Infrastructure Components
Components are a set of resources used to onboard backing infrastructure services into Catalyst so they can be used by the various APIs to perform work.
The majority of supported Catalyst APIs will depend on the existence of at least one component to a backing infrastructure service:
- Pub/Sub API: Message broker
- State API: Key/Value data store
- Workflow API: Workflow data store
- Bindings API: External service to invoke or to receive events from
Catalyst supports connecting to many different cloud services in addition to providing Diagrid-hosted services: Diagrid K/V Store and Diagrid Pub/Sub.
Overview
To understand the power of components, let's consider the scenario of application state management with Redis. Traditionally, a developer would need to import a vendor-specific Redis SDK and author complex plumbing code to configure operations against their cloud-hosted Redis provider of choice. Should the developer ever wish to change the backing state store, an application rewrite is almost inevitable.
Alternatively, the developer could leverage the Catalyst State API for a code-agnostic, vendor-neutral approach to state management, referencing a component and allowing Catalyst to broker the connectivity to the underlying infrastructure resource.
The complexity of the code is significantly reduced, and the developer now has the freedom to switch to another state implementation without changing any application code. In addition, the developer gets end-to-end observability from the application code to the infrastructure layer without any instrumentation, and resiliency policies out-of-the-box for handling transient network failures.
Establish infrastructure connectivity
External cloud services
If you have existing cloud services you'd like to use with the Catalyst APIs, you can create an component by providing the following information:
| Settings | Description |
|---|---|
| Type | API related to specified component i.e Pub/Sub, Bindings |
| Target | The backing infrastructure resource you want to onboard to Catalyst. See a list of supported component targets |
| Authentication | The method through which Catalyst will establish a connection to your target. |
In addition to the above, each component type will have required metadata items which must be provided to establish the infrastructure connection. Optional configuration metadata can also be used to further configure how the target service operates behind the scenes. For a guide on creating external components, see the Create External Components guide.
Diagrid Services
To simplify your experience provisioning infrastructure services, Catalyst provides backing services for both the Pub/Sub and Key/Value APIs which can be easily provisioned at project creation time.
Like any infrastructure services in Catalyst, Diagrid K/V Store and Diagrid Pub/Sub will also have associated component resources. Upon creating a Diagrid Service, a default component of the same name will be created for use with the Catalyst API. You can configure additional custom components for Diagrid Services in addition to the default component that is created.
Default components cannot be deleted directly; To delete a default component, you must delete the Diagrid infrastructure service first.
Limit component access
By default, a component can be used by any App ID- and by extension any connected application- in the same project when making API calls. In order to limit which App IDs can use a given component, you can configure component scopes.
Access scopes provide a way to restrict which applications can utilize a component and the underlying infrastructure it represents. Once scopes are applied, a component can only be used in API calls that originate from allowed App IDs.
Configure resiliency
When creating or updating a component, you have the option to enable a set of default resiliency policies. Depending on the API you are using, resiliency policies may be applied to all outbound requests made from an App ID to a backing component resource and/or all inbound requests made from your component resource to your App ID . In the event of call failures and transient errors, the configured policies would be enforced, without the need for you to write any resiliency code in your application itself.
The same three resiliency policies are available for both outbound and inbound operations, and you can choose which you want to enforce.
Outbound operations are calls from your App ID to the backing component resource to accomplish tasks like:
- Persisting or retrieving state
- Publishing a message to a backing Pub/Sub broker
- Invoking an output binding
Inbound operations are calls from your App ID to your external application, such as:
- Pub/Sub subscriptions when delivering a message
- Input bindings
The below policies can be enabled for a given component:
-
Timeout: Early-terminate long-running operations that exceed 10s.
-
Retry: Retry failed operations
Setting Description policy Constant back-off and retry interval duration 5s between retries maxRetries 5 retries maximum -
Circuit Breaker: Shut off traffic to the impacted application when certain criteria is met to avoid flooding
Setting Description trip After 5 consecutive failures, the CB will trip and become open timeout 20s after the CB is tripped, it will switch to half-open interval 5s, meaning the CB clears its internal counts after 5s maxRequests 1 request will be allowed to pass through when the CB is half-open and recovering from failure
Only Pub/Sub components will make use of both outbound and inbound policies.