Marktplaats is the largest online marketplace in the Netherlands, receiving over 8 million monthly visitors. The company transitioned from 3 large monolithic frontends tightly coupled to backend services to over 25 loosely coupled microservices with corresponding backend for frontend services. This improved time to market for features, code maintainability, and developer autonomy and happiness. Key aspects of their architecture include infrastructure for routing requests to frontends, a build process for deploying frontends as packages, extensive testing, and monitoring of performance and errors.

1. Node.js BFFs -
our way to the
better/micro
frontends
1
Eugene Fidelin

2. Marktplaats Facts & Figures
2
With over 8 million unique visitors monthly and 18.7 million live ads at any given time,
Marktplaats is the largest trading platform in the Netherlands
New ads per day
350K
Visits per day
6.5M
Hits per day
(~4000 per second)
300-400M
Connected ads per day
100K

3. mFs - an architectural style where
independently deliverable
frontend applications are
composed into a greater whole
Cam Jakson, ThoughtWorks

4. Micro frontends livecycle
4
Cam Jakson, ThoughtWorks

5. How to compose micro frontends
Infrastructure
Have an HTTP server that
routes requests to multiple
frontends.
Runtime
Have a controller app
running on the browser
(and/or server) which
selects which script/app to
load.
Build time
Deploy components/apps
as npm packages, and use
them during the build time.
5

6. BFF – a pattern where each
frontend application has a
corresponding backend whose
purpose is solely to serve the
needs of that frontend
Cam Jakson, ThoughtWorks

7. Micro frontends and BFFs
Cam Jakson, ThoughtWorks
7

8. 8
BFF is a best friend to the micro frontend that enables:
● Customizable API authentication/authorization
● Flexible a/b experiments setup
● Highly tailored data fetching and aggregation
● Server-side rendering on demand
Micro frontends and BFFs

9. 9
● 3 huge monolithic frontends tightly coupled with
backend services
● No clear ownership of the frontend codebase
● Business logic leaking into the view layer
● No support for multiple tenants and languages
● Fragile builds because of huge amount of e2e tests
● Very long time to market
● Old and legacy JavaScript stack, JSP on the server
● Minimal developer happiness
Where we were 3 years ago

10. 10
● > 25 small, loosely coupled but highly aligned BFFs
● Each BFF is owned by a specific team and tailored to a
specific step(s) of a user journey
● Downstream APIs don’t leak business logic to BFFs
● Support for multiple tenants and languages
● Stable builds due to more integration and unit tests and
less e2e tests
● Shorter time to market
● Modern JS, TS and frameworks on the server and client
● Higher developer happiness and productivity
Where we are now

11. Architectural changes
11

12. Design of the Web BFF
12

13. 13
● Easy to run BFFs locally, no hard dependencies on other
services
● Locally BFF can use APIs from any other environment
● Frontend developers write both server and client code
● Swagger is the contract between BFFs and APIs
● Typescript allows to share types between server and
client side code
● Plenty of ready-to-use internal libraries,
Design System provides common components and styles
● Clear ownership and PR reviews agreements
Developer experience

14. Code share and reuse
Client side code
• Common styles, fonts and images
• React components (Buttons, Inputs, …)
• React applications (Header, Login
dialog, ..)
• Type definitions
Server infrastructure code
• Middlewares
• API clients
• HTML rendering
• Metrics, logging and tracing
• Type definitions
14

15. Testing trophy
15
Selenium
Jest, Supertest,
Cypress.io (wip)
Jest,
@testing-library/react
Stage of the
Docker build
Eslint,
Typescript
Kent C. Dodds, TestingJavaScript.com

16. Build and deploy
Build
• Shared build config (Webpack, Babel,
eslint, tsconfig)
• Shared multi-stage Docker build
• Automated dependency updates with
Renovate
• Automated builds for master and PR
• Automated security scans by Snyk.io
• Quality checks with SonarQube
Deploy
• Feature switches and a/b switches
• Canary releases
• One-click production rollback
• Overview of dependencies used on
production
16

17. 17
● Each frontend app uses only its own BFF
● Keep BFF small and scale by increasing number of
instances
● SSR only for bots, app shell and user-critical content
● Experimenting with offloading SSR to a separate thread
● Calls to the downstream APIs are run in parallel
● Smart load balancing of API calls
● CDN to serve static resources with cache to reduce
downloaded bytes
Scale and performance

18. Alerting and monitoring
Client
• Error logs in Sentry
• Performance tests and real user
monitoring by Speedcurve
Server
• Access and error logs in Kibana
• Metrics in Graphana
• Node.js event loop, memory
usage, garbage collector
• Response status and latency
• Tracing in Jaeger
• Profile and monitor distributed
platform
18

19. Pros and Cons
Pros
• Huge improvement of time-to-market
for product features
• Smaller, more isolated and maintainable
codebases
• Good fit for the scalable organisation
with decoupled, autonomous teams
• Ability to update or rewrite parts of the
frontend in a more incremental fashion
Cons
• Duplicate dependencies and increasing
the number of bytes the users
downloads
• Team autonomy leads to platform
fragmentation and inconsistent
codebases / APIs
• Extra effort to keep all frontends
up-to-date
• CI/CD pipeline performance becomes a
bottleneck
19

20. How we make decisions
Frontend Chapter
Supports close
collaboration and
knowledge sharing among
all frontend developers.
Tech Radar
List of Techniques, Tools,
Platforms, Language &
frameworks we observe:
currently used, tested, under
research or put on hold.
ADRs
Capture an important
architectural decisions
made along with its context
and consequences.
20

21. 21
1. Adopt runtime composition by Webpack Module
Federation
2. Make it work nicely together with React SSR
3. Build a PoC to collect metrics, learn, pinpoint risks and
obstacles
4. Achieve the following goals:
● make React app to be the minimal delivery artifact
instead of a complete page
● be able to update the shared features (like header)
with a single deploy
Plans for the future

22. 22
● 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)
● How To Convert a Huge Frontend Monolith to a
Micro-frontend (Dream11 Engineering)
● Building Micro-Frontends (book by Luca Mezzalira)
Useful links

23. Thank you
23
Eugene Fidelin
Frontend Architect
Marktplaats.nl | Adevinta
linkedin.com/in/eugef
medium.com/@EugeneFidelin