Flask Web Development

⚠️ Notice

Although this is a four-year-old book, I still suggest this book as a reference for our course since it is well structured. The first part of this book introduces some basic concepts of Flask framework. Then, in the second part, it presents in step-by-step fashion to implement a demo social blogging application. Learning from practice is a good approach to getting familiar with programming languages. However, a four-year-old book does contain some outdated technologies. For instance, the book presents how to implement a web application which employs Bootstrap to render web pages so that they fit well on any devices such as desktop web browsers, mobile. The Flask-Bootstrap which is presented in this book is an outdated version since it only supports Bootstrap 3. Therefore, I will present an alternative extension which is Bootstrap-Flask that support the up-to-date versions of Bootstrap. By using a different extension than the one presented in the book, there will be many modifications to the sample code to make them work with the new extension. Bootstrap-Flask is just an example, there will be more that I will present when giving lectures.


  1. Resources
  2. How this book is organized
  3. How to work with the example code


How this book is organized

  • The Flask Web Development, Second Edition (by Miguel Grinberg) book is organized into three parts. Part I - Introduction to Flask explores the basics of web application development with the Flask framework and some of its extensions:
    • Chapter 1 describes the installation and setup of the Flask framework.
    • Chapter 2 dives straight into Flask with a basic application.
    • Chapter 3 introduces the use of templates in Flask applications.
    • Chapter 4 introduces web forms.
    • Chapter 5 introduces databases.
    • Chapter 6 introduces email support.
    • Chapter 7 presents an application structure that is appropriate for medium and large applications.
  • Part II - Example: A Social Blogging Application builds Flasky, the open source blog‐ ging and social networking application that I developed for this book:
    • Chapter 8 implements a user authentication system.
    • Chapter 9 implements user roles and permissions.
    • Chapter 10 implements user profile pages.
    • Chapter 11 creates the blogging interface.
    • Chapter 12 implements followers.
    • Chapter 13 implements user comments for blog posts.
    • Chapter 14 implements an application programming interface (API).
  • Part III - The Last Mile describes some important tasks not directly related to application coding that need to be considered before publishing an application:
    • Chapter 15 describes different unit testing strategies in detail.
    • Chapter 16 gives an overview of performance analysis techniques.
    • Chapter 17 describes deployment options for Flask applications, including traditional, cloud-based, and container-based solutions.
    • Chapter 18 lists additional resources.

How to work with the example code

  • The code examples presented in the first textbook are available for download at https://github.com/miguelgrinberg/flasky.
  • The commit history in this repository was carefully created to match the order in which concepts are presented in the book. The recommended way to work with the code is to check out the commits starting from the oldest, then move forward through the commit list as you make progress with the book. As an alternative, GitHub will also let you download each commit as a ZIP or TAR file.
  • If you decide to use Git to work with the source code, then you need to install the Git client, which you can download from https://git-scm.com. The following command downloads the example code using Git:
    • $ git clone https://github.com/miguelgrinberg/flasky.git
  • The git clone command installs the source code from GitHub into a flasky2 folder that is created in the current directory. This folder contains just source code; a copy of the Git repository with the entire history of changes made to the application is also included.
  • The 1a referenced in the command is a tag which is a named point in the commit history of the project. This repository is tagged according to the chapters of the book, so the 1a tag used in the example sets the application files to the initial version used in Chapter 1. Most chapters have more than one tag associated with them, so, for example, tags 5a, 5b, and so on are incremental versions presented in Chapter 5.
  • When you run a git checkout command as just shown, Git will display a warning message that informs you that you are in a "detached HEAD" state. This means that you are not in any specific code branch that can accept new commits, but instead are looking at a particular commit in the middle of the change history of the project. There is no reason to be alarmed by this message, but you should keep in mind that if you make modifications to any files while in this state, issuing another git checkout is going to fail, because Git will not know what to do with the changes you've made. So, to be able to continue working with the project you will need to revert the files that you changed back to their original state. The easiest way to do this is with the git reset command:
    • $ git reset --hard
  • This command will destroy any local changes you have made, so you should save anything you don't want to lose before you use this command.
  • As well as checking out the source files for a version of the application, at certain points you will need to perform additional setup tasks. For example, in some cases you will need to install new Python packages, or apply updates to the database. You will be told when these are necessary.
  • From time to time, you may want to refresh your local repository from the one on GitHub, where bug fixes and improvements may have been applied. The commands that achieve this are:
    • $ git fetch --all
    • $ git fetch --tags
    • $ git reset --hard origin/master
  • The git fetch commands are used to update the commit history and the tags in your local repository from the remote one on GitHub, but none of this affects the actual source files, which are updated with the git reset command that follows. Once again, be aware that any time git reset is used you will lose any local changes you have made.
  • Another useful operation is to view all the differences between two versions of the application. This can be very useful to understand a change in detail. From the command line, the git diff command can do this. For example, to see the difference between revisions 2a and 2b, use:
    • $ git diff 2a 2b
  • The differences are shown as a patch, which is not a very intuitive format to review changes if you are not used to working with patch files. You may find that the graphical comparisons shown by GitHub are much easier to read. For example, the differences between revisions 2a and 2b can be viewed on GitHub at https://github.com/miguelgrinberg/flasky/compare/2a...2b.