Exercise 3: The Real Risk of Two Frameworks, One Database — Possible Solution ==================================================================== THE CONCRETE RISK ------------------------------ The chapter's own final decision has the Django app and the FastAPI service each independently connecting to the same underlying database -- two genuinely separate real processes (or process groups), each with its own connection, each capable of writing data. Chapter 8's own real middleware concepts (auth checks and short-circuiting specifically) only ever protect requests that actually pass through the framework they're registered in. An auth-check middleware written and registered inside the Django app, per Chapter 8's own verified onion model, has zero effect on any request handled entirely by the separate FastAPI service -- it's simply never in that request's own chain at all. WHY THIS IS GENUINELY DIFFERENT FROM A SINGLE-FRAMEWORK SYSTEM ------------------------------------------------------------------------ In a single-framework system, registering one auth middleware once, correctly ordered (per Chapter 9's own real Django MIDDLEWARE example), genuinely protects every request the whole application handles -- there's exactly one onion, and one registration is enough. With two separate frameworks each maintaining their own separate middleware chain, "add an auth check" has to genuinely happen TWICE, once in each framework's own real chain, using each framework's own real mechanism (Django's MIDDLEWARE list; FastAPI's @app.middleware("http") or add_middleware()) -- and nothing structurally prevents one of the two from being updated while the other is forgotten. A permissions change applied only to the Django app's own middleware, with the FastAPI service's own separate chain left unchanged, would leave the warehouse- scanner API either wrongly exposed or wrongly restricted, with no single place to check that would reveal the mismatch. WHAT KIND OF CHECK ACTUALLY NEEDS TO EXIST ------------------------------------------------------------------ A genuine, deliberate cross-check is needed specifically because the two systems' own chains can never be verified as "in sync" just by inspecting either one alone. Concretely: a real, documented set of shared authorization rules (which roles can access which real data) that both the Django app's own middleware and the FastAPI service's own middleware are each independently required to implement and test against -- with an explicit, real test suite exercising both entry points against the identical rule set, specifically so a change to one framework's own chain that isn't mirrored in the other's own chain gets caught by a failing test rather than discovered later as a real, live security gap. This is a genuine, real cost of the chapter's own two-framework decision that a single-framework system would never have needed to think about at all -- one more real, honest tradeoff to weigh alongside the genuine benefits the split brought to the table. WHY THIS WORKS AS AN ANSWER ---------------------------- It identifies a real, specific risk (auth-check drift between two independently maintained middleware chains) rather than a vague "two systems are more complex" observation, explains precisely why Chapter 8's own onion model makes this risk structurally real rather than hypothetical, and proposes a genuinely concrete mitigation (a shared rule set plus cross-framework tests) rather than only naming the problem.