Skip to content

Latest commit

 

History

History
136 lines (94 loc) · 5.26 KB

README.md

File metadata and controls

136 lines (94 loc) · 5.26 KB
Raw

Microgateway Action for common microgateway patterns

godoc

Microgateway Action

This is a Microgateway Action which supports several common microgateway patterns , key ones highlighted below:

🔀 Conditional, content-based routing
🔐 JWT validation
⏳ Rate limiting
🔌 Circuit breaking

Quick Start

With Flogo CLI

The Flogo CLI takes a Flogo application defined in JSON and produces an executable application. The Flogo CLI can be installed from here. Next, follow the instructions here to build your first Microgateway Flogo application.

With Flogo API

The Flogo API allows developers to define Flogo applications in the Go programming language without using the Flogo CLI. You can get started by cloning this repo:

git clone https://github.com/project-flogo/microgateway.git

and then following the instructions here to build your first Microgateway Flogo application. Documentation for the Flogo Microgateway API can be found here.

Development

Testing

The commands supported include:

  • clean
  • build
  • generate
  • test
  • test-short

To run tests issue the following command in the root of the project:

go run build/build.go test

It cleans the cache, and runs all the tests in your directory. The tests should take ~2 mintues. To re-run the tests first run the following:

To skip the integration tests use the test-short command:

go run build/build.go test-short

To know the USAGE and the list of commands supported:

go run build/build.go help

Resource

Schema

The JSON Schema for the Microgateway resource can be found here.

Sections

Services

A service defines a function or activity of some sort that will be utilized in a step within an execution flow. Services have names, refs, and settings. Any Flogo activity works as a service. Services that are specific to a microgateway can be found here. Services may call external endpoints like HTTP servers or may stay within the context of the gateway, like the js activity. Once a service is defined it can be used as many times as needed within your routes and steps.

A service definition looks like:

{
  "name": "PetStorePets",
  "description": "Get pets by ID from the petstore",
  "ref": "github.com/project-flogo/contrib/activity/rest",
  "settings": {
    "uri": "http://petstore.swagger.io/v2/pet/:petId",
    "method": "GET"
  }
}

Steps

Each microgateway is composed of a number of steps. Each step is evaluated in the order in which it is defined via an optional if condition. If the condition is true, that step is executed. If that condition is false the execution context moves onto the next step in the process and evaluates that one. A blank or omitted if condition always evaluates to true.

A simple step looks like:

{
  "if": "$.payload.pathParams.petId == 9",
  "service": "PetStorePets",
  "input": {
    "method": "GET",
    "pathParams.id": "=$payload.pathParams.petId"
  }
}

As you can see above, a step consists of a simple condition, a service reference, input parameters, and (not shown) output parameters. The service must map to a service defined in the services array that is defined in the microgateway resource. Input key and value pairs are translated and handed off to the service execution. Output key value pairs are translated and retained after the service has executed. Values starting with = are evaluated as variables within the context of the execution. An optional halt condition is supported for steps. When the halt condition is true the execution of the steps is halted.

Responses

Each microgateway has an optional set of responses that can be evaluated and returned to the invoking trigger. Much like routes, the first response with an if condition evaluating to true is the response that gets executed and returned. A response contains an if condition, an error boolean, a code value, and a data object. The error boolean dictates whether or not an error should be returned to the engine. The code is the status code returned to the trigger. The data object is evaluated within the context of the execution and then sent back to the trigger as well.

A simple response looks like:

{
  "if": "$.PetStorePets.outputs.data.status == 'available'",
  "error": false,
  "code": 200,
  "data": {
    "body.pet": "=$.PetStorePets.outputs.data",
    "body.inventory": "=$.PetStoreInventory.outputs.data"
  }
}

Example Flogo JSON Usage of a Microgateway Action

An example of a basic gateway can be found here.

Example Flogo API Usage of a Microgateway Action

An API example can be found here.