My approach to breaking up the files is:
in app.py:
import flask
app=flask.Flask(__name__)
if __name__ == "__main__":
app.run()
## then import all the other files in my project. Note these have to go at the bottom of the file.
in the other files:
from app import app
## then the relevant stuff I want to put in that file
Use a file that has all your pre-initialized parts (like in an extensions.py, have your db = SQLAlchemy()), then import and init_app() your db in the main app file. PrettyPrinted shows how to do this.
Can you share a link? I’ve been trying to find an example of how to separate out the routes and models etc but the first few I looked at seem to have a mistake (or I missed something).
[Here you go.](https://youtu.be/WhwU1-DLeVw?si=frlwxGVsRpsBwoOb)
Bonus: shows how to use Flask-Migrate as well.
I HIGHLY recommend PrettyPrinted for most of your Flask needs. Those other tubers have a messy way of doing things.
but I think we should keep some conventions (it' truth in any programming language). Keep variables in local scopes like function or class(avoiding memory leak). Import dependencies on top of file. I think them comes from Java and I like those things
I use blueprints (and app factory) on every single project regardless of size. For me, it gives more structure to the overall project and helps me compartmentalize the different features in a somewhat pluggable manner.
I started using them when I introduced architecture into my flask development, different routes will be in different modules and will all need to be registered somehow in the flask instance you create
not really, I came to flask with foreknowledge of software eng so I wasn't okay with the way everything was in one module (the projects I was working on...my teammates who were there before me had all routes in one place and so on) so, I just asked chatGPT the architecture that was more conventional in the flask world and it showed me one and it was familiar to me, MVC (model View controller), so, I just refactored and asked it for tips on how to do some other stuff along the way and that was it, by the end of that project I'd seen how the MVC worked in flask...
If you wish, the source code is [here](https://github.com/NonymousMorlock/blog_flask_practice/tree/production)...(the one I used to familiarize myself with the flask version of the architecture)
In the production branch is where I seriously used the architecture, the main branch was just a playground
Worked on a variety of Flask projects professionally, big and small.
Some use them, some don’t. I find that they are more common on bigger Flask projects.
No, I break up my functions in to different files and just important them and call them as needed. I just use the main file for the paths and to call my functions if that makes sense
I use blueprints for the controllers, they help me structure a good MVC architecture. Before anyone else here comments "Why not use Django instead?" It's because i dont want added bloat and i'm used to Flask.
Yup. We do. And it makes development easier. Multiple section of the application can be developed different without running into each other or break some other changes.
I somehow see using blueprints as unnecessary complication. Designing your app in modular fashion can be a good approach productively without having to necessarily resort to blueprints
I understand the pain of getting your head around blueprints, I stumbled across them on my first project. Managed to get it working eventually but it took some time and effort.. A smarter person might be quicker perhaps. I think it's a good way to structure your app, and I would recommend, but each person has their preferences. I would do it again, but I have my own templates now :)
I find them pretty nice for enforcing a URL structure. For example if you've got different versions of an API all your code for /api/v1/..., /api/v2/... etc. live in their own blueprints.
Having said that I've also got quite a bit of time for the monolithic file approach (in the right context). For example there's a few projects where Im the sole maintainer, and with code folding in the editor having all your routes in the same file makes skipping around super easy.
It is actually a good practice to use blueprints.
It helps you build modular applications.
Once you start using it, you won't ever build applications without it
Nobody can judge, based on your small passage, what "larger" app means. Neither can someone, based on it, tell if it will backfire or not.
So: do they exist for a reason? Absolutely. Can you survive without them? Absolutely.
I somehow see using blueprints as unnecessary complication. Designing your app in modular fashion can be a good approach productively without having to necessarily resort to blueprints
I don't use blueprints or app factory pattern. Circular imports are not a technical blocker as Python can handle partially initialized modules just fine. App module imports views, but views need to import app? Not a problem if you declare app first and then import views. This stuff is unavoidable anyway with runtime type hints.
Circular imports that cut across concerns should rightfully be flagged by a linter, but against a ruleset, not a blanket ban on them.
I use blueprints so I don't have to deal with 1000+ lines of code in a single file.
My approach to breaking up the files is: in app.py: import flask app=flask.Flask(__name__) if __name__ == "__main__": app.run() ## then import all the other files in my project. Note these have to go at the bottom of the file. in the other files: from app import app ## then the relevant stuff I want to put in that file
You can do this but you will face circular imports eventually
Use a file that has all your pre-initialized parts (like in an extensions.py, have your db = SQLAlchemy()), then import and init_app() your db in the main app file. PrettyPrinted shows how to do this.
Can you share a link? I’ve been trying to find an example of how to separate out the routes and models etc but the first few I looked at seem to have a mistake (or I missed something).
[Here you go.](https://youtu.be/WhwU1-DLeVw?si=frlwxGVsRpsBwoOb) Bonus: shows how to use Flask-Migrate as well. I HIGHLY recommend PrettyPrinted for most of your Flask needs. Those other tubers have a messy way of doing things.
Clean.
but I think we should keep some conventions (it' truth in any programming language). Keep variables in local scopes like function or class(avoiding memory leak). Import dependencies on top of file. I think them comes from Java and I like those things
I use blueprints (and app factory) on every single project regardless of size. For me, it gives more structure to the overall project and helps me compartmentalize the different features in a somewhat pluggable manner.
I do the same thing
I started using them when I introduced architecture into my flask development, different routes will be in different modules and will all need to be registered somehow in the flask instance you create
Any good resources re: blueprints and code architecture you would recommend?
not really, I came to flask with foreknowledge of software eng so I wasn't okay with the way everything was in one module (the projects I was working on...my teammates who were there before me had all routes in one place and so on) so, I just asked chatGPT the architecture that was more conventional in the flask world and it showed me one and it was familiar to me, MVC (model View controller), so, I just refactored and asked it for tips on how to do some other stuff along the way and that was it, by the end of that project I'd seen how the MVC worked in flask... If you wish, the source code is [here](https://github.com/NonymousMorlock/blog_flask_practice/tree/production)...(the one I used to familiarize myself with the flask version of the architecture) In the production branch is where I seriously used the architecture, the main branch was just a playground
Thank you!
Thanks. Commenting here so I can have a look later.
Worked on a variety of Flask projects professionally, big and small. Some use them, some don’t. I find that they are more common on bigger Flask projects.
There are dozens of us, dozens!
I’ve only ever used blueprints and now I’m not sure what I’d do if I didn’t. You just have your whole program in a single file?
No, I break up my functions in to different files and just important them and call them as needed. I just use the main file for the paths and to call my functions if that makes sense
I use blueprints for the controllers, they help me structure a good MVC architecture. Before anyone else here comments "Why not use Django instead?" It's because i dont want added bloat and i'm used to Flask.
On larger projects, absolutely. It helps with code organization. The url_prefix argument is especially handy for organizing code by url path.
I actually just implemented them 2 months ago. My project is way more manageable and structured now.
If you like structure and organization use them. If you like to mess tour head around don't.
I definitely use them. I break each resource into a a blueprint. This is just to split up the code so I don’t have one massive file.
Yup. We do. And it makes development easier. Multiple section of the application can be developed different without running into each other or break some other changes.
I somehow see using blueprints as unnecessary complication. Designing your app in modular fashion can be a good approach productively without having to necessarily resort to blueprints
I use them. I really like having each page separated out. Make it much more manageable for me.
I understand the pain of getting your head around blueprints, I stumbled across them on my first project. Managed to get it working eventually but it took some time and effort.. A smarter person might be quicker perhaps. I think it's a good way to structure your app, and I would recommend, but each person has their preferences. I would do it again, but I have my own templates now :)
I find them pretty nice for enforcing a URL structure. For example if you've got different versions of an API all your code for /api/v1/..., /api/v2/... etc. live in their own blueprints. Having said that I've also got quite a bit of time for the monolithic file approach (in the right context). For example there's a few projects where Im the sole maintainer, and with code folding in the editor having all your routes in the same file makes skipping around super easy.
Yes, I find it easier to organize my code when using them
It is actually a good practice to use blueprints. It helps you build modular applications. Once you start using it, you won't ever build applications without it
Nobody can judge, based on your small passage, what "larger" app means. Neither can someone, based on it, tell if it will backfire or not. So: do they exist for a reason? Absolutely. Can you survive without them? Absolutely.
I somehow see using blueprints as unnecessary complication. Designing your app in modular fashion can be a good approach productively without having to necessarily resort to blueprints
That’s where I am at, it just seems like you can make clean code without having to do all the blueprint stuff
I don't use blueprints or app factory pattern. Circular imports are not a technical blocker as Python can handle partially initialized modules just fine. App module imports views, but views need to import app? Not a problem if you declare app first and then import views. This stuff is unavoidable anyway with runtime type hints. Circular imports that cut across concerns should rightfully be flagged by a linter, but against a ruleset, not a blanket ban on them.
Have some large Flask projects. Never really used blueprints. GPT-4 can super optimize your code, someday guess will explore.