ปัญหาของออบเจ็กต์แอปส่วนกลาง

Most tutorials create app at the top of a module and use it everywhere. It feels simple, but that single global object quietly limits how your project can grow. 🌱

A module-level app is built the moment the file is imported. You get exactly one instance, with one fixed configuration, baked in for the whole process.

Testing wants a fresh app per run, ideally with test settings. A global app is already configured, so tests inherit your dev config and bleed state between them.

Dev, test, and prod each need different settings. With one global app, swapping config means editing globals or relying on import-time tricks that are easy to get wrong.

Other modules import app to register routes, and app imports them back. This two-way dependency creates circular imports that crash on startup. 😣

Calling things like db = SQLAlchemy(app) at import time locks the extension to one app, before you even know which config to use.

Because everything hangs off one global, the import order starts to matter. Move one line and a route silently fails to register.

Sometimes you want two app instances, like one for an admin panel. A single global app makes running more than one in the same process awkward at best.

At import time you often do not yet know if this is a test or prod run. A global app forces config decisions before that answer exists.

The cure is the application factory: a function that builds and returns a fresh, fully configured app on demand instead of one frozen global.

Instead of a global, you call a function. Each call hands back a clean app you can configure however the situation needs.

What is the core problem with a single module-level app object?

A global app is one frozen instance: hard to test, tough to configure per environment, and prone to circular imports. The factory pattern is the fix you will build next. 🚀