Why Structum?

The Short Answer: Because we wanted the robustness of a Framework with the freedom of a Library.

1. The Paradox of Python Development

Most Python projects eventually face a dilemma:

  1. Micro-Frameworks (e.g., Flask, FastAPI):

    • Pros: Great freedom, easy to start.

    • Cons: Every team reinvents architecture. “How do apply DI?”, “Where do I put config?”, “How do I handle logging?”.

    • Result: Architectural Fragmentation.

  2. Mega-Frameworks (e.g., Django):

    • Pros: Everything is decided. Consistent.

    • Cons: “The Django Way” or the highway. Hard to swap ORM, auth, or admin.

    • Result: Vendor Lock-In.

2. The Structum Way: “Freedom through Rigour”

Structum is built on a different premise: Standardize interfaces, not implementations.

We provide a strict Architectural Constitution (the “What”) but allow replaceable implementation (the “How”).

Connection: Philosophy → Technical Choice

Philosophy

Principle (Constitution)

Technical Implementation

“No magic”

C-2 Explicitness

Wiring must be manual or explicit discovery. No global monkey-patching.

“Swap anything”

C-4 Zero Lock-In

Use of typing.Protocol everywhere. No hard imports of libraries in Core.

“Your app, your rules”

C-1 Optionality

All features are Opt-In Plugins. Nothing is bundled by default.

“Sleep at night”

C-6 Fail-Fast

Validation happens at import/bootstrap time. Invalid apps don’t start.

3. Why adoption is “Harder” (Intentionally)

You might notice Structum requires more boilerplate than other tools.

  • You must explicitly register a plugin.

  • You must explicitly declare dependency types.

  • You must explicitly validate your environment.

This is a feature, not a bug.

The “ease of use” that comes from implicit magic (e.g., global request objects, auto-wiring) becomes “technical debt” at scale. Structum optimizes for Operational Maintenance, not “Hello World” speed.

4. Who is this for?

Structum is designed for:

  • Engineering teams managing multiple microservices.

  • Projects with long lifecycles (5+ years).

  • Developers who fear vendor lock-in.

It is likely overkill for:

  • Hackathons.

  • Prototypes.

  • Single-file scripts.