FastAPI: The Modern Python Web Framework

 

Introduction to FastAPI: The Modern Python Web Framework

The world of web frameworks has always been competitive — from Django and Flask in Python to Ruby on Rails, Express.js, and Spring Boot. But in recent years, FastAPI has emerged as one of the fastest-growing Python frameworks.

So what makes FastAPI special? Why are developers choosing it for APIs, microservices, and AI-powered apps? Let’s explore.

---

What is FastAPI?

FastAPI is a modern, high-performance web framework for building APIs with Python 3.6+ based on standard Python type hints.

It was created by Sebastián Ramírez and quickly gained popularity for its speed, ease of use, and developer-friendly features.

👉 Think of it as Flask + Django REST + automatic docs — but faster.

---

Key Features of FastAPI

1. Blazing Fast Performance

   • Built on ASGI (Asynchronous Server Gateway Interface).

   • Powered by Starlette (web parts) and Pydantic (data validation).

   • Comparable to Node.js and Go in terms of API performance.

2. Automatic API Documentation

   • Generates Swagger UI and ReDoc automatically.

   • No extra setup needed — docs update as you code.

3. Data Validation & Serialization

   • Uses Pydantic for request validation and response models.

   • Strong type checking → fewer bugs.

4. Asynchronous Support

   • First-class support for async/await.

   • Handles thousands of requests concurrently.

5. Easy to Learn, Easy to Use

   • Minimal boilerplate (like Flask).

   • Clear, Pythonic syntax.

---

Getting Started with FastAPI

Step 1: Install FastAPI and Uvicorn

pip install fastapi uvicorn

Step 2: Create Your First App

# main.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"Hello": "World"}

@app.get("/items/{item_id}")
def read_item(item_id: int, q: str = None):
    return {"item_id": item_id, "q": q}

Step 3: Run the Server

uvicorn main:app --reload

• Open http://127.0.0.1:8000 → API is live.

• Open http://127.0.0.1:8000/docs → Swagger UI (auto docs).

---

When to Use FastAPI

✅ Building REST APIs & microservices.
✅ AI/ML model serving (popular in data science).
✅ High-performance backend systems.
✅ Applications requiring async operations (chat apps, real-time APIs).

Not ideal for:
❌ Heavy full-stack apps (use Django or Rails instead).
❌ When you need batteries-included features like admin panels, auth, ORM (Django is better here).

---

FastAPI vs Django vs Flask

Feature	FastAPI	Django	Flask
Speed (async)	⚡ Very Fast	🐢 Slower (sync)	🐇 Fast
Type Safety	✅ Built-in	❌ Limited	❌ Limited
Auto Docs	✅ Yes (Swagger)	❌ No	❌ No
Learning Curve	Easy	Medium	Easy
Best For	APIs, ML apps	Full-stack apps	Simple APIs

---

Final Thoughts

FastAPI is quickly becoming the go-to framework for modern Python APIs. Its speed, automatic documentation, async support, and Pythonic design make it a favorite for developers building microservices, ML model backends, and high-performance systems.

If you’re coming from Flask, you’ll love the simplicity with extra power.
If you’re coming from Django, you’ll appreciate how lightweight and fast it is for APIs.

👉 In short: If you’re building APIs in Python today, FastAPI is one of the best choices available.

Intro to Docker for Developers: How to Run your Rails App on Docker

Docker in a Nutshell First of all what is Docker? Let’s chew on the Wikipedia definition to start: 

“Docker is an open-source project that automates the deployment of applications inside software containers, by providing an additional layer of abstraction and automation of operating-system-level virtualization on Linux.[2] Docker uses resource isolation features of the Linux kernel such ascgroups and kernel namespaces to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines.[3]”

From a developer perspective Docker promises us the opportunity to forget about the “it works in my local environment but not in production” problem as well as the “it works on my Ubuntu machine but not on my buddy’s Mac three feet away” scenario. 

Now, with the magic of a definition file, it is super easy to port an app between environments: from local to lab, and later to production. Docker is incredibly fast and thanks to the use of some linux kernel features like namespaces, we have isolation for filesystem, networks and processes. 


This consistency is an incredible opportunity for developers, but it’s an especially big win for our users: with Docker we can reduce highly disruptive “environmental issues” to almost zero percent. 

Did I just say the word disruptive? Oh right, container revolution, blah blah. :)

Step #1: Prepare Your Infrastructure / Server Environment

Let’s “dockerize” a basic Rails app.This is what the app looks like. It was created using “Rails new Rails-App” (if you don’t have Rails you can just follow the installation instructions here) 

First, you need to have Docker running. To do so, you can just check the docker documentation, which is really quite easy to follow. Choose your platform, follow the instructions, and voilà! 

Once installed, check that the Docker daemon is running properly by typing:

$ docker -v

Docker version 1.7.0, build 0baf609 (this will probably change based on the installation type/platform you have chosen)

Step #2: Build Your Image

Next up we need to build our Rails image. Docker uses a definition file to describe what the environment will contain. Usually it’s named Dockerfile (you can use a different name also), so for simplicity let’s create a file in our app directory called “Dockerfile” and add a few lines in there (gist):

# Base image FROM ruby:latest 

ENV HOME /home/rails/webapp 

# Install PGsql dependencies and js engine 

RUN apt-get update -qq && apt-get install -y build-essential libpq-dev nodejs 

WORKDIR $HOME 

# Install gems 

ADD Gemfile* $HOME/ 

RUN bundle install 

# Add the app code 

ADD . $HOME 

# Default command 

CMD ["rails", "server", "--binding", "0.0.0.0”]

Okay...so what’s a “Docker image” for real? 

An image is a read-only template that Docker uses to run your code through a container. It contains a complete environment definition: it has the OS binaries, libraries, dependencies and all the applications that you need to run your code or application. All the magic is stuffed into it, so pay attention! 

Images contain layers (I won’t explain much about them here, since it’s a big topic that requires its own blog post). Every instruction creates a new layer in the filesystem. And thanks to the use of a union filesystem, those layers are “combined” into a single filesystem. Neat and tidy. 

An image can be built and pushed into a registry, like Docker Hub, or Quay.io (or even a custom one), just like you would do with GitHub. You can even have public or private repositories, so others can leverage your image / template, or you can re-use for other purposes.

Digging into your Dockerfile

To help us understand how this all works, let’s examine our freshly baked Rails Dockerfile.

FROM ruby:latest - This is the first instruction you have to have in your Dockerfile, with this instruction we are defining the base image. In our case, it will use this base image https://registry.hub.docker.com/u/library/ruby/, which actually has an interesting hierarchy:

• 
  
• Ruby is based on buildpack-deps:jessie which is based on buildpack-deps:jessie-scm which is based on buildpack-deps:jessie-curl, which is finally (!) based on debian:jessie.
• 
  
• As you can see, between images there exist some kind of “inheritance” concept where you can “extend” your images from others. It’s a great thing since you can build your environments based on trusted/stable (if you find them! and still be careful) images.

ENV HOME /home/rails/webapp - Just defining an environment variable.

RUN apt-get update -qq && apt-get install -y build-essential nodejs

• The RUN instruction executes a command in the docker container. So the “apt-get …” command will update the OS packages list and will install some libraries among nodejs.

WORKDIR $HOME - The WORKDIR instruction sets the working directory for any RUN, CMD, ENTRYPOINT, COPY and ADD instructions.

ADD Gemfile* $HOME

/RUN bundle install

• 
  
• Copy all the gem files definitions into the filesystem in the container and execute the command to install the gems. (I’ll explain why I’m doing this, in the next “Using Cache in Docker” post :) )

ADD . $HOME - Copy all the website files into the container.

CMD ["rails", "server", "--binding", "0.0.0.0"] - Specify the default command for when the container runs.

Step #3 - Build and Run Your Web App

Now that we have a better idea of our Dockerfile, let’s get our hands dirty! We need to build and run the web app:

$ docker build -t ruby-app .

Since we don’t have a Ruby image downloaded yet, it will pull the latest from Docker Hub and then run all the instructions from the Dockerfile. You should end up with something like this:

Later we can check the image using:

$ docker images

Let’s create a container and run the app.

$ docker run -d -p 3000:3000 rails-app

The command above will create a docker container using the “ruby-app” image you created in Step #2. The “-d” flag tells docker daemon to run this container in “daemon mode”.

Remember our CMD instruction in the Dockerfile? Well that is what’s running in the container “rails server --binding 0.0.0.0”

You can just open your browser at: http://localhost:3000 or you can get the container IP:

docker inspect 8f4fec2497f5 | grep IPAddress

(you can also run docker inspect --format '{{.NetworkSettings.IPAddress}}' 8f4fec2497f5 )

In my case it is: "IPAddress": "172.17.0.2"

So, just open the browser and point it to http://172.17.0.2:3000 and you will see the rails app running :)

One last interesting command about the run command we used is the -p flag.

docker run -d -p 3000:3000 ruby-app

When using the -p flag docker let us choose a port binding between the host and the container. Without this flag we could get into the rails app from outside the container. We could even choose a different port like: 

docker run -d -p 5000:3000 ruby-app

Or let docker choose a random port like

docker run -d -p 3000 ruby-app

To see what port docker has chosen, we can run “docker ps”

Or let docker choose a random port like docker run -d -p 3000 ruby-app To see what port docker has chosen, we can run “docker ps”

And in the port column you will see that the assigned port is 32769.

Also you could do:

$docker port 284bb5e37f44

Result: 3000/tcp -> 0.0.0.0:32769

And in the port column you will see that the assigned port is 32769. Also you could do: $docker port 284bb5e37f44 Result: 3000/tcp -> 0.0.0.0:32769

Using MongoDB With Ruby On Rails 5

In this post I am going to walk you through installing Ruby on Rails 5 using rbenv and use the Mongoid MongoDB driver for Ruby. MongoDB is a fantastic NoSQL database that is incredibly scalable and fast which makes a good combo with Rails. We will be using Linux Ubuntu 16.04 with MongoDB and Rails already installed.

Create a Rails App (Without Active Record)

rails new myapp --skip-active-record

Using the –skip-active-record option will create the app without the database.yml config file. We will use a mongoid config file instead. This will also prevent using the sqlite gem. We will add the Mongoid gem below

Edit Gemfile

Add the following to your Gemfile

gem 'mongoid', '~> 5.1.0'

Generate Mongoid Config File

rails g mongoid:config

This will create config/mongoid.yml

Thats It! you should now be able to run “rails s” and use MongoDB

rails g scaffold post title body author created

Now visit “http://localhost:3000/posts” and you should have CRUD functionality using MongoDB

If you did NOT use the “–skip-active-record”

Remove Gem “sqlite” from the Gemfile

Delete the database.yml file

Go to config/application.rb and remove “require rails/all” and replace with…


require "action_controller/railtie"
require "action_mailer/railtie"
require "rails/test_unit/railtie"

Comment out any line that has “active_record” in it in the following files

/config/development.rb
/config/production.rb
/config/initializers/new_framework_defaults.rb

Accessing helper modules into decorate with Rails 4

Additionally, a decorator has access to Rails helper modules via the helper proxy method. This is useful when you want to hide complex logic from the templates.

class PersonDecorator < Draper::Decorator
  delegate_all

  def author_headline
    if author == helper.current_user
      h.content_tag(:h3, 'You')
    else
      h.content_tag(:h3, author.name)
    end
  end
end

Now in your template you just call @person.author_headline and you are done. No conditions in the template. Your designers will be thankful!

Access current_user into decorate like below.

h.current_user