The WSO2 API Manager team is pleased to announce the release of API Manager
Micro Gateway 2.5.0-M1. It's now available to download.Distribution

https://github.com/wso2/product-microgateway/releases/download/v2.5.0-m1-r/wso2am-micro-gw-2.5.0-m1.zip
<https://github.com/wso2/product-apim/releases/download/v3.0.0-m21/wso2apim-3.0.0-m21.zip>
Documentation

https://docs.wso2.com/display/AM2xx/Configuring+the+API+Microgateway
Introduction

The Microgateway is a specialized form of the WSO2 API Gateway. Its main
characteristics are

   - Its ability to execute in isolation without mandatory connections to
   other components (Key Manager, Traffic Manager, etc).
   - Ability to host a subset of APIs of choice (defined on the API
   Publisher) instead of all.
   - Immutability - if you update an API you need to re-create the
   container/instance, no hot deployment.
   Microgateway offers you a proxy that is capable of performing security
   validations (OAuth, Basic Auth, Signed JWT), in-memory (local) rate
   limiting and operational analytics.

Design Goals

Following are some of its main expectations of Microgateway

Ability to host just one or a selected set (subset) of APIs only.
Ability to execute in complete isolation once setup, without having the
need to contact the Management or Security components.
Easy integration with CI/CD processes.
Seamless integration with deployment automation tools and techniques.
Architecture

The following diagram illustrates the process of getting an API (or a
selected set of APIs) to be hosted on a Microgateway.

[image: Architecture]
<https://raw.githubusercontent.com/wso2/product-microgateway/master/architecture.png>
Setting up microgateway

This product will include a CLI, the B7a platform distribution and a few
B7a extensions (Endpoints and Filters). The CLI will have two main
responsibilities.

   - Setting up a Microgateway project.
   - Running the Microgateway project.

These two steps will be treated as two phases. One will first complete the
setup phase and move on to the Run phase. The reason for treating them as
phases is to make it possible for developers to take control of the runtime
if and when required. For example, what gets run as default on a
Microgateway is a simple API proxy. If a developer needs to perform some
sort of an integration or change the Ballerina source files for some other
reason, he could engage with the project after the setup phase and do the
required modifications before the runtime is deployed.
Bug Fixes And Improvements in 2.5.0-M1

   - GitHub (Product-Microgateway
   
<https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+is%3Aclosed>
   )

Known Issues

All the open issues pertaining to WSO2 API Manager Microgateway are
reported at the following location:

   - GitHub (Product-microgateway
   <https://github.com/wso2/product-microgateway/issues?q=is%3Aopen+is%3Aissue>
   )

How You Can ContributeMailing Lists

Join our mailing list and correspond with the developers directly.

   -

   Developer List: dev@wso2.org | Subscribe | Mail Archive
   -

   User List: u...@wso2.org | Subscribe | Mail Archive

Reporting Issues

We encourage you to report issues, documentation faults, and feature
requests regarding WSO2 API Manager Micro Gateway through the public API
Manager Micro Gateway Git Repo
<https://github.com/wso2/product-microgateway/issues>.
-- The WSO2 API Manager Team --
<http://harshcreationz.blogspot.com>
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to