ลงทะเบียน Blueprints ในโรงงาน

With the app built and extensions bound, the last factory job is wiring up your routes. You do that by registering blueprints. 🧩

A blueprint groups related routes into a reusable module. The factory is exactly where you attach those groups to the app.

Import each blueprint and call app.register_blueprint on the fresh app, all within the factory body.

Notice the blueprint import sits inside create_app. This deferred import is the trick that breaks circular import chains.

Give a blueprint its own path namespace with url_prefix at registration time, keeping related routes neatly grouped.

Real apps have many blueprints. Register each one in the factory, and each contributes its own slice of routes to the app.

Because registration happens in one place, the setup order is obvious and easy to read: config, extensions, then blueprints.

The factory reads like a recipe: make the app, load config, init extensions, register blueprints, return. One glance shows the whole wiring. 👀

Blueprint endpoints are prefixed by the blueprint name, so url_for uses blueprint.view to link across modules without clashes.

Each call to create_app registers blueprints onto a brand new app, so tests and prod never share route state.

Config, extensions via init_app, and blueprints via register_blueprint, all inside the factory. That is the full application factory pattern.

Where should blueprints be registered in the factory pattern?

You finished the pattern: register blueprints inside create_app with deferred imports and optional prefixes. Config, extensions, blueprints, return. 🏁