 So good evening, everyone. My name is Gao Xiang, or you can call me Eric. I'm currently working as a full-stack engineer at a startup called DeepLabs. So today, basically, after hearing the last month's meetup talks, I come up with an idea talking about API gateways, because previously I was working related to API proxies and API gateways. And also, because the API gateway is in the context of microservices, I will also talk about some background on the microservices as well. So here is the agenda of today's talk. First of all, I will talk about the software architecture history from the Mononic app into the microservice app. And then I will talk two of the common terms used in the API gateway world, which is API proxy and API gateway. And then as a standard of every presentation, I will talk about some pros and cons of the API gateways. At last, there are a lot of open source implementations. I will pick one of them as a demo. And in the end, there is some conclusion and a future work. So in the 90s, basically every application is just one single app. And the developers only need to know one language or one framework. So we are living our happy life until the day that the microservice architecture come out. So now we need to learn more and more new languages and new frameworks, because it's macro architecture. So the idea of macro architecture is to split the single application into multiple sub-self-contained services. And they communicate with each other through APIs. And as we are living in the age of rest, most of them are rest APIs. So here is the background of the software architecture involvement. And everything went well when you are developing the individual services. But there will be a problem when you integrate, I mean, from the client to see the whole microservices app. So for example, if we are building this Armadun mobile application, which has two sets. One is the back end, one is the front end, mobile end. The front end sees the back end as messy API work, because we have so many microservice modules. And for example, if we want to gather some information about user account or product, we don't know which module we should call. Or if, for example, in order to call the module, we need to remember all the IP address of all the sub-modules. And what if one of the modules doesn't provide a web-friendly API? Like for example, it's RPC API rather than the normal rest API. And even though we have figured all this out, we may still face the problem. We need to make tons of calls for just one page of the mobile application, because there are so many microservices. So how do we solve this? The single solution is the API gateway. Before we touch more on what is API gateway, there are two terms actually being used. The first one is called API Proxies, which in general exists in a long time already. As we all know, we have NJX Proxies or Apache as a proxy. So basically, the idea of proxy is to point in. You already have one API at your back end. You will point to that API, and the client will request your proxy. And then the proxy will do some request protocol translation if needed. And as a proxy, you can also add some features like security and monitoring. So this is the standard proxy. For the API, it's more involved, because you can do more than one mapping. Because in the microservice work, you have more than one APIs. Sometimes you want to aggregate multiple APIs to create a new API. So besides that, the API gateway can consider as multiple API proxies. So in that sense, because it's acting as a router, you can add more services like orchestration and authentication. Most of these are in the API gateway work. So the key idea of API gateway is mapping. So mapping the user-facing API to your back end APIs. It can be one-to-one mapping. It can be one-to-many mapping. Most of them are static. That means at the time of the application is running, you already specify the mappings. And then there are a lot of benefits of using the API gateway. First of all, if you look at the picture, basically, Netflix tried to use the API gateway to reduce the number of front trips from nine to one. Just imagine that your client is a mobile application sitting at another end of the world. Then this will be a good performance improvement. Besides that, for your clients, they always want something that's really fancy. They don't want to deal with your complicated API, complicated microservice API work. So you just need to provide them one single API entry point. And then you can customize for each of the customers you have. And last, as I mentioned in the definition, because your API gateway is sitting between your application and your clients, it actually can do a lot of things like the monitoring and authentication adding at this level. But there is also some drawbacks. First of all, originally, your work is once you finish your microservice API, you are done. But now because you have the API gateway, you need to expose your microservice API to your end user. So there is a possible risk of development overnight for meeting the API gateway development. But we can easily solve this by making, adding, or exposing the new API much, much easier. So later, I will show one of the examples how the open source tool help you to do it in an easier way, just making one right call. And this is the part from my personal experience that if you are doing an API gateway in a microservice, a lot of time you will have a risk to create a distributed transaction, which means in this case, you have actually three servers. So one will acting as API gateway. Two and three are your microservices. So if the user want to create a transaction such that it performs some action on two first and then on three. So the problem will be what if your action on server two is success, but your action on server three is not success. Your whole system will be in inconsistent state. Therefore, it's a distributed transaction problem. But for best practice, I will suggest that we always avoid right related API aggregation. So if you want to merge multiple API together, you always use the read-only APIs. And to solve if you really need such kind of operations, you may try to solve it by using some kind of global queues for the eventually consistency. So as so far, we have seen the pros and cons of the API gateways. But it still seems that we are OK to go through with it. So these are the possible open source applications. The most famous one will be the cone from the Marship, which is written in Lua. And then the key idea is that it has three components inside. The first one is your API. The second one is your consumer. The last one is a plug-in. So as long as you have created an API, created a consumer, you can apply plug-ins on the API and on consumers. Later, I will do a short demo about this. And there are a lot of other open source tools as well. And if you are using some specific platforms like Amazon and others, of course, you need to deal with the Amazon API gateways. So maybe a short demo on the cone. So basically, I have created several Docker containers. If you check here, the first one is the cone database. The second one is a Python server which acting as our microservice API. We only have one API in this case. And then the cone server itself, there is also a cone UI. So the idea is once we create the server, this might take some time because the starting up of the Docker container will take some time. So the demo here, what we want to achieve is adding a new API into the cone server and apply a key authentication so that if you don't have the key, you cannot access the API. OK, it's still starting up. But as a start, we can try to call this. This is the microservice API from the Python server, which actually, when you add the recall, you will receive the recall into memory. And then we can access it. So here is the redock, hello. And then at the first, if we call from the API gateways, you will not have a connection because you haven't added the API into your API gateways. So the format to add the API is to call this REST API. Still getting up. OK, finally it's up. Sorry for taking so long. So now you have created your API gateways. Now you can access it by calling from, if you notice in the URL, we are actually calling from localhost 8000, which is not the Python server API. So you get the same results. And if you check from the cone UI, and this is the API we have created, and we can add a plug-in to it. So for example, we add this key authentication API. And once we have this, if we try to access it again, you'll be unauthorized. So this is the basic idea of how the cone API gateway works. And as a conclusion, many talks about what is the API gateway, and how you can use an open source implementation to make your life easier to manage APIs in your microservices. And in the future, I think there are a lot of things need to be done. Like for example, most of the API gateways currently don't have self API discovery. And there is no dynamic API mappings, or there is no UI for you to merge multiple API together to create a new API. So this may be some of the things future will come. Oh, sorry. You're talking about open source solutions, right? Yeah. In the context of open source solutions. Yeah. Because I don't have access to closed source, right? Yeah. So this is a reading list if you want to find out more. And that's all about my talk. Have you run a cone in production? Sorry? Have you run a cone in production? No. Transparency would be nice to see some information. Yeah. So that's all. Any questions? I think cone is being used in production by the company who made it, Maship. It's like an API marketplace for. The Maship itself using the cone app. For me, I don't know. Yeah. I think in back end, it's made out of NGX, like one part of it's NGX. Then I think the, just when I saw the database, I think that's like a state. Using Cassandra. So it's actually like a mixture of a lot of open source components and that sort of thing. What's the language, of course? What's the language? I think it's big. If it's open source, we can do what we want. What? How are you doing? What? It's easy to use for kids. For us. OK.