Our current way to create the tables in the database when we run the application works fine until we need to extend an existing table. Then SQLAlchemy will not do that for us, and we must make the change manually. With Alembic we have a solution for that problem that works great with SQLAlchemy. Let us add it to our to-do application.
Last week we moved from an in-memory data store to SQLAlchemy and persist our tasks inside an SQLite database. We have two things we need to optimize, or else we end up with problems along the way.
Until now we kept our data in a variable. While that worked with an example application, the data vanishes as soon as we restart our API. To get a more realistic application, we need to persist data for a longer time. Let us explore how we can integrate SQLAlchemy with FastAPI.
As we saw with the OAuth2 and JWT example, our main.py file can grow quickly. If we keep adding features, the file will be unmaintainable in no time. For Flask we used Blueprint to split up the application , for FastAPI we can use APIRouter to do the same.
While I was preparing the next post, I run into an annoying warning that I wanted to fix before I add one additional feature to the minimalistic to-do application. Let us explore what I had to do to find the reason for the warning and how I could fix the problem.
The HTTP basic authentication from last week has been working, but it feels a bit messy. When we search for a more current style of authentication, we end up with OAuth2 and JWT. There is an example in the FastAPI documentation that I changed a bit to use a different library for JWT, store the secret key in a .env file and use BCrypt to hash the passwords.
There are many ways we can secure an endpoint in FastAPI. As a first approach we explore HTTP basic authentication, a not so secure way but it allows us to get a first glimpse into the different parts of FastAPI that we need to protect an endpoint.
With FastAPI we get the OpenAPI specification and the Swagger interactive documentation for free. While that is a great help, the automatically generated documentation is not always as helpful as it could be. Let us look for ways in which we can fine-tune the documentation.
While improving the HTTP status codes, I noticed that there should be a header pointing to the newly created task. Let us add that header to our FastAPI application.
Our to-do application currently responds with the HTTP status codes 200 when everything is ok and 404 if the requested task does not exist. While this works, it is not as specific as it could be. Let us explore our options when it comes to HTTP status codes.