I am designing an app that has a database, a CRUD web interface to manage its content, and exposing a REST API to be called by an external UI written in React. I am using native Flask Blueprints, SQLAlchemy, along with Marshmallow for API serialization.
The way I have structured Blueprints, based on what I learned from the Flask docs, seems unnecessarily complicated:
app.py
-> __init__.py
.create_app()
registers blueprints
routes
moduleregister_blueprint
specifies two blueprints one for HTML, another for API as each has a different url_prefix
routes
module __init__.py
from routes.user import routes
)routes
implementation
So the SQLAlchemy approach seems just right: in one place I define all the characteristics of the model and thus the associated database tables, as well as the schema for JSON output of my API.
But the Blueprints approach seems convoluted, with dependencies scattered about -- to define one new route, I typically have to modify three files:
app
module (__init.py__
)routes
module for the specific route (routes/user/__init.py__
)routes
implementation for the specific route (routes/user/routes.py
)user
)All of this is functional, but I am assuming there's a simpler way to approach the problem that I have not yet fully grasped. Is there a simpler, cleaner way to implement this?
you can follow approach as in flask-cookiecutter
in app.py
you can create app as
def create_app(config_object="{{cookiecutter.app_name}}.settings"):
"""Create application factory, as explained here: http://flask.pocoo.org/docs/patterns/appfactories/.
:param config_object: The configuration object to use.
"""
app = Flask(__name__.split(".")[0])
app.config.from_object(config_object)
register_blueprints(app)
return app
and you can create blueprints in any routes.py
or ``views.py file in project
and then register them (add them to app) in the register_blueprint function as
def register_blueprints(app):
"""Register Flask blueprints."""
app.register_blueprint(public.views.blueprint)
app.register_blueprint(user.views.blueprint)
return None
this will eliminate the need to add routes to routes/__init__.py
file each time you create views in different routes for different use case.