<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Fastapi on Alexander Junge&#39;s website</title>
    <link>https://www.alexanderjunge.net/tags/fastapi/</link>
    <description>Recent content in Fastapi on Alexander Junge&#39;s website</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-US</language>
    <lastBuildDate>Sat, 18 Jan 2025 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://www.alexanderjunge.net/tags/fastapi/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Basic async performance testing with FastAPI and Locust</title>
      <link>https://www.alexanderjunge.net/blog/fastapi-async-perf/</link>
      <pubDate>Sat, 18 Jan 2025 00:00:00 +0000</pubDate>
      
      <guid>https://www.alexanderjunge.net/blog/fastapi-async-perf/</guid>
      <description>Performance optimization is a crucial aspect of web application development, especially when dealing with concurrent requests. When writing FastAPI applications in Python, you can use the async and await keywords to improve performance in many use-cases by writing asynchronous code. However, most tutorials focus on sprinkling in a bunch of asyncs and awaits and hoping for the best. Between some very basic concurrency explanations and reading whole text books, I have come across little helpful, practical guidance on how to actually measure (let alone improve) async performance in a real fastAPI application.</description>
    </item>
    
    <item>
      <title>Deploying fastAPI to AWS Lambda via Amazon API Gateway</title>
      <link>https://www.alexanderjunge.net/blog/fastapi-aws-api-gateway/</link>
      <pubDate>Sat, 16 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://www.alexanderjunge.net/blog/fastapi-aws-api-gateway/</guid>
      <description>I started experimenting with AWS and as a first tiny project I deployed a fastAPI-based REST API to AWS Lambda, a serverless framework. Amazon API Gateway acts as a front-door to the Lambda instance. The architecture roughly looks like this:
The deployed API is a simplified version of the REST API described in a previous post. My code is available on GitHub.
Using AWS SAM, the deployment works like this:</description>
    </item>
    
    <item>
      <title>Querying arXiv preprints using Airflow</title>
      <link>https://www.alexanderjunge.net/blog/arxiv-airflow-fastapi-psql/</link>
      <pubDate>Sun, 02 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://www.alexanderjunge.net/blog/arxiv-airflow-fastapi-psql/</guid>
      <description>Querying arXiv preprints using Apache Airflow I experimented with Apache Airflow to schedule hourly workflows fetching recent preprint articles from different arXiv categories via the public arXiv.org REST API. These articles are then stored in a PostgreSQL database via a custom-built fastAPI-based REST API.
The setup looks like this:
The code is fully dockerized and available on GitHub along with more detailed documentation.</description>
    </item>
    
  </channel>
</rss>