An Intro to Building Modular Flask Applications With Blueprints
Growing our application with Blueprints
So far, we've been putting all of our server logic into one file, server.py. As our application gets larger, it's going to be harder to continue to do that.
Blueprints allow developers to create modules that define routes and are then imported into the main server. This is helpful if you are designing multiple separate components of a web application. For example an application that has an user facing webpage, an administrative dashboard, and an API could have one blueprint for each of those parts of the website. Each part of that application will often have its own URL routing scheme (/user, /admin, /api) and its own templates and logic. Blueprints are well suited for each of these because they allow routes to share a common routing prefix (for example /api) while also being able to modularize the logic and templates.
Common Misunderstanding: Blueprints may look like separate Flask apps that happen to be imported into the server, but they are not. A better mental model for Blueprints is to think of them as a collection of routes that needs to be "mounted" to an existing Flask application.
In our stock ticker application, we can modularize our application into two "concerns". The home page logic and the financial information for a specific stock ticker.
To create a blueprint within our stock application, we're going to create a folder inside of our application for the blueprints and then eventually import them into our server.py.
mkdir blueprints
Within the blueprints folder, we should create a Python file in which we can create a Blueprint. For the financial one, we'll call it stock.py
At this point, your folder structure should look like this
* blueprints
* stock.py
* templates (folder)
* your template files...
* requirements.txt
* server.py
* Procfile
In the last section, our stock ticker quote route looked this
@app.route('/stocks/<string:ticker>')
def view_stock(ticker):
stock_price = fetch_price(ticker)
return render_template('stock_quote.html', ticker=ticker, stock_price=stock_price)
We defined the route using the actual Flask application (app) and had to add /quote/ in front of the route. In our stock blueprint, instead of using the application, we will create a Blueprint and use that to define routes.
At the top of stock.py, we're going to define our Blueprint which will involve importing the Blueprint class from Flask, instantiate a Blueprint with a name, and optional arguments to define the url_prefix for all routes in this blueprint.
tip
Maintainability Tip: URL Prefixes are optional, but good practice
Without URL prefixes for blueprints, it can be easy to accidentally define the same route twice and Flask will fail to start once it sees that there is a conflict.
Instead it is generally better practice to have unique url_prefixes for each blueprint you make so you can avoid this problem. In addition, developers looking for the logic for a specific route can quickly find what blueprint it is defined in.
from flask import Blueprint, render_template
stock = Blueprint('stock', __name__, url_prefix='/stocks')
Defining our route will be very similar to how we did earlier, with two changes, the decorator for the route (@app.route) will reference the blueprint instead (@stock.route) and the route path no longer needs /stocks in front of it since the blueprint already sets it as a prefix.
We'll also need to move in the fetch_price function from the server.py.
from flask import Blueprint, render_template
import requests
stock = Blueprint('stock', __name__, url_prefix='/stocks')
def fetch_price(ticker):
data = requests.get('https://financialmodelingprep.com/api/v3/stock/real-time-price/{}'.format(ticker.upper()),
params={'apikey': 'demo'}).json()
At this point, if we run our server, nothing has actually changed. That's because we have not yet imported and registered the stock blueprint we just made. In server.py, we'll start by importing the blueprint we just made.
from flask import Flask, render_template
from blueprints.stock import stock
app = Flask(__name__)
app.register_blueprint(stock)
We're specifically importing the blueprint object we've instantiated within sever.py.
We'll also need to update some calls to url_for because we've changed the routing path. What was url_for('view_stock') needs to become url_for('stock.view_stock') to reflect that route is actually in the Blueprint that we initialized with the name stock. In macros.html, update the call to url_for to look like this:
{% macro stock_quote_link(stock_ticker) %}
<a href="{{ url_for('stock.view_stock', ticker=stock_ticker) }}">{{ stock_ticker }}</a>
{% endmacro %}
This lesson preview is part of the Fullstack Flask: Build a Complete SaaS App with Flask course and can be unlocked immediately with a single-time purchase. Already have access to this course? Log in here.
Get unlimited access to Fullstack Flask: Build a Complete SaaS App with Flask with a single-time purchase.
[00:00 - 00:37] Welcome back. In today's video, we're going to talk about Blueprints as a better way to organize our Flask application as it grows. Now, to date, everything we've done has been inside of a single file inside of server.py here. Now, you can imagine that as we scale, we don't want to put all of our code into one large Flask file. Some of the hardest to maintain Flask applications I've worked with have just been massive single file Flask servers. And there's just a lot of logic all over the place, and it's hard to maintain.
[00:38 - 00:50] So instead, we'll use something that Flask provides called Blueprints to organize our routes and collections. They make a lot of sense when we have applications that have components that are fairly discreet.
[00:51 - 02:33] For example, if you have an administrative side of your application that's only accessible to employees at your company, for example, it makes sense to make that a separate Blueprint and separate that out from the more user-facing side of your application, which could live in another Blueprint. A common misconception is that Flask Blueprints are separate Flask applications, and that's not quite true. Instead, the way you want to think of Blueprints is that there are actually just a collection of routes that can be imported into your application and be registered accordingly. Okay, so let's get started, and we're going to add Blueprints into our application. So the first thing we're going to do is we're going to create a Blueprints folder in our application. And then within that, we can think about what our existing Blueprints are. So we're probably going to add a lot of functionality on the stock side of this application. So it will make sense to have a stock.py Blueprint. And the other side of our application is more like the homepage stuff, so maybe eventually we 'll start a homepage Blueprint. But for now, let's think about the stocks Blueprint. So when we're starting off a Blueprint, what we want to do is import that class from Flask. So in our server, before we used to import Flask and create an application to which we're registering routes, but this time what we're going to do is we're going to import a Blueprint, and we're going to set up a Blueprint. Let's call our Blueprint stock here, then we're going to initialize a Blueprint.
[02:34 - 03:31] And we're going to give this Blueprint a name. The name that we're filling out here is going to be the name that we're going to refer to it in the rest of our application as any time we're constructing URLs or trying to route to a specific route in this Blueprint. So I'm going to call my stock. And we also have to pass in an import name, which is the name of the module that we're in. So similarly, to how we did it in Flask, we're going to use the module name. And then here, the last argument is there's a bunch of optional arguments here. So you can see all of those arguments here, including a custom template folder, potentially a subdomain. But the one we're going to specify here is actually URL prefix. So we want all of the routes in this to add in this Blueprint to be prefix with slash stock.
[03:32 - 03:45] What that will mean is we don't have to reference slash stock in every single route we define here. So what we can then do is we can take this logic we had here and move that into here.
[03:46 - 04:31] And now instead of app.route, this just becomes stock.route. And instead of slash stock, we can change this to be just slash ticker because the URL prefix will take care of making that slash stock. And then this can stay. We probably don't want to define this as stock since that's the name of our Blueprint. So we can call this quote, for example. Okay. So so now that we have that, we're also going to have to define the fetch price function. So it probably makes sense to have the fetch price function live in a in a separate file, maybe like a utils file. But for the sake of example, we're just going to put it in the controller for now. And so we import requests.
[04:32 - 05:17] Okay, so we've actually just created our Blueprint right here. So our next step is to delete all of the code that we've created here that we don't need anymore. So we don't need this. And we don't need any of this logic either. Now what we want to do is we actually just want to import our Blueprint here. So what we can do to do that is we can say from blueprints dot stock import stock. And what we're doing there is we're importing this variable here. Now it's best practice to create a module file here, just an empty init.py file.
[05:18 - 05:26] So that's more easily recognized as an import. All right. So Blueprint dot stock import stock.
[05:27 - 06:00] Now that we have the Blueprint, we want to go and register that Blueprint. So the way we can do that is there's a function on floss called register Blueprint. And all we have to do is pass in a Blueprint. Okay. So at this point, we can try running our application and see what happens. And the short answer is I think it's going to crash. So if we refresh our page here, okay, well, that one's an easy one to fix. We also need to import render template.
[06:01 - 07:07] Now going back here, now it's complaining about this URL. Could not build URL for endpoint stock with values ticker. Did you mean stock dot quote instead? And the debugger is right. We did mean stock dot quote. And looking at the trace back, we can find exactly where we met. We did that. So our macros file has us going URL for stock. And that's not what we want to do. So we want to do URL for stock dot quote instead. All right, let's try now. All right, so this works. So if we're here, we can now go back to our application and there's a Blueprint. But while we're back on the s code, now that we changed this look at stock dot quote, we actually looking at this template structure, we actually probably want to organize a little better. Good practices, we're going to create a template folder for each of the blueprints. So we created a blueprint named stock dot pi.
[07:08 - 08:32] And then what we should do is we should move the template inside of there. So I 'm going to move stock dot quote inside of there. Okay, now that's here, maybe we can rename this to be just quote dot HTML to better match the name of the template. Then here, what we're going to have to do is we're going to say stock quote. And the reason we have to do stock slash quote is because when we do render template by default, it's always looking in the templates folder for everything. So when we say stocks quote, that way, it knows where to go. All right, let's check out Firefox and see if it worked. Okay, looks like it still works. Now that we're looking at server dot p y, it looks so much neater. All of the complexity of how to view a stock quote is moved out of there in this application simple to understand. Now if we want to add another feature , it's relatively simple. The feature I'm thinking about is the one to view a company's financial s. So our API that we're using also provides us with an endpoint to view companies quarterly financials. And it'd be neat if we can bring that into our application as well. So to do that, first off, we're going to have to write some code to fetch that data from our server. So let's do that.
[08:33 - 09:17] And then also define a new route. So this function is going to be called fetch income. And so I've pasted in the code here, you can find that as well. But it basically does the same thing that we've seen above. But it specifically grabs the financial data for a company's quarterly results. So what we want to do here is define a new route, stock dot route. And we'll call this tickers, and then maybe slash financials. So once we're here, we can call this financials. Again, it takes in a ticker.
[09:18 - 10:32] One thing we can do is specify the type is we can say string ticker, just to be extra explicit there. Okay. And then we can say our data is equal to fetch income ticker. Now one thing that's making me a little uncomfortable is I think we should move this into its own separate utility file . Now that it's getting pretty complicated, we generally want to keep blueprints to simply the logic to render the template stuff like this, where you're making API requests should really be in a separate module. But for the sake of our example here, I'm going to stuff that under the rug there and just collapse those functions. Okay, then what we want to do is we essentially just render the details of the template. So we want to return maybe a template, which we'll have to create. So we'll create anyone, stock financials dot html, probably wanted to pass in the ticker, and we'll also probably want to pass the data there as financials. Okay, so let's create that template.
[10:33 - 11:55] Financials dot html. Alright, inside of financials dot html, we want to define the same initial set of things. So we want to say that it comes from base layout, and it defines the financials. Now that we've had this, we can actually load the financials page. There won't be anything on it, but it's just a good way to verify that it works. So if we go here and say financials, and we fix the syntax error, then we should be good to go. Alright, now that we've fixed the syntax error, we see that the page actually renders. There's just no content yet, because on the financials template, we haven't defined the content block. Okay, so the content block I'm thinking of is essentially a table. So to start off with, I think the table contains a few fields. Let's go there, and then, and block. And then what we can do here is we can render the details of the financials here, so we can see exactly what that looks like.
[11:56 - 12:32] Alright, going back to our browser, we see here, there's a table, and then there's these dates and data, and it's basically the data we saw in this JSON file here. So we can use a for loop here to render our rows. So here's our table that we want. Let's see what that looks like in PowerFogs. Cool, so that's essentially our table right there.