Pattern Sections
Pattern: Frontend Integration
a.k.a. Vertical Integration, Frontend-to-Backend Integration, Frontend API, North-South Connectivity
Context
An architectural decision has been made to organize a system into physical tiers. The frontend that is responsible for displaying and controlling the end-user interface is physically separated from the backend that is in charge of processing and data storage.
Due to physical separation, the frontend cannot invoke the backend directly via local, programming language- or operating system-internal API calls; remoting is required to load domain data from the backend and invoke actions in it once the user input has been compiled.
Problem
How can client-side end-user interfaces that are physically separated from server-side business logic and data storage be populated and updated with computing results, result sets from searches in data sources, and detailed information about data entities? How can application frontends invoke activities in a backend or upload data to it?
How to independently develop one or more client-side user interfaces (for one or more platforms) while keeping these decoupled from the backend server-side implementation?
Forces
Important high-level forces and desired qualities in frontend-to-backend integration include:
- Business needs
- Client developer convenience vs. risk and cost considerations (including the level of coupling)
- Security and data privacy concerns
While these forces and qualities are rather general, conflicts between them and their incarnations in the frontend and the backend may arise, and differ from those in other development and integration contexts.
Pattern forces are explained in depth in the book.
Solution
Let the backend of a distributed application expose its services to one or more application frontends via a message-based remote Frontend Integration API.
Sketch
A solution sketch for this pattern from pre-book times is:
Example
In our insurance case study called Lakeside Mutual,1 the interface between the customer self-service frontend and its backend provider is an example of Frontend Integration. See the readme for an API and service dependency overview:
The interface between the Customer Management Rich Internet Application (RIA) and the interface layer of the Policy Management backend is another example of Frontend Integration: JavaScript running in the browser is the API client; it obtains the policy (contract) and quote request (offer) data from the backend, displays it, and sends change requests back to the API provider.
Are you missing implementation hints? Our papers publications provide them (for selected patterns).
Consequences
The resolution of pattern forces and other consequences are discussed in our book.
Known Uses
Most software systems require at least one user interface (e.g., for application management) and many projects are focused on such effort, e.g. to expose existing backend functionalities to new users, to existing users over new channels, or to replace technically obsolete existing user interfaces. Hence, many known uses for this pattern exist; we only mention a few here.
The Terravis integration project develops a Web portal that uses external APIs to integrate with the process layer but internally uses own, private APIs to integrate the user interface deployment units with each other (see Lübke and Lessen (2016)).
A major Swiss bank distinguishes its frontend APIs from its backend APIs. See IEEE Software/InfoQ article “Fifteen Years of Service-Oriented Architecture at Credit Suisse” Murer and Hagen (2014) as well as “Managed Evolution” (Murer, Bonati, and Furrer (2010)).
The Dynamic Interface described in Brandner et al. (2004) also applies this pattern by exposing 1000+ core backing backend functions such as “give me a total retail banking customer overview for all last names starting with Z” to API clients such as online baking systems and branch office applications.
More API examples from finance and banking can be found in the openbankingtracker. An example of a country-wide initiative is the Open Banking Project in Switzerland.
More Information
Related Patterns
This pattern has one sibling Backend Integration; other patterns in the Foundation category deal with API visibility (Public API, Community API, Solution-Internal API).
The Backends for Frontends (BFF) pattern describes channel-specific “edge service APIs” specifically designed for Frontend Integration. Note that usage of the pattern requires the existence of channel-neutral backend APIs as per Sam Newman’s pattern description.
The API Gateway pattern can be used to decouple API clients in the frontend and API providers in the backend, for instance with respect to security management (but also service granularity).
The Two-Tier Cloud Application pattern and the Three-Tier Cloud Application pattern in Fehling et al. (2014) make the need for Frontend Integration APIs evident; the same holds for the various application components patterns in that book (because if physically distributed, these components rely on APIs to be able to communicate with each other).
Other Sources
MDSL has a pattern “Decorator” for this pattern; an API can be classified as supporting Frontend Integration.
References
Lakeside Mutual is a fictitious insurance company invented by the authors. Its systems comprise several microservices to demonstrate the patterns in action. It can be found at https://github.com/Microservice-API-Patterns/LakesideMutual.↩︎