Skip to main content

Independent Choice of Communication Technology

Context​

The system is split into multiple microservices with corresponding APIs. There is at least one client type (e.g. browser app, native app, ...) that wants to use the APIs of the system.

Problem​

  • The internal API does not fit the purpose for communication with external systems (e.g., internal publish-subscribe via AMQP)

Solution​

Choose the communication technology for the interaction with clients independently from the internally used technology for communication between microservices.

If such a discrepancy between internal and external communication technology arises, there are two possibilities:

  • Each service has an internally and an externally directed API. The external API technology has then to match the clients' needs.
  • Implement the externally directed API in a dedicated facade that maps the communication to the internally used communication technology, e.g., via an API Gateway Facade.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L6:

  • Context: DIMMER platform for IoT devices and their meta-data
  • Different services (Resource Catalog, Semantic Datastore) with each their own datastore technology
    • Have different kinds of API (REST, SPARQL) optimized for their client (Mobile App, Semantic Web Client)
    • Between services: RabbitMQ as pub-sub middleware between microservices
  • Additionally, IoT Data Gateway for high-level API for different kinds of consumers

L37:

  • System that uses REST for communication with clients
  • pub-sub to notify clients about subscribed events
  • SDK makes internal data structure available to external clients in a language independent way

L41:

  • Internal communication: RabbitMQ for choreography, no direct API calls
    • low coupling, no interfaces to violage
  • Communication with external systems via other paradigms (proprietary, future: REST)

L53:

  • Open questions
    • Should we use REST everywhere?
    • Use/create a standard service level protocol (e.g., HTTP) or accomodate different protocols?

LM48:

  • Context: microservice migration describes an examples project (FX Core) and compares back to monolith
  • System communicates with external systems via other paradigms as proprietary protocols or REST APIs in the future
    • does not compromise internal system complexity

Interview E:

  • They use REST for communication between UI client and backend
  • Very rarely seen pub-sub between UI client and backend
    • it gets more complex if you don't really need it
    • only makes sense if you really need it