What started as a series on my blog Improve & Repeat reached now the milestone of 250 posts. This is not only a point to celebrate, but also a good opportunity to move Python Friday to its own site. From now on you find all parts of the series on PythonFriday.dev. Please update your RSS reader and point it to this feed to stay up to date.
Here you can see the list of all previously released posts grouped by topic - I hope you enjoy it!
With Material for MkDocs I found a valid alternative for WordPress. There is only one large obstacle left: How do we get the blog posts from WordPress to Markdown?
Last week we searched for viable candidates to run a blog with a static site generator and Material for MkDocs got in the first place. It is now time to check if the documented functionality is really there and works as expected.
I have been using WordPress for my two blogs for 15 years now. While it is still a good tool, I am not very excited about the AI strategy of Automattic Inc, the company behind WordPress. I fear that they will stop spending time on improving WordPress and instead accelerate the enshittification of their platform. I guess it is now time to look for alternatives and see if static website generators could be a viable alternative for a blog.
Before we end this series on FastAPI, I am going to take you for another round to show you a few helpful little tricks that can improve your FastAPI experience.
With our authentication system in place, it is time to put our to-do application into production. For this post I start with a basic Docker container and when that runs, we can add more parts to create a production-ready setup.
A few weeks ago, we explored two approaches to add authentication to our FastAPI applications. In this post we go a different way and integrate a package that does the heavy lifting for us. I decided to go with FastAPI Users, even when it takes a big step to integrate it.
A simple way to protect our API is to limit the number of calls a client can make in a given timespan. For FastAPI, we can use the SlowApi package to prevent our application from being flooded with requests.
Last week we created a breaking change when we added the new filter syntax. With API versioning we try to prevent that and make the breaking changes in a different version of an endpoint. There are many ideas on how to version endpoints the correct way, but so far there is no standard that we can follow. In this post we explore 3 approaches to learn the options we have in FastAPI.
Our filter for retrieving the tasks we are interested in still fetches all data from the database before applying the actual filtering. It is time to fix that and use a more flexible solution that works with the asynchronous SQLAlchemy that we introduced in the last post.