 or like any other API gateway. Okay, let's start with authentication and security. So with the API gateway, when a user sends a request to your service, that is your API gateway, you can set up authentication. So this can be simple stuff like a key value pair, JWT token, or you can use other platforms or the third party platforms, something like OAuth or any other third party tool. So it not only lets you control who access your APIs, but you can also get the user info once the user is authenticated with your API gateway. And you can make your API a bit tailor-made so that you can give each user a tailor-made experience. Another one is rate limiting. So rate limiting can be intentional, something like denial of service attacks, or it could also be unintentional. So maybe like your site got really popular, your application got really popular, and there are a lot of users trying to access your application at the same time. So this could happen in a multitude of ways, but you have to make your services reliable enough to work against this, right? So an API gateway can help you do that. So if the number of requests exceeds a certain threshold, you can choose to reject or delay the request so that your backend application or your actual APIs can handle those requests. Now let's look into monitoring and observability. So you are only as good as your monitoring solution because if something happens, if some error occurs or if there are some issues, you need to be able to identify it. You need to be able to have data on it to actually protect against it. So an API gateway like Apache API 6 integrates with a lot of observability tools, so like tracers, so things like open telemetry. So API 6 integrates with open telemetry and logos. So you need logs coming in from your API gateways from your backend applications, and you also need metrics of stuff like Prometheus. It needs to be integrated with stuff like Prometheus. So all of these stuff can be handled centrally within an API gateway. So when you think of a system without an API gateway, you need to actually add all of these into each of your applications, each of your microservice application. So an API gateway makes it much easier to do that. Another aspect of this, another aspect of reliability is version control and zero downtime. So you have to make sure that you are able to bump new versions, release new version of your application without your users experiencing any downtime. And you can do this with something called a Canary release. So this is a release strategy that is being followed in like the software engineering world. So you have your V1.org API, and you are trying to switch it with a V2.org API. And initially you have all of your traffic being routed to V1.org. So API gateway is routing all traffic to V1.org. And you have V2.org deployed in your server. And initially you can route some traffic. So a 5% is a nice number. So you can route 5% of the real traffic to your new version of the application. And the API gateway lets you do that. So in Apache API 6, this is handled dynamically. So you don't need to restart the gateway to make this change. But some percent of the traffic is now being routed to the V2.org application. So you can test your application with real traffic, but you are only testing it with a small percentage of the traffic. So if any issue occurs, or if your application is not working as you intended, or if there are any bugs, you can easily identify it without affecting most of the users. And finally, when you have tested the new version of your application, you can deploy or you can configure the API gateway to route all traffic to your new version of the application. And there is always an option to roll back to the older version of the application if you have an API gateway. Next up we have circuit breaking. So this is similar to how circuit breakers in electrical circuits work. So the main goal of a circuit breaker in an electrical circuit is to protect your applications from faulty components. So if you have faulty service, or if you have a service that is experiencing some downtime, you need to cut it away from your system. If you don't do that, what happens is it can cascade into other services. So if upstream A1 is not working and you are still trying to send requests to this upstream service, this request will fail and this will cause a bottleneck in your system. So you have to make sure that you cut it off from the system. So when you play gateway can check the, can run health checks with these backend applications. And if they are faulty, they will cut it out from the system and the API gateway can keep pulling the system and once the service is back online, it can restart sending requests to this service. And finally, redirects. So as I mentioned in the beginning of the talk, reliability not only means reliability of your services but also means reliability for your users, for your client applications. So redirects are a way to do that. So if you are deprecating or like if you are changing your API endpoint, a client application might need to change their endpoint as well. So this is an additional overhead to the clients. So if you are doing this frequently, you don't want your clients constantly changing their code to like work with your API. So an API gateway acts as a middleman and even if the user sends the old API endpoint, an API gateway can redirect the users to the new API and it can also send a deprecation notice with a 300 status code. And this will help users to like transition to the new API in a more smooth way. And before I go, like I want to talk about the project and the community. So Apache API 6 is a project under the Apache software foundation and it is entirely built by the community. So the Apache foundation has this motor which can be summed up as community over code. In this project is entirely community driven. And we have community members from around the world. So yeah. And if you're interested in contributing to API 6, feel free to do so. So contributions of any kind are welcome. You can contribute code. You can help us by testing out API 6. You can share how you're using API 6. You can help us write blog post or give talks like this. So you can check that out as well if you are interested. And if you have any questions, feel free to ask me now. And you can check out API 6. And there is also an article version of this talk. So if you want to look at all these diagrams, you can check that article out as well. Yeah, thank you. I guess I have a lot of time for questions. So we do have Kishya. Yeah. So my question is basically, I'm trying to basically find out what exactly this is, why this is different from load balancing. It seems to be a lot of features are very close to load balancing except for things like the monitoring and the logging. But does it do things like integrating multiple APIs? So is that one of the features that it has? Or is it more like a more advanced version of load balancing essentially? Yeah, it does load balancing. So load balancing is a, I guess it's sort of superset of what a load balancer is. So an API gateway can do load balancing. An API gateway can also batch request as you mentioned. So one request to the API gateway and the API gateway will send multiple requests back to your services, collect all the information and send it back as one package. So it does all of that stuff, but it also gives you more features on top of that, better control of your traffic. Yeah, so. Yeah, so I have a really good question. So you mentioned it has tracer support, right? And I wonder when this API calls the downstream API and if you also use the same API gateway for those downstream APIs, does the tracer integrate all the traits together? And yeah, can you get into the detail like how the tracer works? So the API gateway access the entry point to your whole backend services. So when we talk about open telemetry, this is where an API gateway is the place where you get the trace ID generated. So everything that starts at the API gateway, it can track. So if you have instrumentation in your backend applications, the API gateway can trace the whole request. So from your API gateway to your service and like if you have databases, maybe you can also instrument those databases to send out traces. So an API gateway can be the central part and it collects all these and you can get it as a single data. So there are many API gateway service on all the platform. If you talk about AWS, they have AWS API gateway in the Google also, Google API is and all. So have you done any kind of evaluation? This API six from Apache, how it is different from them? What is the USP it is having, which is basically a differentiator as per the other API gateways? What are those points? Those brownie points actually, that would be really helpful if you can help us. Yeah, but that's a good question. So first of all, API six is completely open source and it is hosted by ASF. So that's a big point. And then like API six is built on top of AngelX but it is a different build of AngelX that makes it much faster, much more dynamic and much more much less and cost much less overhead to your infrastructure. So being fast is being fast and making makes it really scalable. So as your applications grow, I'm talking in the range of millions of traffic, millions of requests per second. So in such scenarios, API six really shines compared to other alternatives. And when you talk about big cloud providers, you can always end up in scenarios like where you are tied to the vendor but Apache API six let's you get away from that. Because like you can easily switch to a different API gate if you want because API six supports a lot of common specifications. So like if you're using Kubernetes, there is a Kubernetes Indra's API and there is also a Kubernetes gateway API. So API six supports all of these. And even if you decide to switch API gateways, you don't need to change your configuration. And this will work seamlessly. And there is also the case for multi cloud or like hybrid cloud scenarios where you don't necessarily want to be tied to one cloud provider and a gateway like API six can like help you avoid that. Are there questions? So API six has this plugin architecture. So there is the core API six and all of these features, all of these things like rate limiting and observability are implemented through plugins. And let me just show you the docs. We have multiple plugins for rate limiting. So yeah, so this plugin limit work limits the number of rate limits based on number of requests. And we also have things like limit the number of simultaneous connections a user can have with the API gateway. And you can also do things like limit based on count. But you can also make it more complicated by like setting up rules for specific users. So you can set up authentication and once the user is authenticated, you can give them a certain limits. So this particular user has 60, can make 60 API calls in a minute or like a paid user can make 600 API calls in a minute or something like that. So API six really lets you do that. And if you have a more complex scenario that is not supported within API six's plugins, you can also create your own plugins. So you can use Lua or like you can use all of these other programming languages. So API six also supports multiple plugin runners. So if you can write Java plugins, you can write Go plugins. We are also working on a Wasm integration. So basically you can write a plugin in any language and put it to Wasm and like run it with API six. So yeah. Yeah. Yeah. It should be possible but like not out of the box, I guess. Like you can set, you can write your custom code to like pull metrics from like Prometheus or somewhere. And then like or set up your monitoring system and then like evaluate and run limit as you mentioned here. So if you need to, so the question was how you can upgrade the API gateway? So I guess it is similar to how you update all the other software because you can do something like canary release as well. Because if you have multiple instances of API six deployed, or like if you're talking at that scale, you need to have some, some sort of load balance or in front of that. And then probably to a canary release or something similar so that like the traffic is not dropped in between. But the process is quite seamless. Like we do, we do have a LTS version and we also have a genesis. So most people like they stick to one particular version and they like they take time to like update to any version of API six. But yeah, that's how we treat it. So, so one question was what kind of communication protocols we support? So, so all the different types of API. So like REST, GRPC, GraphQL and work. We also support multiple protocols. So we recently had a user who have been using API six for IoT applications. So that uses NQTT protocol. So it is it, it is pretty vast. And like another use case of an API gateway is like to convert between multiple protocols. So you might have a GRPC application or you might have a GraphQL application, but your API is on your client is in a REST model. So you would want to translate between those different kinds of API, API types, right? So when API gateway can be a facilitator for that. And the other question was about service discovery. So API six integrates with service discovery platforms as well. So like, let's see, like, so API six integrates with all of these platforms. So if you talk about copenties like API six integrates with copenties default service discovery system. Let's see, like, there should be some documentation somewhere here. Oh, yeah. So you can see all these all these registries, all these different things that API six supports. So yeah, you can definitely integrate with that. I'd like it will do a service discovery here. You can also do it manually as well. Like, so if you have a YAML file where you are automatically populating your services or like your backend services, API six can watch that and like, do automatic service discovery. Thank you. Thank you.