Channel Architecture & API Styles

A summary of existing decisions on Channel Architecture and API Styles.

Problem Description

It is unclear which API style should be used, and where, in Ebury 2.0 Channels.

Background

Ebury 2.0 microservices will expose Ebury data to users through channels: EBO, BOS 2.0, and Ebury API. There are several RFCs in this area but no single RFC draws them together into a complete definition.

Solution

Current Near Term Target Architecture

Notional Future Target Architecture

API Gateways

Channel clients must consume data via gateways:

• "third-party" clients should use Kong API Gateway
• "first-party" clients should use Bosporus.

Each gateway provider satisfies the same set of requirements:

1. Authentication
2. Authorisation
3. Caching
4. Rate limiting
5. Monitoring
6. Logging

Each gateway operates within a slightly different set of constraints, i.e. internal vs external clients.

Each Ebury 2.0 microservice may serve all, some or none of the gateways.

Internal Clients Gateway API: GraphQL

Clients: BOS 2.0, in the future EBO

The gateway is Bosporus, which exposes a GraphQL style API¹.

These clients must consume Ebury data via GraphQL.

A new GraphQL Governance group with representatives from users, Product, UI Engineering and Data Engineering will oversee schema design. (The beginnings of this initiative can be found in the slack channel #graphql-schema-design)

User Authentication & authorization / Identity and Access Management (IAM) should be managed by Keycloak. BOS 2.0 must use Google as an identity provider².

Note: It is possible that in the future EBO will consume this API rather than the REST style API.

Third-Party Clients Gateway API: REST

Clients: 3rd parties & EBO

The API gateway is Kong, which exposes a REST style API⁴

These clients must interface with Ebury data using a REST style API.

Ebury 2.0 Microservices with Channel/Gateway Clients

Ebury 2.0 microservices require APIs where they need to expose data to gateways for Channel clients.

It is recommended that services expose APIs as gRPC³ (or GraphQL¹ if it makes more sense) or HTTP API⁵ or propose a new API style via RFC and update this document.