WSO2 API Microgateway
The WSO2 API Microgateway (MGW) is a Cloud Native API Gateway which can be used to expose one or many microservices as APIs.
The WSO2 API Microgateway is designed to expose heterogeneous microservices as APIs to end consumers using a common API interface based on the Open API Specification. This helps expose microservices using a unified interface to external consumers, internal consumers and partners. It applies the common quality of service attributes on API requests such as security, rate limiting and analytics and also offers a wide range of features which helps organizations to deploy APIs microservice architectures efficiently.
Table of Contents
Let's expose the publicly available petstore service via microgateway.
Download the latest WSO2 API Microgateway release from the product official page or github release page and extract it. For Docker container based usages, downloading only the toolkit will be sufficient.
Add the 'bin' directory of the extracted distributions to your PATH variable.
export PATH=$PATH:<TOOLKIT_EXTRACTED_LOCATION>/bin export PATH=$PATH:<RUNTIME_EXTRACTED_LOCATION>/bin
First we need to initialize a project by adding the open API definition of the petstore service. We'll name the project as "petstore". To initialize the project, execute following command.
micro-gw init petstore -a https://petstore.swagger.io/v2/swagger.json
The project is now initialized with the open api definition of the petstore service.
Next, Lets build the project and create a microgateway instance.
micro-gw build petstore --docker-image petstore:v1 --docker-base-image wso2/wso2micro-gw:3.2.0
micro-gw build petstore
Start the gateway.
docker run -d -p 9090:9090 -p 9095:9095 petstore:v1
Now we can test our API. Since APIs on the MGW are by default secured. We need a valid token or key in order to invoke the API. MGW can issue API keys on its own. Execute the command below to get a API key from microgateway. Following command will set the api key into
TOKEN=$(curl -X get "https://localhost:9095/apikey" -H "Authorization:Basic YWRtaW46YWRtaW4=" -k)
We can now invoke the API running on the microgateway using cURL as below.
curl -X GET "https://localhost:9095/v2/pet/1" -H "accept: application/json" -H "api_key:$TOKEN" -k
Below is a list of most noticeable features out of many other features MGW hosts.
- Exposing one or more microservices as APIs using the Open API Specification.
- Authentication and Authorization based on OAuth2.0 (opaque tokens and JWTs), API keys, Basic Auth and Mutual TLS.
- Rate Limiting of API requests based on numerous policies.
- Business Insights through API Analytics.
- Service discovery.
- Request and Response transformations.
- Load balancing, failover and circuit breaking capabilities of API requests.
- Seamless Docker and Kubernetes integration.
- Integration with WSO2 API Manager to support design first APIs, API Analytics and shared rate limiting.
It also has the following characteristics that makes it a perfect fit for microservice architectures
- Less than 1s startup time, allowing faster scaling.
- Built on a stateless architecture, allowing for infinite scaling.
- Has an immutable runtime, making it heavily robust.
- CI/CD friendly worlkflow.
- Runs in isolation with no dependencies to other components
Exposing APIs with MGW involves in two main phases.
MGW uses OpenApi specification and a set of MGW specific OpenApi vendor extensions to define an API. Users can use these extensions to enable/disable different gateway features on an API. A sample can be found in here. Dev phase involves defining the required API(s) using these extensions. This phase can involve below basic steps.
- Initializing a project.
- Adding/updating project's OpenApi definition(s).
- Sharing the project with other developers/teams (in Github or any VCS)
Once the project is ready for the deployment, MGW can produce three types of main deployment artifacts. Out of these three types, you can select which artifact(s) you need for the required deployment.
This is the default build output of a project. Output executable can be provided to a MGW runtime installation to start a microgateway server instance. Otherwise this executable can me mounted to a MGW docker container.
buildcommand can be configured to produce a docker image required to create a docker installation.
Similar to docker images,
buildcommand can be configured to produce kubernetes artifacts required to create a kubernetes installation.
MGW runtime is mostly implemented with ballerina-lang. However the toolkit is implemented with Java. You can contribute your code to both runtime and toolkit.
Contribution is not limited to the code. You can help the project with identifying issues, suggesting documentation changes etc.
For more information on how to contribute, read our contribution guidelines.