Hello! My name is Pedro Kauati👋
In this post I’m going to describe my experience creating a webapp using FastAPI⚡
TL;DR: I created a back-end api that you can see it running here and check out the code here.
My background is in Game Development. I have worked in several companies in Vancouver, mainly using C# and C++. I have dipped my toes in Web Development before, but I was never in charge of seeing something through from start to finish. So I decided to create my own web app (at least the back-end part). Since I’m familiar with Python from other projects, I decided to go with the FastAPI framework.
So I wanted to do something… doable. But still useful. Something that could have a real application, even if it only lives as a hobby project.
An Issue Tracker seemed like a good fit. And with that… Flyswatter was born (well, not yet)! A bug tracker where users could report issues from different projects, comment on them and assign issues to themselves or others.
Stack
- FastAPI⚡
- PostgreSQL🐘
- SQLAlchemy✨
- Alembic🧪
- Docker + docker-compose🐋
- OAuth2 + JWT tokens for authentication🔐
- pytest running on Github Actions🤖
- Sentry for error monitoring📊
Gotchas🔍
During development I ran into some points of confusion for someone who’s getting into a new development environment:
- The difference between running scripts from docker containers and the docker host. Sometimes it makes no difference, but at other times it does. Something I still need to wrap my head around it
- The correct way of managing the database while using Alembic. For example, you should ideally let Alembic generate the tables instead of making them in code. It also creates a table holding the current db revision, which you also shouldn’t manually tamper with, unless you know what you’re doing. Things like that can create a drift between the database and what Alembic tries to do, risking the migrations to not work at all.
- Some common features of Python that I’m still not very well versed with, like the different ways to load env vars and for how long they last in memory; unpacking a dictionary to a set of kwargs and also Python’s import system.
- Watching out for which parts of the database aren’t covered in Alembic’s auto generation. One that I’ve noticed is that it can add enum types on upgrade but it doesn’t remove them on downgrade.
-
Base.metadata.drop_all()nukes all tables except for alembic_versions and other remaining data. It does not go well with alembic inner workings, which may give false positives on migrations or fail them entirely. I lost a few hours trying to find the issue there. - In order to rollback database changes (useful for testing), you have to:
- Start a db connection that lasts for as long as all the changes you want to rollback
- Start a nested subtransaction
- Listen to
after_transaction_end, which triggers after session.commit() - When a transaction ends, start a new subtransaction
- To rollback, call the rollback method on the original connection. This will revert all previous nested transactions
After about 3 weeks of work, the main features of Flyswatter are complete!
You can check out the Github repo and the deployment on Render. I didn’t put any work on the front-end, but fortunately FastAPI also makes use of Swagger UI, which generates a docs page with access to all the endpoints.
This was a very interesting project which taught me lots in terms of web frameworks and Python in itself. And I’m still not done with it, the next step now is to add background processing with Redis. I’m currently planning on generating a PDF bug report, but I may go with something else in the end.
Thank you for reading until this point and feel free to share your thoughts about the project!✌️
