Create a separate backend service for each frontend application or interface.
Problem
Many applications start as a single app experience, but as requirements and user base grows additional applications are created. Almost always, these apps, even if working on the same data, have a different general purpose - let's say desktop or rich web interface has a rich set of capabilities for data managing, and mobile and tablet experience are focused on data viewing and lite editing. By expanding backend service for use for other frontends, backend service becomes a general-purpose backend, serving sometimes quite different requirements.
Differences between capabilities and requirements of frontends can differ significantly. And even if they are similar enough, the change of one frontend can require changing the others at the same time. Also, different teams can work on different frontends, and they will have to work on the same backend service at the same time, without a clear owner, and perhaps with conflicting requirements.
Solution
Create a separate backend service for each frontend application and interface. Optimize each service independently, without having to worry how changes to one service will affect the others.
The result of this approach is having several smaller, more focused backend services, with clear owners.
- It does not have to be one backend service per one frontend - In many cases, it is ok to have a single backend service for multiple frontends (iOS and Android apps)
- Backend services should be as thin as possible, and focus only on client-specific logic
Related Patterns
- Gateway Patterns
- Backends for Frontends pattern
- Gateway Aggregation pattern
- Gateway Routing pattern
- Gateway Offloading pattern