Skip to main content

UI as Part of Each Microservice

Context​

Microservices are being adopted. The user interface application(s) are of monolithic nature, each governed by a dedicated frontend team.

Problem​

  • Introducing new features or changing/enhancing existing ones requires coordination between the frontend team and the microservice teams, leading to coupling between microservices and the user interface application(s).
    • APIs are not optimally designed for the backend and/or the microservice team, depending on who drives the API.
    • Frequent issues lead to a "we against them" situation between frontend team and microservice teams.

Solution​

Make the user interface (UI) part of the microservice.

This design is a continuation of the microservice paradigm to the frontend, often mentioned in the context of Self-Contained Systems (SCS). If the service cut is vertically well aligned, most communication of the UIs with the backend is facilitated with the owning microservice. Co-locating frontend and backend into the microservice teams' responsibility enables independent evolution, flexibility to manage changes avoiding communication overhead and a higher team autonomy. However, the knowledge required to implement this technique needs to be in the microservice team.

As a consequence there are multiple UIs (potentially, one per microservice) that need to be integrated. We recommend the following more specific UI integration techniques that guide an implementation of this abstract technique:

  • UI Suites when users may see the existence of multiple frontend applications,
  • Microfrontends if the existence of multiple technical frontend applications should be hidden from the user.

Maturity​

Proposed, evaluation needed.

Sources of Evidence​

L8:

  • UIs critical component in microservice architectures
  • not focus of most advocates => usually focus on backend
  • Having monolithic UI can work, but they often inhibit goals of microservices
    • downsides of monolithic architecture still exists
  • modularization of frontends badly needed
    • either associated as part of microservices
    • or as a collaborating entity
  • need independent from web, native, or hybrid UI
  • SCS
    • Variant of microservices
    • include UI, esp. web UI, as part of service
    • rely on frontend integration as much as possible

L16:

  • self-containment => front- and backend
  • each service provide own UI
    • (+) enables independent evolution

L34:

  • microservices: isolation; user interaction operate in the scope of a particular service
  • changes to microservice => user interface propagation
    • UI and microservice should be under control of a single team
      • (+) flexibility to manage changes
      • (+) avoid bureaucratic negotiation on interface changes
  • SOA: UI can be the integration part or services can interact directly
    • Microservices: UI can be integrated into microservice
      • Comparison table: UI part of microservice
    • (+) avoids communication overhead
    • UI may talk to other services, involve data replication instead
  • SCS
    • UI part of microservice, share same code-base
    • Example: Jave EE; multi-module maven project sharing code between UI and microservice; each separately deployable WAR file
    • (+) team is familiar with knowledge
    • (+) full control of changes and change-propagation
    • (+) less overhead since no web services used for given UI scope
    • (-) deal with whole dev stack: UI, middleware, database
    • (+) change => only redeploy SCS and UI, rest not affected
    • need for look-and-feel correlation => unity of system
    • Example workflow with SCS
      • Routing between UIs
      • events to get outside of SCS
      • (+) higher autonomy to perform changes, possibly only involving single team
  • Microservices without UI => changes can influence UI and other teams

L41:

  • Differences to SOA
    • SOA not self-contained with data, UI, persistence tool
    • Interpretation: Microservices (can) have UI with them

L47:

  • joining GUI and backend responsibilities of services => number of services 73 -> 52

LM45:

  • Context: interviews and insights from multiple cases on technologies and sw quality in MSA
  • C6-S10
    • SCS, 20 coarse grained vertically cut services with own UI

Interview E:

  • Context: dedicated frontend teams vs. vertical teams?
  • if possible: always go for vertical teams
    • not everyone has to be full stack developer, but full stack know-how needs to be within team
  • currently observing situation with one frontend team, multiple backend teams => frequent problems leading to a "we against them" situation
    • easier interface situation due to short communication ways, e.g., adding an entity to a response
    • who drives the interface?
      • frequently the backend team: more power, know business, were there before
      • if UX is focused, would make sense to let frontend teams drive the APIs
        • Follows from UX what needs to be part of a call to the backend
        • not necessarily entity driven, could also be a few fragments of entities
    • example: project in stronlgy regulated where UX is less important than being conform to the law quickly
      • => acceptable that users have to do multiple clicks
      • API driven rather driven by backend team