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. Consider 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 strongly 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