Add Backends For Frontends (BFF) pattern (#300)#3543
Conversation
Implements the BFF pattern with two client-specific gateways (MobileBff, DesktopBff) aggregating shared downstream services (AuthService, CartService, OrderService, SupplierService) into client-tailored response shapes. Closes iluwatar#300
|
⏳ Analyzing changes in this PR... ⏳ This might take a few minutes, please wait 📥 CommitsAnalyzing changes from base (
The service is looked up by product name throughout the codebase, not 📁 Files being considered (2)➕ backends-for-frontends/src/main/java/com/iluwatar/bff/service/SupplierService.java (1 hunk) autogenerated by presubmit.ai |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #3543 +/- ##
============================================
+ Coverage 83.24% 83.29% +0.05%
- Complexity 4025 4052 +27
============================================
Files 1060 1074 +14
Lines 14246 14339 +93
Branches 686 689 +3
============================================
+ Hits 11859 11944 +85
- Misses 2100 2107 +7
- Partials 287 288 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
The service is looked up by product name throughout the codebase, not an actual product ID as the previous naming implied.
Summary
Closes #300
Implements the Backends For Frontends (BFF) pattern as a new module,
backends-for-frontends. Two client-specific gateways —MobileBffandDesktopBff— sit in front of a shared set of downstream microservices(
AuthService,CartService,OrderService,SupplierService) and eachaggregates only the services its own client needs, reshaping the result into
a response tailored to that client:
MobileBffcalls Auth + Cart + Order → returns a leanMobileDashboardResponsesuited to a phone screen.
DesktopBffcalls Auth + Order + Supplier → returns a richerDesktopDashboardResponsewith back-office detail a mobile client never needs.This satisfies the issue's acceptance criteria: distinct client-specific backends,
data aggregation from multiple downstream services per BFF, and an optimized,
purpose-built API for each client.
What's included
Product,CartItem,User,Order,SupplierRecord)real microservices
ClientBff<T>contract +MobileBff/DesktopBffimplementationsApp.javademonstrating both BFFs against the same useretc/backends-for-frontends.png+.urm.puml), referencedfrom the README
Verification
mvn -pl backends-for-frontends -am clean test— all tests passingmvn checkstyle:check@validate -pl backends-for-frontends -am— 0 violationsmvn spotless:check -pl backends-for-frontends -B— cleanmvn clean install, module excluded from unrelated flakesbelow) — green
Notes for reviewers
full reactor build and confirmed not caused by this change by reproducing
them in isolation on a clean checkout:
rate-limiting-pattern'sTokenBucketRateLimiterTest.shouldRefillTokensAfterTimeis timing-flaky.
commander's test suite can hitOutOfMemoryError: unable to create native threadlocally depending on OS thread limits, unrelated to this module.WhitespaceAround'sallowEmptyConstructors/allowEmptyTypesproperties are unset (defaultfalse) in the current Checkstyle config, which conflicts with Spotless/Google Java Format's formatting of empty
{}bodies. This affects any recordwith a fully empty body — I counted at least 16 other existing modules with
the same latent construct, which only avoid failing because Checkstyle isn't
bound to the
installlifecycle. I worked around it locally in this module's6 records by giving each a minimal documented compact constructor rather than
a bare empty body, but didn't touch the shared Checkstyle config or any other
module — happy to open a separate follow-up issue for that if it's useful.