Micro API gateway
Introduction
Yes we have repeatedly heard of API gateways, but what is it,
a micro API gateway??
Is it something evolved when microservices came in to play,
you ask. Of course the micro API gateway concept emerged with the microservice
architecture.
However micro API gateway again is a type of API gateway, but now
it serves a different set of use cases, other than the typical API gateway. Essentially, WSO2 offline micro API gateway is an approach to meet your different
API needs.
This enables the gateway to run in a localized environment,
because now all the information of the API, including the API name, API
context, API version and the subscription details are being stored at the
gateway itself.
In the APIM 3.0 release, WSO2 micro API gateway is authenticated
using the API key, which I was a part of.
WSO2 micro API gateway
WSO2 micro API gateway is powered by Ballerina. Initially this was coded in Ballerina 0.89, but will be upgraded to the latest version.
Micro API Gateway flow |
Microgateway flow is not much different from the normal WSO2 API gateway flow, unless now the cache is loaded using the API swagger JSON files.
As depicted in the diagram, the API ballerina files are used when creating a client connector to the actual API target, once the authentication process succeed.
Use cases
1. Reduce API traffic latency
In the WSO2 normal API gateway scenario, the gateway has to
rely on the Key Manager server, Traffic Manager server and Analytics server to
cater the typical aspects of an API gateway. This results in additional latency
for an API call when it has to connect with other servers, which is not a
favorable condition at all.
Typical API Gateway and related components |
Unlike the normal WSO2 API gateway, here the micro API gateway itself will perform all the
functionality without calling the other servers. In this way the API run time
traffic is separated from the API core traffic to reduce the latency when
serving an API call.
2. To run in a locked down environment.
Micro API gateway executes in an offline mode, that is, it is
detached from the API core (WSO2 publisher + WSO2 store) and Key Manager, and
is run as an isolated component.
So, unlike the normal WSO2 API gateway, micro API gateway has the
capability to execute in a locked down environment (to run in a Pod, maybe!).
Now the microgateway itself will perform all the
functionality without calling the other servers, which will be very useful in
future gateway deployment patterns, to manage even the internal APIs as if it
was externally facing.
3. Provides an Immutable run time
To start the micro API gateway, the user should place the API
swagger file and the API ballerina file of each API in the “microgateway”
folder in gateway home.
•
API Swagger JSON file - this includes the api
definition, used to load the caches at the bootstrap time of the microgateway.
•
API Ballerina file – creates a client connector
with the API endpoint, for every resource that is available.
These files which should be provided by the user contain all
the necessary information of APIs. At the bootstrap time of the microgateway,
it loads its caches from these files.
Now the micro API gateway itself bares all the information
required to meet the API needs securely. Once an API is invoked it
authenticates against the available API keys, and responds back in accordance
with the cache.
If the user wants to add/update/delete any API related
information (API keys / subscription policies etc.) a user must do the changes
manually into the ballerina file and the swagger file of the API, and restart
the micro API gateway. Hence this is immutable. So there’s a guarantee that the initial API artifact is not
changed unless the gateway is restarted.
P.S. Apart from the above use cases, there are many other. But I would recommend you to take a hands on exercise on yourself to feel the actual usage of this. [link]
Comments
Post a Comment