About 2 years ago Marktplaats.nl started to build a new platform. We migrated from huge Java-based frontends towards smaller Node.js BFFs (backend-for-frontends). We are close to the next step and adapt a micro-frontends approach. Here I would like to share the outcomes of this quest: what architecture solutions are made, how does Marktplaats.nl run and scale so many BFFs in production, how we grew as a team, educated frontend-developers to write backend code and what were our biggest challenges.

1. 13 Feb 2020
Eugene Fidelin
Node.js BFFs
our way to better/micro
frontends

2. Micro frontends
mFs - an architectural style where independently
deliverable frontend applications are composed
into a greater whole

3. Micro frontends
Cam Jakson, ThoughtWorks

4. How to compose mFs
Without container app
• HTTP server routing to redirect multiple frontends
With container app
• Server-side template composition
• Client-side integration via iframes
• Client-side integration via JavaScript
• Client-side integration via Web Components

5. Micro frontends and BFFs
BFF – a pattern where each frontend application
has a corresponding backend whose purpose is
solely to serve the needs of that frontend
• authentication/authorization
• a/b experiments setup
• data fetching and aggregation
• server-side rendering

6. Micro frontends and BFFs
Cam Jakson, ThoughtWorks

7. Where we were 2 years ago
� Huge monolithic frontends tightly coupled with backend services
� No clear ownership of the frontend codebase
� Business logic in the view layer
� No support for multiple tenants and languages
� Fragile builds because of huge amount of e2e tests
� Very long time to market
� Very old JavaScript stack
� Minimal developer happiness

8. Where we are now
✅ > 20 small BFFs tailored to a specific step(s) of a user journey
✅ Each BFF is owned by a specific team
✅ Backend APIs don’t leak business logic to BFFs
✅ Support for multiple tenants and languages
✅ Stable builds due to more unit and integration tests and less e2e tests.
✅ Short time to market
✅ Modern JS and frameworks on the server and client
✅ Higher developer happiness and productivity 

9. Architectural changes

10. Zoom into BFF

11. Developer experience
• BFFs can easily run locally, no hard dependencies on other services
• Able to use APIs from any environment: int, demo, dev-tenant or local
• Frontend developers write both server and client
• Swagger is the contract between BFFs and APIs
• Plenty of ready-to-use internal libraries and components
• Styling is provided by Design System

12. Code share and reuse
• Design System
• common styles, fonts and images
• React components
• atoms and molecules (Buttons, Dialogs, …)
• organisms (Header & Footer)
• Server instrastructure code
• middlewares
• API clients
• HTML rendering
• metrics, logging and tracing

13. Testing strategy
Jest, react-test-renderer
Mocha, Chai, Sinon
Jest snapshots
Cypress.io (wip)
Seleniume2e
Mock API
QATestLab
Stage of the
Docker build

14. Build and deploy
• Shared build config (Webpack, Babel, eslint, …)
• Automated dependecy updates
• Automated builds for master and PR
• Shared multi-stage Docker build
• Feature switches and a/b switches
• Canary releases
• One-click production rollback

15. Scale and performance
• Frontend app uses only its own BFF (1 exception)
• CDN to serve static resources
• SSR only for bots and app shell
• Run calls to BE APIs in parallel
• Smart load balancing of BE API calls
• Keep BFFs small
• Scale by increasing number of instances

16. Alerting & Monitoring
Server:
• Access and error logs in Kibana
• Metrics in Graphana
• Node.js event loop and garbage collector
• Response status and latency
• Tracing in Jaeger
• Profile and monitor distributed platform
Client:
• Error logs in Sentry

17. How we make decisions
ADRs – capture an important architectural decisions made along with its
context and consequences.
TechRadar – list of technologies we observe: currently used, tested,
under research or put on hold. The list has four major categories:
Techniques, Tools, Platforms, Language & frameworks.
Frontend guild – supports close collaboration and knowledge sharing
among all frontend developers.

18.  Pros
+huge improvement on time-to-
market for product features
+smaller, more isolated and
maintainable codebases
+more scalable organisation with
decoupled, autonomous teams
+the ability to update or rewrite
parts of the frontend in a more
incremental fashion
−duplication of dependencies and
increasing the number of bytes
the users must download
−team autonomy can lead to
platform fragmentation and
inconsistent codebases
−struggle to keep all frontends
up-to-date
−CI/CD pipeline performance
becomes a bottleneck
 Cons

19. Usefull links
• Micro Frontends (Cam Jackson)
• Pattern: Backends For Frontends (Sam Newman)
• Micro-frontend Architecture in Action with six ways (Phodal Huang)
• Micro-frontends resources (Luca Mezzalira)

20. Thank you!
Eugene Fidelin
linkedin.com/in/eugef
medium.com/@EugeneFidelin