Architecture Overview and Deployment Options

The Rapid Enterprise Hub is divided into two high-level components:

1. Management plane
2. Rapid Runtime (Proxy/Gateway)

Management plane

The management plane is used to facilitate API discovery, testing, provisioning, analytics, API definitions, and more.

Rapid Runtime

Rapid Runtime is responsible for proxying API requests, validating request content, asserting access permissions, tracking analytics, and enforcing monetization models.

Deployment options

There are three options for deploying APIs to the Hub:

1. Deploying with Rapid Runtime and third-party gateways (recommended)
2. Deploying only with existing third-party gateways
3. Hybrid deployment

1. Deploying with Rapid Runtime and third-party gateways (recommended)

The simplest deployment uses both the Rapid management plane and Rapid Runtime as a SaaS offering, managed by Rapid. API requests are first sent the Rapid Runtime, then usually forwarded to the API's gateway (such as Amazon API gateway or Apigee). This configuration allows the Hub to host easily all of the enterprise's APIs, control access to those APIs, report usage analytics, and more.

Deploying only with existing third-party gateways

If an enterprise would prefer to not use the Rapid Runtime, existing gateway services can be configured to be used directly in API requests. With this option, usage analytics are not automatically available in Rapid (because Rapid is not included in API requests). Usage analytics can be asynchronously sent to Rapid using the Platform Analytics API.

This approach fully relies on the gateways as the runtime component, so there is no new dependency or networking hop added to the API request flow. Rapid merely acts as a control and visibility component on top of the gateway.

📘

Gateway functionality

In this configuration, Rapid is not involved in the API requests' runtime, so all gateway functionality [transformations, rate limits, quota limits, etc.] is deferred, defined, and enforced on the existing API gateways.

🚧

Monetization

When utilizing only third-party API gateways, monetization of an API is no longer available as a feature. Rapid's monetization functionality is tightly coupled to our Rapid Runtime. The only way to enforce transactional monetization pricing plans from Rapid is by using the Rapid Runtime.

There is a workaround for this:

• Utilizing a third-party gateway integration for any API not requiring monetization, then utilizing the Rapid Runtime for any API requiring monetization (mentioned below in Hybrid deployment).

Hybrid deployment

Integrating with an existing API gateway and the Rapid Runtime are not mutually exclusive options. Some APIs on the Hub can be configured to use the Rapid Runtime and others can be configured to use the API's gateway directly.

For example, this is a useful option when some APIs will not use the Rapid Runtime. Some enterprises may choose to use an existing gateway for all internal APIs and the Rapid Runtime for enforcing monetization of APIs that have been made available to external developers.