What is WSO2 API MicroGateway (MGW)?
It is a lightweight proxy for your APIs.
What are the core features?
- Security via OAuth2, JWT
- Usage metering (Analytics)
- Low resource usage (2CPU, 256 MB RAM)
- Fast bootup time
When to use?
- When there is a unusual traffic for an API or a set of APIs, you can spawn a MGW to serve traffic during that period without impacting the performance of other APIs
- When there is a need to run gateway in a lockdown environment which does not have connectivity to other API management components (e.g. Publisher, Store, KM)
- When deploying API gateway within a microservices architecture where gateway acts as a sidecar to the main service (or API)
How API MGW works?
- API developers use the Publisher interface to create the APIs
- API admins publish this API
- API MGW will connect to the API publisher and generate a micro-gw runtime
How to invoke an API?
- Log into the developer-portal (Store) and subscribe to the API through an application
- Generate an access token (JWT or OAuth2 token)
- Send the request along with the token
e.g. curl -k -i -H “Authorization: Bearer <JWT_token | OAuth2_token>” <API_url>
What are labels and how to use them with MGW?
- Labels allow the users to create a MGW runtime with a set of APIs
- The label needs to be specified in the admin portal (https://<hostname>:9443/admin)
- When you are creating and publishing an API through the publisher portal, you can see the label you created in the previous step under “Microgateways” category in the Manage->Gateway Environments section of the API creation wizard
- Once you select the label from that menu, this particular API will get assigned to the selected label
- Using the micro-gw CLI tool, you can create a microgateway runtime with this label name which will eventually create the microgateway with all the APIs which has this particular label
e.g. micro-gw setup <project name> -l <label name>
micro-gw build <project name>
How to handle multiple environments with different endpoints?
- Dev, Staging, UAT, Prod environments can have different URLs for backend endpoint
- Use system variables to override endpoint information
- Override production endpoint (after building the MGW)
e.g. bash gateway -e TestAPI.v1.prod.endpoint.0=”http://wso2.com"
- Override sandbox endpoint
e.g. bash gateway -e TestAPI.v1.sand.endpoint.0=”http://wso2.com"
- Override with load balanced endpoint
e.g. bash gateway -e TestAPI.v1.prod.endpoint.0=”http://wso2.com" -e TestAPI.v1.prod.endpoint.1=”http://support.wso2.com"
- Override with backend basic authentication details
e.g. bash gateway -e TestAPI.v1.prod.basic.username=”admin” -e TestAPI.v1.basic.password=”admin”
How to monitor MGW?
- In a locked down environment, the connections to other components can come and go
- Analytics (monitoring) data needs to be stored locally and published when connected to an analytics runtime
- API requests received at the microgateway and the relevant analytics metadata are written into files
- A file rotating task which is configured to run periodically will rotate and archive the original file allowing the new file to get created
- A file upload task which is configured to run periodically will upload the archived files to the microservice which is running in the analytics server
- These archived files are stored in the WSO2AM_STATS_DB database in a separate table with the name AM_USAGE_UPLOADED_FILES
- A separate task running in the APIM analytics server process these files and publish events to the stream processing components of the analytics server
- Stream processing component of the analytics server will process this information and stored in the processed data table which will be used by the API publisher and store components