Last week we got pytest to run asynchronous test methods. That was the preparation step for this post where we switch to asynchronous SQLAlchemy for our to-do application. As it turns out, switching to asynchronous methods for SQLAlchemy takes a lot of work. Let us get through the different changes we need to make.
After finishing the dashboard, I hoped to quickly switch my datastore implementation to use the asynchronous methods for SQLAlchemy. Unfortunately, that was not the case. Everything needs to change, and that change must be done all at once. That includes pytest, that we need to run our tests.
To make the change more understandable, we start in this post with pytest and do the necessary work to test asynchronous methods. With that out of our way, we can next week focus on SQLAlchemy.
We already created a shared layout for the web interface of our API and fixed the problem with the static resources. Now we can create a dashboard that shows us some important numbers about our application.
When we start serving HTML files with our FastAPI application, we need a way to send images, CSS- and JavaScript files without creating an endpoint for each file. Let us solve this problem with a static route.
Last week we added Alembic to our to-do app to be ready for upcoming changes to the tables. In this post we extend our FastAPI application, but in an unexpected direction: we add a web interface. Let us find out how we can do that.
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.
Before we can move ahead and add a database to our to-do API, we take a little detour and update SQLAlchemy to version 2. Much changed since I wrote about SQLAlchemy three years ago, but thanks to the early published guidelines, the largest part of the examples I used in my post can stay the same. Nevertheless, there are changes we need to know about, and we must update minor details to run the examples with the current version of SQLAlchemy.
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.