As it turns out, however, not knowing what the app does is our downfall in making such an assessment. Without knowing what Billy’s app does, this all seems reasonable. He has his handy app.py file (ugh), a folder for templates, a folder for static assets, and so forth. Armed with only that knowledge, his app looks something like this:Įnter fullscreen mode Exit fullscreen modeīilly has a lot of what you might expect a lot at first glance. Billy is pretty new to Flask, but is confident in his abilities to build large-scale Flask apps after reading parts 1-5 in this series.
First, let’s look at what a large app might look like without Blueprints. The best way to get a glance at the benefits associated with using Blueprints is to see the effect they have on an app’s structure.
Blueprints also enable performance benefits associated with code-splitting, similar to Webpack. Blueprints keep related logic and assets grouped and separated from one another, which is essential to designing a maintainable project. (basically anything suitable to be represented as a JIRA epic). Blueprints are intended to encapsulate feature-sized sections of our application, such as checkout flows, user auth, user profiles, etc. We can organize our Flask apps via a built-in concept called Blueprints, which are essentially the Flask equivalent of Python modules. It's a mess to shit where you eat, which is precisely what happens when building applications without structure or encapsulation. It's the same reason why bathrooms and kitchens are separate rooms: one room is for shitting, and one room is for eating. I'm referring to the Single-responsibility principal: a commonly understood concept where each piece of an application should be limited to handling no more than a single responsibility. It's easy to think of an application as a single entity, yet reality shows us that well-structured apps are collections of standalone modules, services, or classes.
Flask blueprint software#
Good software is organized by separation of concerns. Almost every Flask tutorial is structured this way, presumably out of convenience, but it seems as though an asterisk is missing from these tutorials which should read _ *THIS IS NOT A GOOD WAY TO BUILD APPLICATIONS. It's no surprise as to why Flask newcomers believe that structuring entire projects into single app.py files is normal and acceptable.
Of these misconceptions, two are particularly popular as much as they are false: There aren't many perks that come with that title, but it certainly offers some unique perspective, especially when it comes to widespread misconceptions about what people believe about Flask. I've since accepted my fate as being the guy-who-writes-flask-tutorials-on-the-internet-for-no-particular-reason with few regrets. I'm unclear as to when or why it happened, but at some point in the last couple of years, I became emotionally and perhaps romantically involved with Flask (I'm sure you've noticed).
0 kommentar(er)
