apiresteda

Event Driven Architecture - backend services with two interfaces (interface types)

Several articles about Event Driven Architectures recommend an event broker (for example Kafka via topics) to integrate backend services and in addition RESTful interfaces for these backend services (here an example from Guido Schmutz: Building event-driven (Micro)Services with Apache Kafka, 2019, p. 19).

enter image description here

The RESTful interfaces provide access for GUI and external services. These GUI and external services access the RESTful services via an API Gateway. So each backend service has two interface types: a RESTful interface and a channel interface (event broker).

My question is: what are the advantages of providing RESTful API in addition / in parallel to the integration of backend services via an event broker? The reason for this question is that the event broker could provide the same capabilities (synchronous request response).

Solution

  • You're correct, the event broker could provide the same capability: one of the purposes of an API Gateway is to perform 'protocol translation'.

    The advantage of using a RESTful API for your 'frontline' microservices depends significantly on your specific situation. Interestingly, there is nothing stopping you from providing a RESTful API via an event broker (REST is explicitly protocol agnostic). However, if by RESTful you mean over HTTP, then there may be benefits to using this protocol. As an example, if you intend for your microservices to be consumed by 'other' clients, then (despite the rise in event-driven architecture) HTTP is still objectively the most ubiquitous protocol in existence.

    This is very subjective, but 'request-response' is an afterthought for event-based frameworks. If you want to follow that model, you might be best served using frameworks and technologies that are designed for it.

    As you mentioned, you can of course provide a RESTful API in parallel. If this is appropriate really depends on your use-cases.

    My two cents: use whatever architecture is easiest and makes the most sense for you behind your API Gateway. The Gateway provides abstraction, so if the approach you take doesn't work out, you can change with little impact.