Supercharge your Backend for Frontend with Kotlin
summary
Argues that the winning tradeoff is a BFF per UI screen (or per client) that hydrates and composes multiple downstream services, not a monolithic gateway nor mirrored one-to-one proxies. Recommends Kotlin for mobile BFFs because of null-safety, suspending functions and built‑in concurrency. Insists BFFs stay simple and stateless—no state/no DB/queue—and warns against shared business models and one‑to‑one BFFs; gives the Strangler Fig migration pattern and concrete examples of per‑screen services that reduced client‑backend coupling.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 1:00Frontend backend collaboration
- 3:55Monolithic architecture limits
- 5:43Monolith vs microservices
- 8:12API Gateway partial solution
- 10:15Domain API Gateways drawbacks
- 11:22Backends for Frontend explained
- 12:44True BFF benefits
- 14:09BFF as Strangler Fig
- 15:17Reducing BFF duplication
- 16:41Language for BFF services
- 17:47Kotlin for mobile BFFs
- 18:55BFF anti-patterns
- 20:20Avoid one-to-one BFF
- 21:24Code sharing pitfalls
- 22:50API Gateway + BFF
- 23:34When to adopt BFF
- 24:17Keep BFF simple
related talks
54mGiving the Frontend Only What It Needs, or Why You Need a BFF
40mBFF4EAE: Your Backend's New Best Friend Forever
26mBackend For Frontend: Building APIs w. end user in mind
21mEnhance and improve user experience with BFF
38mBFF vs GraphQL: A critical perspective
28mBackend Engineering for Android Developers
39mBFF, our best friend forever for building lots of frontend apps?
11mFrontend Development With BFF (Backend for Frontend)