 Hi everyone, how are you doing today? Great, are you ready for the party tomorrow? Because they didn't call it a party, but it's just, how to say, not a working party. Social. Social, yeah, social network. I'm looking forward to it. So today's topic we discuss how you can absorb your APIs with the help of API gateway plugins. So before we get started, let me introduce myself. My name is Babur, or you can call me Tiger, which is translation of Babur into English, Tiger. And my surname directly can be live and more. Like Tiger, live and more means Tiger who lives longer. This is a direct translation. If you have a problem with pronunciation of my name or another version, like you can call me Bob, shorty, right? I'm a software engineer, open source contributor to Apache Soto Foundation. Also developer advocate for project called under ESF, API6. If you have questions regarding my session, or would you like to discuss more about API management, APIs, feel free to reach out to me on these social channels. I will be super happy always to have this conversation. Before we get started, let's do first thing. For my Instagram, I need to take some selfie, right? If you don't mind, from that part, I think it looks great. Smiles, I don't see smiles, we can take a look at these. So my job is done, I can go home. Thank you. But today I have actually quite interesting topic to bring. We're gonna start first talking about what's API observability, right? And then I will explain you how you can use API gateway as a central observation point for your APIs. And shortly I'll introduce what is one of the famous open source projects API6 also, and then we'll dive into three pillars of observability like logging, metrics and traces. And then I will show you a small demo, how you can use these plugins to observe your APIs, right? So what is API observability? Does anybody know what's API observability? Are you monitoring your APIs? Some people are still coming. So what is the API? Okay, API observability is a very hard question. What is the API? It is a acronym, right? Stands for application programming interface, right? So because we are all now, this API uses by every service, applications nowadays, and API also a little bit itself, it's just the next evolution of API monitoring. Like a traditional, we monitor APIs using logs, right? Using metrics and traces, because traditional monitoring mostly focus on tracking non-announce, which means we know exactly what we are measuring, like a number of requests per second, or maybe number of errors per second, but we don't know exactly value. What will be the value of after we had the resource, how many requests will be for our APIs, right? This is about monitoring. And compared to observability, it focuses on measuring announce, announce, which means there are some metrics that we don't know as a developers that might happen, right? Like a network latency, or maybe some API version incompatibility, right? Or can be some other issues that related to your environment, depth, staging, product environment, that can be separate metrics or logs for different environments, right? This is about observability. We don't have to confuse with monitoring, usual monitoring and observability. I'm gonna explain later how you will understand like what observability exactly means. And nowadays, actually, observability is welcome. Thank you. Observability is a part of every development team, right? Because it solves many problems related to APIs consistency, reliability, and how fast we are, frequently we are delivering new features for our customers, right? And for example, as product manager, I can use API observability to understand the consumption and the usage of my API, right? As I am a developer, I can use it to specify all the requirements. I should build these APIs by looking at the API observability. Or security team, they can use API observability to detect and protect against the possible threats of your APIs, right? If you're a business manager or you're working in a business line, you can use API observability to understand the real business value of your API or you can use it for monetization. There are different teams, different purposes using the API observability. Once we understand, there are another question comes. You see the answer already. How easily observe your APIs? There are maybe several ways. You can use platforms, tools, SDKs, some other solutions. But one of the simplest way I understood is using maybe API gateway. Why? Because nowadays, we are building multiple microservices, APIs, serverless APIs, JRPC services, GraphQL, all this like bringing some functionality to your client applications, right? On the left side, a client application can be mobile, web, desktop application, but you do have not one microservice or a modern service behind the scene. Lot of services are running. And in this scenario, as you can see API gateway can access a central point that can route your incoming requests from your client applications to the intended destination. What does intended destination? As you can see, it can be database also. It can be some serverless APIs, whatever on the backend. You can build this backend with your own knowledge using Spring Framework, using ESP.NET Framework, or maybe go Python libraries. But here in the picture is API gateway access sync layer to catch all the requests. Why it's useful? Because usually if you have multiple microservices, you expose a lot of URLs, right? Endpoints. And this client application should know all the endpoints to get some functionality from them. But what if there is another tool called API gateway can give client application information about all the URLs so that it shouldn't understand what's happening on the behind the scene in your service network. In this case, you can use API gateway to say, okay, these read customers, data should go to customers, the service, read the orders, request should go to order service, and so on. API gateway can map this sort of request. Is it clear what's API gateway now? Who is using API gateway? Yeah, I know you're too, okay, very good, very good. Which API gateway is it? All right, all right, nice, nice. And if it's clear one, what is API gateway, let's understand what is the plugins for API gateway. Gateway is just a door, right? I can open the door and I can go inside. If door is not open, I cannot go inside. It means it offers some security features also. You can do authentication, authorization, right? With the help of plugins because plugins just additional component that can be plugged into your API gateway to add some extra power. We can control the traffic. You can also transform your API request or API responses, right? A lot of responsibilities comes with API gateway plugins. Also, as I mentioned earlier at the beginning of the talk, you can use it like for absorbing your APIs because as we said, only center stays in the center, knows all the moving traffic, all the logs, all the metrics in the API gateway level. You can collect this data easily from the gateway to derive further useful metrics. Without spending time or effort on finding out frameworks, or using your oven tool, maybe building your own tool, you can use some plugins, pre-built connectors where you can easily connect to some famous observability tools like ProMetors. Who's using ProMetors, by the way? Oh, we have many people, right? Grafana, who's using, okay. I'm also using Grafana, ProMetors together. Datadoc also that is in the list. You can always connect to your API gateway without any additional, I mean, coding or additional time. This is one of the benefits of using API gateway as plugins. So, one of the API gateway representing, today me is called API6. It's also one of the open source project of Apache SOTI Foundation. Do you know Apache SOTI Foundation? No? Do you know Kafka, Cassandra, Tomcat? These are all the open source projects, right? API6 is also like one of them. Why I brought this example? Not only I am kind of contributing to this project, because I like also some features on this project. Like, let's assume that it's written originally in Lua programming language, which is old NGNICs. Also, plus maybe some other frameworks written in Lua. But if I don't know Lua, I can use chatGPT, right? If chatGPT cannot give me some ideas, I can use my oven skills, like I'm a Java developer. I can use Java plugin runner to create my oven plugin. Because not always existing plugins can solve your requirements, like user needs. Or if you're a goal developer, you can use the plugin development in your favorite programming language. Another feature, if you don't like to write the code, you are lazy enough, you can use the dashboard without writing in the low code. You can use the dashboard to connect one or multiple plugins together in the dashboard. This is also for free. Our contributors are still working on the dashboard so to make some advanced kind of solutions for using these plugins. So let's back in the observability topic. Once we understand what's API gateway, right? Observability, why important? And what is, let's say, API 6. Now, let's talk about observability pillars. There are key areas where we talk about observability. We need to start to look into metrics first, logs and traces, right? Three pillars. First you start to log in with logging. Logging because it's tribal version and easy to instrument, easy to use. Because logging, I think everybody use logs, right? We use logs for debugging. Or we use logs for auditing. We use logs for in real time understanding some events by timestamp, right? Events coming, maybe Kafka or some other things. Or let's say there are some logger plugins, not only in API 6 or all other API gateway providers like Conn, for example. You can also use these sort of plugins to understand your logs. You can use HTTP logger, for example, to send the requests to your log server automatically from API gateway without implementing it in any logic. Or you can use, for example, TSP logger, whatever logger you want to use. And next one is, for example, metrics. Metrics, like just data measurement over time. You can use metrics to understand what happened over time. Also aggregate this data to further use it in distributed systems, like maybe Elasticsearch. You can maybe understand your metrics on there. And maybe based on the metrics, you can also switch on some alerts to take some actions. This is what the metrics does. With API 6, also you can use Prometheus plugin to collect your metrics. Also show it in the Grafana. I'm going to demo soon how you can do it. Connect to Grafana and maybe visually see your metrics. Last one is observability indicators or pillars tracing. Who knows tracing? Or are you using tracing often? Which tools are you using? Yeah, Yeager also. Open telemetry also. By the way, my colleague, Nikola Franklin, he's here. On Sunday, he's also talking about from developer perspective how you can use open telemetry to understand your tracing. It's going to be interesting, because that's why today I will skip tracing part, only give you an idea how you can do metrics and logging. So this is a Zipping plugin, also we have. By the way, you can also use Zipping plugin, of course, to collect some trace and make reports to Yeager or some other platforms. So that's enough theory. We can jump into now a quick demo I have for today. If you want to try yourself, you can just scan the square code after this session. There is one GitHub repository. It brings you to GitHub repository. Couple of examples, like how you can manage your traffic for your backend. In my case, I am using, for example, in this GitHub repository you will see soon, I'm using Docker Compulse to create some containers, containers for API6, because we need to use plugins, right? Containers for Prometheus, Zipkin, and Grapharm. These are the containers. And then I am also using .NET. Who is a .NET developer? Is there anybody? Now you will kick me out. I'm not actually a .NET developer, originally in Java, but I also, you write sometimes in .NET, but it can be any backend service, just an example in .NET. You can use a Java skill source to build the backend, because API Gateway usually doesn't care about the backend development. You don't have to use, for example, NuGet packages or Maven dependencies to use API Gateway, because it's an independent instance, right? So if it's everything clear, let's me show you some interesting stuff here. Let me stop my presentation here. I am talking about this repository, as you can see. In this repository, it demonstrates some how you can manage your traffic. Also, if you navigate to different brands, there are different showcases. And for example, if you navigate API hostability, you can learn how you can enable all the observability plugins. If you open Circuit Breaker, how you can use API Gateway to enable Circuit Breaker or fault handling, and so on, you will start with API observability, right? Let's assume that I am using Windows machine. Who is using Windows machine? I want to do it like this. Sorry, I worked for Microsoft that time, like I don't have a choice to use. Let's say I am still using the Windows machine, but in my case, WSDL, Ubuntu subsystem installer, there is no issue. I don't have an issue using Ubuntu Windows. But as you can see, I have one container. This is actually second container, api6.net Docker. The same, I cloned the project, and I'm going to run this project without using Docker Compose app. I'm using desktop. But you can do Docker Compose app as well. I'm going to start my containers. They will slowly start it. And then, as you can see, I have one backend service. It's product API. If I navigate to it's running like 5.5.5 port, but actually it's running, but this here is not nothing happening. But if you navigate to API products, it's quite simple API. It does just get request and returns some response like with the list of products. I have two products running for demo purposes. And from there, let's start to observe this small, simple, tiny API. If you open the project in your favorite editor, in my case, VS Code, I use also IntelliJ there, but it comes with VS Code. What we start with now, we're going to first start understanding logs. For example, if you navigate to command folder in this repository, there is a couple of steps how you can achieve these three, logs, metrics, and trace. First thing, in any API gateway providers, you need to create and register your backend service. Backend service, how you can register? Is it big enough, or is it good now? Everybody can see. First thing, you need to create and register your backend service, in my case, product API. In API 6, to register my backend API, I need to create new upstream object. Just one single object. And I'm saying to API gateway, please create single node with one backend service. And we will use it later for plugins and rows. Let's register my backend service. This is a product API with a list of product list. I will register it just by running this code command. But if you prefer to use dashboard, as I said earlier, you can use dashboard. Or you can use even Postman to do this code command, if you hate code commands. We created now first our upstream registered product service. And next step, I will start with logging. Enabling this logging plugin. If I open the next terminal example here, code command, what I am doing, I am creating another object. Call it plugin config. So plugin config, what it does, you can register all plugins you want to use. For your upstream, for your routes. In my case, I want to use HTTP walker plugin to send my logs collected by API gateway to a server, log server. Let's assume that I have a log server running on the mockbin.org. Let me show you. If I go to this mock server, you will see there are some information. Yeah, as you can see, it's saying it's your log server. It's my mock log server. In the reality, it can be your old one log server running in the cloud, running on-premise services. Also, if you do slash logs, it will show all the logs I tried before the demo. 20 hours ago or maybe a few seconds ago, I also tried to run some API commands. It sends some requests, as you can see. So let's enable this plugin to send my API logs to that server. In order to do so, I will create my plugin config with single HTTP logger plugin. And as you can see, it's enabled. And the next step, let me send some requests to my slash API product to send logs. Let me do this cool command once again. There we go. I can do one more time. As you can see here, it should be reflected. Sometimes it takes time, depending on the network issue or so on. But usually, these logs should come. As you can see, like a few seconds ago, one log came. And then, if you open these API6 logs available, it adds additional headers, like, for example, headers for rate limiting, how many times you can send this request, so on. Or you can customize these logs as you wish. This is how HTTP logger, simply, I enable it. On the other hand, how you do achieve this logger, for instance, in the Spring Framework, also easy. In application.properties, you can enable these logs as well. It's also simpler, even, like a Spring. So now enable it. As we can see, we can send some logs, and we can see the logs. Clear now, HTTP logger? Or any questions? I see some faces, not something not clear, or everything is crystal clear, right? Good. Next step, in my list, is to create a route. So let's see. I created one first upstream, a plug-in config, a route. In API Gateway, it means I will show sometimes some policies, regulations, how my request should be forwarded to a backend service. This will specify some routing rules. Because we skip it in the previous step now, I'm going to explain these routing steps. As you can see what I'm saying to API Gateway, please try to fetch every GET request to our domain if this request slash api slash products enable these plugins. In our case, it was HTTP logger plugin, right? Once you enable these plugins and use this plugin, after that, you can forward the request to the backend, product API. That's how fetching mechanism works in API Gateway, right? If it isn't good, next step, maybe let's try with Prometheus plugin, how we can enable this plugin with easy steps. I can, for example, create one, again, plug-in config by running patch request. I can add a Prometheus plugin to my plugins list. There you go. If I do this code command and run it, my Prometheus plugin is also enabled here. How I can see these plugins, if you navigate to Docker, if you remember, some Prometheus also, the instance were running. Let's check this Prometheus instance and if you have any metrics available on this dashboard. For example, usually metrics sent by API 6 call it HTTP, or you can, for example, see other also type of metrics available, like I say, maybe HTTP status. I think it's not yet here, but I can generate some by calling, again, one request. Because until we send the request, these plugins wasn't enabled, right? Let me send some request and then maybe I can see some thing here, API 6. Was it the status, Nikola? Do you remember? Status, let me check. Or we can HTTP, what's the status? Oh, we can see the own graph on as well. Or it's not coming. Maybe just use the code command. Sometimes, this work updating not quickly. We can use code command, like in the dashboard. Because my metrics are now automatically should be sent to this endpoint, running the same on the Prometheus server, like Prometheus metrics. For example, I can use this code command and see this metrics over there. There we go. Here, I think it was this one, API 6 HTTP status. We can try to search now back in the dashboard how this came to my dashboard. Yeah, this is the same request sent to the Prometheus. The idea is very simple, right? I mean, to implement this, the same like future in other frameworks, they can do also similar steps. But in our cases, in API 6 Docker Compose example, like everything's set up, like there's a graph on also configuration. Sometimes it's hard to configure, but you can also use these capabilities. For example, if I navigate to Grafana, the board now, we are contributors, because it was already created this beautiful dashboard. Is it easy to create a dashboard on Grafana? No, right? Yeah, it's true. That's the point. Like we have already this dashboard is created, like you can at least understand some observed APIs, like a request per second, or you can understand some latency, how much latency your APIs are taking, or for example, you can understand some traces later on with open telemetry, right? This is how the Grafana and the Prometheus plugin actually works together, automatically send some requests, right? So this is about the logger and Prometheus plugin. If you want to understand like other plugins we have, you can open the official website, there are a list of observability plugins. Let me show you, like here, under observability, you can see it's structured by the categories. For example, tracers, we are supporting right now, Zipkin, Skywalking, open telemetry. Or if you want to use some metrics, like you can use Datadoc. Most of our open source developers are using Datadoc. Or if you're using like a logger, for example, you can use like a Google logger or Clickhouse also. We are supporting, and we are adding more extensions onto API6. This is open source, right? You need to find some contributors who can do this integration part. So the Z, we can slowly close my presentation. Before that, let me finish with the takeaways. What was the takeaways, actually, what I presented or tried to explain? First, you can use API Gateway. If you want to easily make available your monitoring observability without using some SDKs or libraries or tools, you can achieve that as we achieve it easily right now, like I spent even less than five minutes. Or you can use some more than API gateways to build some other connections to other platforms you want to use by adding additional plugins to support other platforms, right? And then also, you can use some plugins without any code on the application side, because we didn't write any code on application side. Usually, you need to write something also to send from application to API Gateway some logs, right? And it's not about API observability. It's API Gateway also you can use for other cross-containing functionalities, like you can use, as we said, for transformation, right? You can use for load balancing also, sometimes. There are other features. So it was my talk. There are some references. If you are interested to contribute to open source project, you are more than welcome. And you can get this sort of t-shirt. It's kind of more motivating, right? Now we can jump to questions, if you have any. No questions? Yep, who got? Yeah? Oh, yeah. It's a tricky question. Thank you for that. Do you want to answer or I can answer? Yeah, just a bit of questions. My colleague was asking, what is the key reason to switch from the API Gateway that they are using to API 6? That we are trying to explain now. I am giving a stage to my colleague, Nikola. He would like to understand which alternative are you using currently? API management, because you are workload-ordered in API management on Azure, right? Infrastructure. OK, in that case, if you're using combination of different platforms, you can also use API 6 together with API management. The idea, for me, it's performance first. It is quite fast. If you want to speed is the first place. Also, you can use some other features that maybe the Azure API management doesn't provide. If I'm missing something, Nikola? Yeah. And what are also the cloud providers using Azure plus? Is there anything else? Yeah, I get it. And also, one thing, we are talking about API Gateway a lot, right? You can also use Ingress Controller. API 6 can work as an Ingress Controller for Kubernetes. There's a different topic. That's why we have different sessions for that. If you're interested, you can check that out. Because I know 60% of our many contributors now from different companies, they use Ingress instead of API Gateway, because everything is inside Kubernetes, right? So this is a solution. I think this is also a selling point. I'm not selling, but the selling point of API 6. I have a T-shirt for you, one. The same like this. I hope the same. I have two more T-shirts. Sorry, once again, it's a little bit far. Yeah, good question. I think I will repeat the question. My colleague is asking, is there any performance indicators you are checking to understand the API's performance with the parameters, right? Yeah, there's an additional configuration we need for that. But there is a performance analysis, benchmark analysis we did in the past. Maybe I can also send you the link specifically for API 6, you can have a look, right? And if your question is more about specifically if we did for one product API's performance testing, we don't have such tool, honestly, like to test with parameters. It requires additional setup for parameters. That answer question, or maybe we can talk after. OK, out of time. One more question, no. One more question do we have? Because I have one T-shirt more, so I need to think. Well, I can give it to the next session. Any questions? Or I need to show, like, this is a T-shirt, very high quality, but it's black. You cannot be in the sun. I had trouble today. Sorry. Thank you in this case for your attention.