TL;DR I recently had to restructure the biggest project I’ve ever worked on into blueprints. Blueprints help new developers break projects into smaller chunks and practice structuring there files more intuitively.
I was extremely relieved after I finished my first major capstone project in my bootcamp. After spending so much time and energy building an entire application, it was nice to finally have a finished product. I then made the mistake of asking my mentor to go through it with a fine toothed comb and tell me everything that could be improved. Luckily I love any kind of feedback, because the resulting email I got back was 20+ bullet points of things that could be improved.
Once again my mentor came through and provided me with exactly what I asked for. Most of the feedback were things I already knew could be improved, but some of the suggestions dealt with concepts I was not very familiar with (a.k.a, had never heard of). The biggest of these was probably blueprints in Flask. They were something that was mentioned in passing in my bootcamp and I remember my initial thought was, “Wow, that sounds like it could be really helpful”. However, my brain cruised right along and forgot about them.
The reason blueprints were suggested was that my project had clear delineations when it came to the routes I was utilizing. It also probably had something to do with the fact that I had every single one of my routes in my app file, which got a little cumbersome after a while. So I took the suggestion and went to the source for more information, the Flask Blueprints Documentation. Unfortunately the actual documentation for blueprints was kind of confusing, so I branched out to look at additional examples until I stumbled upon this extremely helpful walkthrough at https://realpython.com/flask-blueprint/.
So what are blueprints? Essentially they are a way to take a large project and break it down into smaller applications. They keyword here is applications. I initially thought of blueprints as just another way to structure files in the project. Even though that is true, the utility of blueprints goes beyond making you project file easier to follow. When you create blueprints you’re actually making a small app that can possibly be used in the future with other projects. This turns your one large project into many small applications that run together.
How do I start? First thing you’ll need to do is look at your current code. If you’re following RESTful routing conventions then you’ll most likely have multiple routes with the same prefix.
Above is a snapshot from of one of the simpler aspects of my project. However this highlights exactly what is needed to utilize blueprints. At the top you can see that blueprints are included in the flask library so all you need to do is import them.
After that you can create a blueprint and assign it to the variable you will decorate your routes with. The first part of the blueprint statement is the name of the blueprint, which to make things easier on yourself should match the name of the variable. The dunder variable is the import name of the blueprint. In my project I left all of the dunder’s as __name__ and everything works fine. Finally in my project I have multiple template folders being used which is why I have the last variable set to the name of my template folder.
Okay so now you have a blueprint set up, but you’re not done yet. As you can see, creating the routes is still the same, but instead you’re going to decorate the route with the name of the blueprint. Once you have you’re routes set up then you can move on to utilizing them in your app file.
Once you have your blueprint set up all you need to do it import it and register it. One thing you might notice is the naming conventions used to import the files, but that pertains to the file structure, which I’ll discuss shortly. So once it’s imported all you need to do is register it with your app and you’re all set up!
The last thing I want to briefly highlight is how much easier this made structuring my files. I can definitely say my file structure was a mess before the conversion to blueprints. I won’t try and explain explain everything because the link I referenced earlier does a fantastic job of showing how the files should be structured (including nice pictures and diagrams).
In the screenshot of my blueprint you can get an idea of how the files are structured. The only thing I want to mention is that I had trouble deciding if I should include additional files like database models and middleware in the application folders, or if I should keep them separate. However, the decision became much easier when my mentor reminded me that these are not just separate files, but APPLICATIONS. This small change in thinking really helped me make the decisions to include any important file. That way if I wanted to take that application and use it in another project, I would be able to have everything I needed.
With that being said I was really happy to learn more about blueprints and implement them in my project. I definitely learned a lot and I think utilizing blueprints could be a big help to new developers, like me. Not only do they help focus the developer on specific parts of the application, but they provide a nice clean file structure that is easy to follow. If you want to see the full project you can find it deployed through heroku here:
Or you can check out the files for it on my github:
