Tetrate Service Bridge API (next)

Applications are logical groupings of services that are related to each other, typically within a trusted group. A common example are three tier applications composed of a frontend, a backend and a datastore service.

Applications are often consumed through APIs, and a single Application can expose one or more of those APIs. These APIs will define the hostnames that are exposed and the methods exposed in each hostname.

apiVersion: application.tsb.tetrate.io/v2
kind: Application
metadata:
  name: three-tier
  organization: myorg
  tenant: tetrate
spec:
  workspace: organizations/myorg/tenants/tetrate/three-tier

Optional FQN of the Gateway Group to be used by the application. If configured, this gateway group will be used by the application. If no namespaces are configured and no existing gateway group is set, a new gateway group claiming all namespaces in the workspace (*/*) will be created by default. All Ingress Gateway resources created for the APIs attached to the application will be created in the application's gateway group.

Optional list of services that are part of the application. This is a list of FQNs of services in the service registry. If omitted, the application is assumed to own all the services in the workspace. Note that a service can only be part of one application. If any of the services in the list is already in use by an existing application, application creation/modification will fail. If the list of services is not explicitly set and any service in the workspace is already in use by another application, application creation/modification will fail.

API objects define a set of servers and endpoints that expose the business logic for an Application. APIs are attached to existing Applications to configure how the features exposed by the different services that are part of the Application can be accessed.

The format used to define APIs is based on the OpenAPI v3 spec. Users can attach OpenAPI documents to the applications, and Service Bridge will generate all the configuration that is needed to make the APIs available. Service Bridge also provides a set of custom extensions to the OpenAPI spec that can be used to further customize the APIs in those cases where the standard OpenAPI properties are not sufficient.

The following example shows how an API can be attached to an existing application:

apiversion: application.tsb.tetrate.io/v2
kind: API
metadata:
  organization: my-org
  tenant: tetrate
  application: example-app
  name: ezample-app-api
spec:
  description: An example OpenAPI based API
  workloadSelector:
    namespace: exampleapp
    labels:
      app: exampleapp-gateway
  openapi: |
    openapi: 3.0.0
    info:
      title: Sample API
      description: An example API defined in an OpenAPI spec
      version: 0.1.9
      x-tsb-service: sample-app.sample-ns   # service exposing this api
    servers:
    - url: http://api.example.com/v1
      description: Optional server description, e.g. Main (production) server
    - url: http://staging-api.example.com
    paths:
      /users:
        get:
          summary: Returns a list of users.
          description: Optional extended description in CommonMark or HTML.
          responses:
            '200':    # status code
              description: A JSON array of user names
              content:
                application/json:
                  schema: 
                    type: array
                    items: 
                      type: string