generated from coulomb/repo-seed
47 lines
1.3 KiB
Markdown
47 lines
1.3 KiB
Markdown
# Pattern: Backend-for-Frontend
|
|
|
|
Status: seed
|
|
Readiness target: RL2 private beta
|
|
Primary owners: product repos, NetKingdom
|
|
Genesis family: Application/API security
|
|
|
|
## Problem
|
|
|
|
Different UI clients often need different API shapes, but exposing broad
|
|
backend APIs directly to browsers or mobile clients increases token and
|
|
data exposure.
|
|
|
|
## Context
|
|
|
|
Use this pattern for web frontends, mobile clients, admin consoles,
|
|
tenant portals, and agent-facing UI surfaces.
|
|
|
|
## Forces
|
|
|
|
- UI clients need tailored data and workflow APIs.
|
|
- Backend services may expose fields or operations that clients should
|
|
not see.
|
|
- Tokens and sessions need client-appropriate handling.
|
|
- Authorization decisions still need tenant and object context.
|
|
|
|
## Solution
|
|
|
|
Create a client-specific backend layer that mediates session handling,
|
|
data shaping, authorization calls, and downstream API access for one
|
|
frontend class.
|
|
|
|
## Verification
|
|
|
|
- The BFF exposes only client-appropriate operations and fields.
|
|
- Downstream calls include trusted user, tenant, and authorization
|
|
context.
|
|
- Sensitive backend tokens are not exposed to clients.
|
|
- Session and CSRF controls match the client type.
|
|
|
|
## Related Patterns
|
|
|
|
- API Gateway as Security Boundary.
|
|
- Object-Level Authorization Check.
|
|
- Tenant Context Propagation.
|
|
- Schema-First API Security.
|