Architecture Overview and Deployment Options
The Rapid Enterprise Hub is divided into two high-level components:
- Management plane
- Rapid Runtime (Proxy/Gateway)
Management plane
The management plane is used to facilitate API discovery, testing, provisioning, analytics, API definitions, and more.
| Management Plane Responsibility |
|---|
| Storing metadata about APIs in the Enterprise Hub |
| Storing information about users with access to the Enterprise Hub and connecting to existing SSO / LDAP systems |
| Serving the user interface that developers interact with to discover and view API details |
| Generating reports on API usage |
Rapid Runtime
Rapid Runtime is responsible for proxying API requests, validating request content, asserting access permissions, tracking analytics, and enforcing monetization models.
| Rapid Runtime Responsibility |
|---|
| Enforcing gateway functionality: Authorization, rate limits, quota limits, transformations, etc. |
| Infinitely horizontally scalable with the ability to be deployed in multiple data centers. |
| Is independent of the management plane. The Rapid Runtime still works even if it can't communicate with management plane. |
Deployment options
There are three options for deploying APIs to the Hub:
- Deploying with Rapid Runtime and third-party gateways (recommended)
- Deploying only with existing third-party gateways
- 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.
Updated 11 months ago