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

Popular posts from this blog

What is an API?

Image
What exactly is an API? API stands for A pplication P rogramming I nterface. Perhaps some of you may have already used APIs in your software applications, which you may think that API is an already written piece of code dedicated to perform a specific task. Yes it is, but hold on! The API itself gives the actual meaning when it is read backwards.   an Interface used by Programs to interact with an Application. Essentially, an API could be anything in any form that is used by 2 software components to communicate with each other. Basically an API allows one application to talk to another, directly and securely. Some important facts about APIs will be listed below, No direct human usage of APIs. That is an API is normally invoked by some other code which is running on a computer. Normally this code is written by a developer to talk to the API. APIs expose something useful. You have APIs on your computer itself. (eg: when you type a key in the keyboard it gives
Read more

API Gateway

Image
This is needed when bringing all the microservices together, or rather this can be introduced as the entry point of the requests made by clients for each API service. All requests from clients first go through the API Gateway. Basically this abstracts the complexity behind the application you are going to build, so now the clients simply talk to the gateway to invoke specific services. The API Gateway is responsible for request routing, composition, and protocol translation.  Or rather this is an intermediate layer for the APIs and clients who call them, providing the functions listed below, authentication  authorization of API calls security throttling and rate limiting Proxy vs. API gateway Precisely, an API gateway is so much functionally richer than a proxy. Proxy provides you a new endpoint for an existing API and add some lightweight security and monitoring. The gateway, of course, still offers the same capabilities that an API proxy would offer for
Read more

Microservices

Image
You may have certainly come across this term, and may be curious what exactly it refers to. Okay I would say, this mainly refers to an architecture, which is used in developing software applications. It’s more like implementing specific use cases, independently. That is the software is being decomposed into independently deployable, simple services that could cater a specific business need. Microservice Architecture These components may use different languages, technologies, frameworks etc. and finally can communicate each other via well-defined interfaces, or rather APIs. That is they communicate each other in a loosely coupled way. This I would say, is ideal for large applications, providing better agility in the long term software development process. Especially when working with large teams, so now you can assign certain features of the app to certain team members. Also can scale fast unlike the monolithic architecture.   If not for micro services, how can pe
Read more