A logged-in experience for both customers and agents (Boeing employees).Consider the major parts of what might go into something like Zendesk: Service desks are complicated pieces of technology. After rushing the Boeing 737 to market and murdering hundreds of people with criminal negligence, Boeing hired Billy to build a friendly service desk to field complaints from the families of victims. It turns out Billy is building a customer-facing service desk portal for Boeing. 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. └── config.py Minimal Flask project structureīilly has a lot of what you might expect a lot at first glance. Armed with only that knowledge, his app looks something like this: /myapp 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. 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. Flask is a microframework, which therefore implies we should be writing micro projects, where all logic is dumped into a single file called app.py.Flask is intended for building small-scale apps, while Django is better-suited for larger-scale apps (I may address this directly, although the nature of this tutorial should accomplish that on its own).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). Demystifying Flask’s “Application Factory”.

Bundle & Serve Frontend JS & Styles in Flask.

Connect Flask to a Database with Flask-SQLAlchemy.

Flask User Accounts & Authentication in with Flask-Login.

User Session Data with Flask-Session & Redis.

Flask blueprint for database