Technical note
Microfrontends + BFF in regulated banking
How to decouple frontend teams without fragmenting the user experience in an MEP project with legacy Oracle services.
Context
In high-criticality banking projects, multiple frontend teams need to move in parallel on a legacy backend (Oracle, heterogeneous SOAP/REST services). The challenge isn't just technical: there's compliance, fixed deadlines, and zero tolerance for regressions in money flows.
Why microfrontends
Microfrontend architecture lets each squad own its UI domain (onboarding, simulation, confirmation) with independent deploys. The cost is coordination: shared design system, communication contracts between shells, and versioning of common dependencies.
The BFF role
The Backend-for-Frontend layer in Node.js acts as a translator: aggregates calls to multiple Oracle services, normalizes errors, adapts payloads to the shape React needs, and hides backend complexity from the client. A single typed entry point with TypeScript reduces integration bugs.
Applied lessons
We delivered in 4 months by prioritizing typed contracts between BFF and microfrontends, a minimal host shell, and cross-team code review. The key was not over-engineering: microfrontends where team coupling justified it, BFF where Oracle orchestration required it.
Takeaways
- BFF as orchestration layer, not a second monolithic backend
- Shared TypeScript contracts across layers
- Minimal agreed design system before parallelizing teams
- Incremental delivery by business flow, not by technical layer