This tutorial is out of date and no longer maintained.
Note: This is Part One of a three-part series. Build a CRUD Web App With Python and Flask - Part One Build a CRUD Web App With Python and Flask - Part Two Build a CRUD Web App With Python and Flask - Part Three
In this three-part tutorial, we’ll build a CRUD (Create, Read, Update, Delete) employee management web app using Flask, a microframework for Python. I’ve named the app Project Dream Team, and it will have the following features:
Part One will cover:
Ready? Here we go!
This tutorial builds on my introductory tutorial, Getting Started With Flask, picking up where it left off. It assumes you have, to begin with, the following dependencies installed:
You should have a virtual environment set up and activated. You should also have the following file and directory structure:
├── dream-team
├── app
│ ├── __init__.py
│ ├── templates
│ ├── models.py
│ └── views.py
├── config.py
├── requirements.txt
└── run.py
This project structure groups the similar components of the application together. The dream-team
directory houses all the project files. The app
directory is the application package and houses different but interlinked modules of the application. All templates are stored in the templates
directory, all models are in the models.py
file, and all routes are in the views.py
file. The run.py
file is the application’s entry point, the config.py
file contains the application configurations, and the requirements.txt
file contains the software dependencies for the application.
If you don’t have these set up, please visit the introductory tutorial and catch up!
Flask has support for several relational database management systems, including SQLite, MySQL, and PostgreSQL. For this tutorial, we will be using MySQL. It’s popular and therefore has a lot of support, in addition to being scalable, secure, and rich in features.
We will install the following (remember to activate your virtual environment):
Flask-SQLAlchemy: This will allow us to use SQLAlchemy, a useful tool for SQL use with Python. SQLAlchemy is an Object Relational Mapper (ORM), which means that it connects the objects of an application to tables in a relational database management system. These objects can be stored in the database and accessed without the need to write raw SQL. This is convenient because it simplifies queries that may have been complex if written in raw SQL. Additionally, it reduces the risk of SQL injection attacks since we are not dealing with the input of raw SQL.
MySQL-Python: This is a Python interface to MySQL. It will help us connect the MySQL database to the app.
We’ll then create the MySQL database. Ensure you have MySQL installed and running, and then log in as the root user:
mysql> CREATE USER 'dt_admin'@'localhost' IDENTIFIED BY 'dt2016';
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE DATABASE dreamteam_db;
Query OK, 1 row affected (0.00 sec)
mysql> GRANT ALL PRIVILEGES ON dreamteam_db . * TO 'dt_admin'@'localhost';
Query OK, 0 rows affected (0.00 sec)
We have now created a new user dt_admin
with the password dt2016
, created a new database dreamteam_db
, and granted the new user all database privileges.
Next, let’s edit the config.py
. Remove any existing code and add the following:
It is good practice to specify configurations for different environments. In the file above, we have specified configurations for development, which we will use while building the app and running it locally, as well as production, which we will use when the app is deployed.
Some useful configuration variables are:
TESTING
: setting this to True
activates the testing mode of Flask extensions. This allows us to use testing properties that could for instance have an increased runtime cost, such as unit test helpers. It should be set to True
in the configurations for testing. It defaults to False
.DEBUG
: setting this to True
activates the debug mode on the app. This allows us to use the Flask debugger in case of an unhandled exception, and also automatically reloads the application when it is updated. It should however always be set to False
in production. It defaults to False
.SQLALCHEMY_ECHO
: setting this to True
helps us with debugging by allowing SQLAlchemy to log errors.You can find more Flask configuration variables here and SQLAlchemy configuration variables here.
Next, create an instance
directory in the dream-team
directory, and then create a config.py
file inside it. We will put configuration variables here that will not be pushed to version control due to their sensitive nature. In this case, we put the secret key as well as the database URI which contains the database user password.
Now, let’s edit the app/__init__.py
file. Remove any existing code and add the following:
We’ve created a function, create_app
that, given a configuration name, loads the correct configuration from the config.py
file, as well as the configurations from the instance/config.py
file. We have also created a db
object which we will use to interact with the database.
Next, let’s edit the run.py
file:
We create the app by running the create_app
function and passing in the configuration name. We get this from the OS environment variable FLASK_CONFIG
. Because we are in development, we should set the environment variable to development
.
Let’s run the app to ensure everything is working as expected. First, delete the app/views.py
file as well as the app/templates
directory as we will not be needing them going forward. Next, add a temporary route to the app/__init__.py
file as follows:
Make sure you set the FLASK_CONFIG
and FLASK_APP
environment variables before running the app:
* Serving Flask app "run"
* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)
We can see the “Hello, World” string we set in the route. The app is working well so far.
Now to work on the models. Remember that a model is a representation of a database table in code. We’ll need three models: Employee
, Department
, and Role
.
But first, let’s install Flask-Login, which will help us with user management and handle logging in, logging out, and user sessions. The Employee
model will inherit from Flask-Login’s UserMixin
class which will make it easier for us to make use of its properties and methods.
To use Flask-Login, we need to create a LoginManager object and initialize it in the app/__init__.py
file. First, remove the route we added earlier, and then add the following:
In addition to initializing the LoginManager object, we’ve also added a login_view
and login_message
to it. This way, if a user tries to access a page that they are not authorized to, it will redirect to the specified view and display the specified message. We haven’t created the auth.login
view yet, but we will when we get to authentication.
Now add the following code to the app/models.py
file:
In the Employee
model, we make use of some of Werkzeug’s handy security helper methods, generate_password_hash
, which allows us to hash passwords, and check_password_hash
, which allows us to ensure the hashed password matches the password. To enhance security, we have a password
method that ensures that the password can never be accessed; instead, an error will be raised. We also have two foreign key fields, department_id
and role_id
, which refer to the ID of the department and the role assigned to the employee.
Note that we have an is_admin
field which is set to False
by default. We will override this when creating the admin user. Just after the Employee
model, we have a user_loader
callback, which Flask-Login uses to reload the user object from the user ID stored in the session.
The Department
and Role
models are quite similar. Both have name
and description
fields. Additionally, both have a one-to-many relationship with the Employee
model (one department or role can have many employees). We define this in both models using the employees
field. backref
allows us to create a new property on the Employee
model such that we can use employee.department
or employee.role
to get the department or role assigned to that employee. lazy
defines how the data will be loaded from the database; in this case, it will be loaded dynamically, which is ideal for managing large collections.
Migrations allow us to manage changes we make to the models and propagate these changes in the database. For example, if later on, we make a change to a field in one of the models, all we will need to do is create and apply a migration, and the database will reflect the change.
We’ll begin by installing Flask-Migrate, which will handle the database migrations using Alembic, a lightweight database migration tool. Alembic emits ALTER
statements to a database thus implementing changes made to the models. It also auto-generates minimalistic migration scripts, which may be complex to write.
We’ll need to edit the app/__init__.py
file:
We have created a migrate
object which will allow us to run migrations using Flask-Migrate. We have also imported the models from the app
package. Next, we’ll run the following command to create a migration repository:
This creates a migrations
directory in the dream-team
directory:
└── migrations
├── README
├── alembic.ini
├── env.py
├── script.py.mako
└── versions
Next, we will create the first migration:
Finally, we’ll apply the migration:
We’ve successfully created tables based on the models we wrote! Let’s check the MySQL database to confirm this:
mysql> use dreamteam_db;
mysql> show tables;
+------------------------+
| Tables_in_dreamteam_db |
+------------------------+
| alembic_version |
| departments |
| employees |
| roles |
+------------------------+
4 rows in set (0.00 sec)
Blueprints are great for organizing a flask app into components, each with its own views and forms. I find that blueprints make for a cleaner and more organized project structure because each blueprint is a distinct component that addresses a specific functionality of the app. Each blueprint can even have its own custom URL prefix or subdomain. Blueprints are particularly convenient for large applications.
We’re going to have three blueprints in this app:
Create the relevant files and directories so that your directory structure resembles this:
└── dream-team
├── app
│ ├── __init__.py
│ ├── admin
│ │ ├── __init__.py
│ │ ├── forms.py
│ │ └── views.py
│ ├── auth
│ │ ├── __init__.py
│ │ ├── forms.py
│ │ └── views.py
│ ├── home
│ │ ├── __init__.py
│ │ └── views.py
│ ├── models.py
│ ├── static
│ └── templates
├── config.py
├── instance
│ └── config.py
├── migrations
│ ├── README
│ ├── alembic.ini
│ ├── env.py
│ ├── script.py.mako
│ └── versions
│ └── a1a1d8b30202_.py
├── requirements.txt
└── run.py
I chose not to have static
and templates
directories for each blueprint because all the application templates will inherit from the same base template and use the same CSS file. Instead, the templates
directory will have sub-directories for each blueprint so that blueprint templates can be grouped together.
In each blueprint’s __init__.py
file, we need to create a Blueprint object and initialize it with a name. We also need to import the views.
Then, we can register the blueprints on the app in the app/__init__.py
file, like so:
We have imported each blueprint object and registered it. For the admin
blueprint, we have added a URL prefix, /admin
. This means that all the views for this blueprint will be accessed in the browser with the URL prefix admin
.
Time to work on fleshing out the blueprints! We’ll start with the home
blueprint, which will have the homepage as well as the dashboard.
Each view function has a decorator, home.route
, which has a URL route as a parameter (remember that home
is the name of the blueprint as specified in the app/home/__init__.py
file). Each view handles requests to the specified URL.
The homepage
view renders the home template, while the dashboard
view renders the dashboard template. Note that the dashboard
view has a login_required
decorator, meaning that users must be logged in to access it.
Now to work on the base template, which all other templates will inherit from. Create a base.html
file in the app/templates
directory and add the following code:
Note that we use #
for the Register and Login links. We will update this when we are working on the auth
blueprint.
Next, create a home
directory inside the app/templates
directory. The homepage template, index.html
, will go inside it:
Inside the static
directory, add css
and img
directories. Add the following CSS file, style.css
, to your static/css
directory (note that you will need a background image, intro-bg.jpg
, as well as a favicon in your static/img
directory):
Run the app; you should be able to see the homepage now.
For the auth
blueprint, we’ll begin by creating the registration and login forms. We’ll use Flask-WTF, which will allow us to create forms that are secure (thanks to CSRF protection and reCAPTCHA support).
Now to write the code for the forms:
Flask-WTF has a number of validators that make writing forms much easier. All the fields in the models have the DataRequired
validator, which means that users will be required to fill all of them in order to register or log in.
For the registration form, we require users to fill in their email address, username, first name, and last name. Users will also be required to enter their password twice. We use the Email
validator to ensure valid email formats are used (e.g., example@example.com
). We use the EqualTo
validator to confirm that the password
and confirm_password
fields in the RegistrationForm
match. We also create methods (validate_email
and validate_username
) to ensure that the email and username entered have not been used before.
The submit
field in both forms will be represented as a button that users will be able to click to register and login respectively.
With the forms in place, we can write the views:
Just like in the home
blueprint, each view here handles requests to the specified URL. The register
view creates an instance of the Employee
model class using the registration form data to populate the fields and then adds it to the database. This essentially registers a new employee.
The login
view queries the database to check whether an employee exists with an email address that matches the email provided in the login form data. It then uses the verify_password
method to check that the password in the database for the employee matches the password provided in the login form data. If both of these are true, it proceeds to log the user in using the login_user
method provided by Flask-Login.
The logout
view has the login_required
decorator, which means that a user must be logged in to access it. It calls the logout_user
method provided by Flask-Login to log the user out.
Note the use of flash
method, which allows us to use Flask’s message flashing feature. This allows us to communicate feedback to the user, such as informing them of successful registration or unsuccessful login.
Finally, let’s work on the templates. First, we’ll install Flask-Bootstrap so we can use its wtf
and utils
libraries. The wtf
library will allow us to quickly generate forms in the templates based on the forms in the forms.py
file. The utils
library will allow us to display the flash messages we set earlier to give feedback to the user.
We need to edit the app/__init__.py
file to use Flask-Bootstrap:
We’ve made quite a number of edits to the app/__init__.py
file. This is the final version of the file and how it should look at this point (note that I have re-arranged the imports and variables in alphabetical order):
We need two templates for the auth
blueprint: register.html
and login.html
, which we’ll create in an auth
directory inside the templates
directory.
The forms are loaded from the app/auth/views.py
file, where we specified which template files to display for each view. Remember the Register and Login links in the base template? Let’s update them now so we can access the pages from the menus:
Run the app again and click on the Register and Login menu links. You should see the templates loaded with the appropriate form.
Try to fill out the registration form; you should be able to register a new employee. After registration, you should be redirected to the login page, where you will see the flash message we configured in the app/auth/views.py
file, inviting you to login.
Logging in should be successful; however you should get a Template Not Found
error after logging in, because the dashboard.html
template has not been created yet. Let’s do that now:
Refresh the page. You’ll notice that the navigation menu still has the register and login links, even though we are already logged in. We’ll need to modify it to show a logout link when a user is already authenticated. We will also include a Hi, username!
message in the nav bar:
Note how we use if-else
statements in the templates. Also, take note of the current_user
proxy provided by Flask-Login, which allows us to check whether the user is authenticated and to get the user’s username.
Logging out will take you back to the login page:
Attempting to access the dashboard page without logging in will redirect you to the login page and display the message we set in the app/__init__.py
file:
Notice that the URL is configured such that once you log in, you will be redirected to the page you initially attempted to access, which in this case is the dashboard.
That’s it for Part One! We’ve covered quite a lot: setting up a MySQL database, creating models, migrating the database, and handling registration, login, and logout. Good job for making it this far!
Watch this space for Part Two, which will cover the CRUD functionality of the app, allowing admin users to add, list, edit, and delete departments and roles, as well as assign them to employees.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Hi,
In the instance/config.py file, where did you get the SECRET_KEY? Is it okay to use a random string of characters or its fetched from somewhere?
Really excited for this series. Please confirm the SQLALCHEMY_DATABASE_URI is correct with the root:password and host creds.
When I remove the credentials within instance/config.py and run flask db init to create my migrations folder it works great.
However, when I keep the secret key and URI, python throws me a KeyError regarding the following line from init.py in the app directory.
app.config.from_object(app_config[config_name])
Please advise any thoughts on this.
Thanks!
This is a great article, but somewhat undermined by using Python 2.7 instead of Python 3?
Are you all planning to release /part-two?
I hope so! I really enjoyed this tutorial.
For the form, you wrote validate_email and validate_user methods, but they were never invoked anywhere? I tested it and they don’t seem to work?
Any plan to upgrade the tutorial to Python 3?
At “flask db init”, I get this error
No handlers could be found for logger “flask_migrate”
Somebody help
Mbithe Muy buen tutorial De a poco estoy logrando lo que estuve mucho tiempo intentando. Gracias a vos y a toda la gente de Digital Ocean.