Monolithic vs Microservice: How Does the Frontend Integrate?
Learn how frontend integration differs between monolithic and microservice backends, and why gateways/BFFs bridge the gap.
Expected Interview Answer
In a monolithic backend the frontend talks to one deployable service that owns the whole domain, whereas in a microservice backend the frontend must aggregate data from many independently deployed services, usually behind a gateway or BFF that hides that fan-out from the client.
With a monolith, a single API server exposes every resource behind one base URL, one auth model, and one deployment cadence, so a frontend engineer writes one client and rarely worries about cross-service consistency. With microservices, a single screen — say a product page showing inventory, pricing, and reviews — may require calling three or four independently owned services, each with its own schema, versioning, and failure mode. Calling each service directly from the browser multiplies round trips, leaks internal topology to the client, and makes CORS and auth a per-service headache, so most teams introduce an API gateway or a backend-for-frontend to aggregate and normalize those calls into one client-friendly contract. The frontend integration cost of microservices is real — more orchestration, more partial-failure handling, more contract testing — but it buys independent deployability and scaling per service, a tradeoff the monolith does not need to make.
- Monolith: one client, one auth model, simpler cross-resource consistency
- Microservices: services deploy and scale independently of each other
- Gateway/BFF hides service topology and reduces client-side round trips
- Clear ownership boundaries let teams evolve services without frontend rewrites
AI Mentor Explanation
A monolithic backend is like one ground office handling ticketing, catering, and merchandise from a single counter, so a fan asks one person for everything. A microservice backend is like three separate stalls run by different vendors, each with its own queue and payment system, so the fan without a coordinator would have to visit all three separately. A stadium usher acting as a single point of contact collects what the fan needs from each stall and hands back one bag. That usher role is exactly what a gateway or BFF plays for a frontend calling many backend services.
Step-by-Step Explanation
Step 1
Identify per-screen data needs
Map which services a given screen actually needs data from before deciding on an integration strategy.
Step 2
Choose direct calls or an aggregator
For a monolith, call the single API directly; for microservices, route through a gateway or BFF instead of calling each service from the browser.
Step 3
Normalize contracts
The aggregation layer reshapes each service's response into one client-friendly contract, hiding internal service boundaries.
Step 4
Handle partial failures
Decide how the frontend degrades gracefully when one of several aggregated services is slow or down.
What Interviewer Expects
- Clear contrast between single-service and multi-service integration cost
- Mention of gateway/BFF as the standard mitigation for microservice fan-out
- Awareness of partial-failure handling when aggregating multiple services
- Understanding of the tradeoff: monolith simplicity vs microservice independent scaling
Common Mistakes
- Claiming microservices are strictly better without discussing frontend integration cost
- Suggesting the browser call every microservice directly instead of via a gateway
- Ignoring CORS and per-service auth complexity in a direct-call design
- Not mentioning partial-failure/degraded-UI handling for aggregated calls
Best Answer (HR Friendly)
“With a monolith, the frontend talks to one backend for everything, which is simple. With microservices, one screen might need data from several independent backend teams, so most companies put a gateway or a backend-for-frontend in between that collects everything and hands the frontend one clean response, instead of the browser juggling many separate calls.”
Code Example
// Without a BFF: three round trips from the browser
const inventory = await fetch('https://inventory.svc/api/items/42').then(r => r.json())
const pricing = await fetch('https://pricing.svc/api/items/42').then(r => r.json())
const reviews = await fetch('https://reviews.svc/api/items/42').then(r => r.json())
// With a BFF: one call, server aggregates internally
app.get('/bff/product/:id', async (req, res) => {
const [inventory, pricing, reviews] = await Promise.all([
fetch(`https://inventory.svc/api/items/${req.params.id}`).then(r => r.json()),
fetch(`https://pricing.svc/api/items/${req.params.id}`).then(r => r.json()),
fetch(`https://reviews.svc/api/items/${req.params.id}`).then(r => r.json()),
])
res.json({ inventory, pricing, reviews })
})Follow-up Questions
- How would you handle one of three aggregated service calls timing out?
- What is the difference between a BFF and a general-purpose API gateway?
- How does auth differ between calling a monolith and calling multiple microservices?
- How would you version a BFF contract when an underlying microservice changes its schema?
MCQ Practice
1. Why do frontends typically avoid calling each microservice directly from the browser?
Direct browser-to-service calls increase round trips and expose internal service boundaries, which a gateway/BFF hides.
2. What is the primary frontend benefit of a monolithic backend?
A single deployable service means the frontend integrates against one contract instead of many.
3. What role does a BFF play for a microservice-based frontend?
A BFF sits between the frontend and services, collecting and reshaping responses for one client contract.
Flash Cards
Monolith frontend integration? — One client, one base URL, one auth model.
Microservice frontend integration risk? — Multiple round trips and leaked internal topology if called directly.
Standard mitigation for microservice fan-out? — An API gateway or backend-for-frontend aggregating calls.
Tradeoff of microservices for the frontend? — More orchestration cost in exchange for independent service deployability.