Hook (1-2 sentences): Every integration you build follows the same chain — upsert the role, create the user, upsert the group, add the user — and somewhere around the third time you write that chain, you realize you've been copying and pasting the same scaffolding across scripts.
Why It Matters
Without a factory pattern, business logic gets tangled into your class methods, error handling gets duplicated across integrations, and every new automation task starts from scratch. The factory approach separates what steps to run from how each step works, so the same sequence logic can be driven entirely from a config document. This unlocks reusable pipelines where the only thing that changes between deployments is a JSON or YAML config — not your code.
What You'll Learn
- Understand why route functions and class methods should stay thin and logic-free
- Recognize the failure mode that emerges when integration logic bleeds into class definitions
- Build a factory process that executes a configurable list of functions in sequence
- Drive multi-step automation workflows from a config document without rewriting the chain
- Apply consistent logging patterns that make script runs auditable and reproducible
From Routes to Factory: A Three-Layer Architecture
The video walks through a deliberate layering strategy. At the base, route functions do exactly one thing: send the right payload to an API and return a response. No branching, no chaining — if you get a 401, throw an error and stop. That's it.
One layer up, classes with methods group related routes into entities. A DataSet class might expose execute_connector, alter_schema, and upsert_dataset — each method packages the API request cleanly but still only talks to one endpoint at a time. Upsert-style methods that combine a create and update are acceptable here, but anything resembling a multi-step workflow is a smell.
The problem surfaces the moment you try to automate something. Configuring three users with a custom role means: check if the role exists, upsert it, create each user, create a group, add users to the group. That's five distinct class calls, and the sequencing logic has to live somewhere. Most scripts bury it inline, which means it gets rewritten — slightly differently — every time.
The factory pattern solves this by treating the sequence itself as data. You define a list of functions to run, pass in a config document that parameterizes each step, and let the factory loop execute them in order. The config drives the what and with what values; the factory drives the how to run it. New automation tasks become config files, not new scripts.
The GitHub notebook shows the concrete implementation — worth reading alongside the video to see how the config document maps to function dispatch.
