Streamlined API Management for Developers
With the exploding endpoint problem that exists, APIs no longer require an introduction and is used or should be used by all/most organizations. With APIs becoming a core component of architecture, there is an increase in API management adoption with proper lifecycle management, governance, security, rate limiting and much more. However, most of these approaches/solutions that are in place require API specialists to join the team and brings in changes to the way projects are implemented, built, tested and also automated. In an ideal world, API management should be more aligned with the usual developer and ops workflow of an organization. This is an explanation of how WSO2 micro gateway can be used in a typical developer and ops environment for API management.
In a typical microservices architecture, different developers can use different technology stacks and frameworks to build the microservices, as micro-services nurture the concept of independently build, managed and rolled out. Let’s consider a scenario where a set of developers working in a microservices architecture, trying to build an online book store. They have worked on their microservices for this bookstore and is looking at exposing an API for these services so that external parties can consume that API. Following is a depiction of what they want to do.
The development team of this organization uses Spring boot and Ballerina to build their backend microservices which are related to different components of the book store, such as book listing, book searching, author catalogue etc. They also want to represent all these services using a single book-store API which can be invoked by the subscribers. WSO2 micro gateway can be used as depicted below to expose the required API, regardless of the technology used to create the microservices.
Now let us try to map this solution to the typical developer workflow followed at this organization. Let’s consider two developers, John and Emma who developed book-listing service and book-search service using Spring boot and Ballerina[4] respectively. Once the API is exposed, John likes to perform his edit, build, test cycle in his on-premise local machine itself. However, Emma wants to complete that cycle in a cloud-native environment(where her micro-service is deployed in a kubernetes environment)where she wants to expose the API as a docker container. WSO2 micro gateway comprises of a toolkit and runtime components, where the runtime comes as a binary as well as a docker image. Please refer [1] for more details on the WSO2 micro gateway architecture.
With the micro-gateway in place, this is what a typical developer workflow would look like for John and Emma, without interrupting the independent cycle followed by each developer.
You could find a reference implementation of exposing a Spring boot service and a ballerina service as a single book store API in [3].
How is this possible? Here are some clarifications for some obvious questions that might be popping up for our inquisitive developers.
Where are the connections to external components? Such as an IDP?
Well, WSO2 MGW is designed in a way that it can be used a completely offline environment if needed. That means you do not need to connect to any external component if you do not want to. For example, if your security mechanism is to use JWT tokens you do not need to connect to any key manager. This also helps in the scaling aspect of MGW, as it does not depend on other components.
How can the same API expose two different backend endpoints?
This is supported by the vendor-specific extensions that you can include in your OpenAPI swagger specification, allowing you to define backend endpoints for each resource of your API.
How can I create a bookstore project?
You do not need to worry about this, as the MGW toolkit will auto-generate this common folder structure for you. You just need to provide a name for the project and run an init command like; micro-gateway init bookstore
What is this .balx extension? Do I need to install anything specific for this to work?
WSO2 Micro gateway is built using Ballerina[1] which is a cloud-native programming language to code integration. If you are like Emma and is already using Ballerina to write your micro-services you will already have Ballerina installed, but if not, no worries you do not need to worry about installing Ballerina. It automatically creates this runtime executables in your project, and you just need to point this file as input to the MGW runtime.
Why does Emma need to rebuild the project?
Micro gateway artefacts are immutable, therefore whenever you edit, want to add a new resource etc you need to rebuild your artifacts using the toolkit component.
How about everything else related to API management? rate-limiting? security?dynamic endpoints?
Yes, WSO2 Micro gateway comes with all that :)There is local and distributed rate-limiting, OAuth/JWT/basic auth support, request/response schema validations, dynamic discovery with ETCD , offline analytics and more. Please refer [2] for a complete set of features that are supported.
[1] https://docs.wso2.com/display/MG301/Overview
[2]https://docs.wso2.com/display/MG301/Using+WSO2+API+Microgateway
[3] https://github.com/himasha/MGWDeveloperWorkflow
[4] https://v1-0.ballerina.io/
In the next blog post, let’s look at how we can streamline API management for your dev-ops engineer, using WSO2 micro gateway to create a complete Kubernetes environment for above Bookstore API.
