Flask is a micro-framework that runs in Python. This document aims to concisely describe Flask. Linked material provides detail about actually using Flask.
$ conda activate new-env # maybe you want a virtual environment specialized for this project (new-env) $ ! pip install flask
A great (and world-famous) tutorial is here: https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world
Heroku is a hosting service that has a free tier appropriate for small, experimental works. Here is a decent walk-through of setting up a Flask app on Heroku: https://stackabuse.com/deploying-a-flask-application-to-heroku
A framework is a set of interoperable components that provide functionality. Some provide rich functionality. But, heavier frameworks might provide many more prebuilt components than are actually required. In this case, ‘micro-frameworks’, which provide fewer components, are useful.
The Web Server Gateway Interface is a standard specification for communication between web servers and a client applications. Details are contained in PEP333.
- Flexibility regarding application components
- Interoperability with different Python frameworks
- Scalability (with number of users or frequency of use)
- Efficient development
Jinja is a template language that can be used by Python.
These allow sets of pages (e.g. recipes) and sets of components, (e.g., lists, highlighted sections). A templating language, and code that can use it, allows templating code to be interspersed with markup language (such as HTML), making life simpler.
- A development server and debugger
- Interoperability with Jinja2
- Compliance with WSGI 1.0
- Integrated support for unit testing
- Many avaiable extensions
When a browser sends an HTTP request, that request will be routed to a specific virtual or physical server.
A running web server will be listening for requests, and needs to know what to do when it gets a request.
Other Moving Parts
These are some things that are needed to use Flask. Alternatives might exist.
A collection of software that monitors specific ports, and responds to requests on certain ports (e.g., 80) by passing data to other software, such as an instance of Flask. This article mentions gunicorn, but there are others.
An instance of an operating system. This might be a single physical machine, or a virtual machine. This is the environment the web server, web frameworks, and language interpreters (e.g., Python) run in. This article mentions Heroku, a service that provides virtual servers. A free tier of service can provide virtual servers that can be assigned URL’s like MYPROJECT.heroku.com.
Files and Directory Structure
On Heroku, a file named
Procfile specifies a web server to use to respond to HTTP requests.
The web server ‘gunicorn’ will look in a folder, named the same as the server, for file named
__init__.py, and interpret it in Python.
In Flask, usually, the only two things this file will ‘do’ are:
- Import code (e.g., from a file named
app.py) that tells how to create an
- Use that code to create an
Appobject, usually simply named
.app will contain code that will specify how to create an object that will handle requests to different ‘paths’ on the server.
Definitions of how to handle requests to specific ‘paths’ are called ‘endpoints’ generically, and ‘routes’ specifically in Flask.
As a set, these endpoints should specify how to handle any requests received by the server. Procedures to handle requests to specific routes will need a variety of functions, classes, data, and assets such as images anad video.
Pipfile can contain a list of libraries required by the application’s main code.
Pipfile.lock is a file that is used by a pipenv-aware server (Heroku is) to ensure that required code, and versions of that code, are installed.
Structure of directories and files
This is a common, but not required, pattern.
├── LICENSE (optional, recommended) ├── blasto (a folder named the same as the domain prefix, like the 'blasto' in a URL like blasto.heroku.com) │ ├── app.py (contains functions to instantiate an 'app' object, and functions to handle requests to 'endpoints') │ ├── a_separate_code_file.py │ ├── __init__.py │ ├── sample-data.py │ ├── test_data.py ├── Pipfile ├── Pipfile.lock ├── Procfile