The BFF as a thin adapter
The one axis the owner already owned — backend — is the smallest repo in the project: a 12-commit FastAPI BFF (backend-for-frontend — a thin server owned by the client's team, shaped to exactly one frontend's needs). That is not idleness; it is the project's most senior architectural judgment: spend your strong axis sparingly, exactly at the seams you don't control, and BaaS everything else away (BaaS = backend-as-a-service; here Appwrite, self-hosted, took identity/DB/storage).
What the thin layer actually does — all three jobs are "adapt the uncontrolled":
- Dual-identity bridge: signup/login write to both the partner's API (SuperRoute) and Appwrite in one call (
routes/auth.py—third_api_signup+ AppwriteUsersside by side); the app sees one auth, two systems stay consistent. - Partner-API decontamination:
third_api.py's_flattennormalizes the third party's responsemessage— "possibly a string / list / nested list / object" — into a predictable shape at the boundary, so the partner's format drift never reaches the app (matching commit: "Improve API response format handling", 2025-06-09). HTTPS enforced at startup — the boundary refuses to exist insecurely. - Version gate (
routes/version.py): minimum-version / force-update decisions kept server-side, the one control you must never bake into the client.
The shape generalizes: write only the backend that adapts what you don't control. Everything the project does control lives in the BaaS or the client; the custom code exists precisely where two foreign systems (a partner's API, a store-distributed app population) meet.
Interview archetype: "walk me through an architecture decision" — my strongest skill got 12 commits, placed where a partner's API and two identity systems meet; the discipline was knowing where NOT to write code.