FastAPI

explain fastapi

FastAPI is a modern, fast (high-performance), web framework for building APIs with Python. It is based on standard Python type hints and offers automatic validation and serialization, which makes it an attractive choice for developers looking to create APIs efficiently.

Key Features of FastAPI:

Fast:
- FastAPI is one of the fastest Python frameworks, thanks to its use of asynchronous programming based on Python’s asyncio library. It’s comparable to other high-performance frameworks like Node.js and Go.
Type Hints & Validation:
- FastAPI leverages Python's type hints to provide input validation, serialization, and documentation automatically. For example, if you specify a field as an integer, FastAPI will automatically validate the input and ensure it's of the correct type.
Automatic Interactive Documentation:
- FastAPI automatically generates interactive API documentation with Swagger UI and ReDoc. You can explore and test your API directly from the browser.
Dependency Injection:
- FastAPI supports dependency injection, which allows you to define reusable components and services that can be injected into your endpoints. This can help manage database connections, authentication, and other cross-cutting concerns.
Asynchronous Support:
- It natively supports asynchronous request handling, making it ideal for applications that require non-blocking I/O operations, such as database queries, calling external APIs, or handling file uploads.
Data Validation and Serialization:
- FastAPI automatically validates the request data and serializes the response data based on the Python types you define. This reduces boilerplate code and potential errors.
Background Tasks:
- You can easily define background tasks to be executed after returning a response, useful for tasks like sending emails or processing data.
Security:
- FastAPI provides tools for handling authentication and authorization. It includes utilities to work with OAuth2, JWT (JSON Web Tokens), and more.
High Scalability:
- FastAPI is built on top of Starlette for the web parts and Pydantic for data handling, making it highly scalable for large applications.

Basic Example:

Here’s a simple FastAPI example:

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}

How FastAPI Works:

Endpoints: You define endpoints using Python functions, and you can specify the HTTP methods (GET, POST, etc.) by decorating these functions with @app.get(), @app.post(), etc.
Path Parameters: You can define dynamic routes using path parameters. For example, /items/{item_id} will match any path that starts with /items/ and ends with a number (or other types, as specified).
Query Parameters: You can add query parameters by specifying them as function arguments with default values.
Data Models: You can use Pydantic models to define the shape of the data you expect in your requests or responses.

Running a FastAPI App:

To run the FastAPI app, you typically use an ASGI server like uvicorn:

uvicorn main:app --reload

main:app refers to the app instance in the main.py file.
--reload enables the server to reload when the code changes, useful during development.

Use Cases:

FastAPI is suitable for building RESTful APIs, microservices, asynchronous web applications, and any other project where speed and developer productivity are crucial.

Would you like to know more details about specific features or how to set up a FastAPI project?

Async vs Sync?

In the context of web frameworks like FastAPI, understanding the difference between asynchronous (async) and synchronous (sync) programming is crucial for optimizing performance and handling I/O-bound operations effectively. Here’s an explanation of both concepts:

Synchronous (Sync) Programming

Blocking Operations: In synchronous programming, tasks are executed one after the other. Each task must complete before the next one starts. If a task involves waiting (e.g., a database query, API call, or file I/O), the entire program waits (or "blocks") until that task finishes.
Single Thread: Typically, synchronous operations run on a single thread. Even if a task is just waiting for an external resource (like data from a database), it occupies the thread and prevents other tasks from being executed until it finishes.

Example:

import time

def task1():
    print("Task 1 started")
    time.sleep(2)  # Simulate a blocking operation
    print("Task 1 finished")

def task2():
    print("Task 2 started")
    time.sleep(2)  # Simulate another blocking operation
    print("Task 2 finished")

task1()
task2()

In this example, task1 will finish before task2 starts, and the entire program will take 4 seconds to complete.

Asynchronous (Async) Programming

Non-Blocking Operations: Asynchronous programming allows tasks to be executed concurrently. When a task is waiting for something (e.g., I/O operation), the program can move on to execute other tasks instead of waiting.
Event Loop: Async programming is typically managed by an event loop that schedules and handles multiple tasks. Tasks that involve waiting yield control back to the event loop, allowing other tasks to run during that time.
Concurrency Without Multithreading: Asynchronous operations can achieve concurrency (running multiple tasks seemingly at the same time) without needing multiple threads. This is particularly efficient for I/O-bound tasks, where waiting is common.

Example:

import asyncio

async def task1():
    print("Task 1 started")
    await asyncio.sleep(2)  # Simulate a non-blocking operation
    print("Task 1 finished")

async def task2():
    print("Task 2 started")
    await asyncio.sleep(2)  # Simulate another non-blocking operation
    print("Task 2 finished")

async def main():
    await asyncio.gather(task1(), task2())

asyncio.run(main())

Here, task1 and task2 run concurrently, so the total time is approximately 2 seconds instead of 4.

When to Use Async vs. Sync

Use Sync:
- CPU-bound tasks: If your application is mostly performing calculations or other CPU-intensive operations where there's little waiting time, synchronous code might be sufficient.
- Simplicity: Sync code is generally easier to write and debug. If your app is simple and doesn’t need to handle many I/O operations, sync might be the way to go.
Use Async:
- I/O-bound tasks: If your application involves a lot of waiting (e.g., for API responses, database queries, file I/O), async can be much more efficient.
- High concurrency: Async programming shines when your application needs to handle many simultaneous tasks (like in web servers handling many requests at once).
- Scalability: Asynchronous code can help your application scale better under load, as it uses system resources more efficiently.

FastAPI and Async

FastAPI is designed to support asynchronous programming natively. This means you can define your API endpoints as async functions, allowing them to handle I/O-bound operations efficiently. Here’s a quick example:

from fastapi import FastAPI
import asyncio

app = FastAPI()

@app.get("/async-task")
async def async_task():
    await asyncio.sleep(2)
    return {"message": "Async task completed"}

@app.get("/sync-task")
def sync_task():
    import time
    time.sleep(2)
    return {"message": "Sync task completed"}

The /async-task endpoint will be non-blocking, allowing other requests to be handled while it’s waiting.
The /sync-task endpoint will block the server for 2 seconds per request.

Summary

Sync: Tasks are executed one after another, waiting (blocking) for each task to complete before starting the next.
Async: Tasks can be executed concurrently, allowing the program to perform other tasks while waiting for certain operations to complete, improving efficiency in I/O-bound applications.

Would you like to see examples or explore how to convert synchronous code to asynchronous in more detail?

flask vs fastapi?

When choosing between Flask and FastAPI, it's important to consider your project’s requirements, team familiarity, and the specific features you need. Here’s a comparison to help you decide:

1. Performance

FastAPI:
- Designed for speed, it’s one of the fastest Python frameworks, leveraging asynchronous programming. It's built on top of Starlette and Pydantic, which are optimized for high performance. FastAPI is particularly beneficial for applications with high concurrency needs or I/O-bound operations.
Flask:
- Flask is a synchronous framework, which can make it slower in high-concurrency scenarios. However, it is sufficient for many applications that don’t require handling a large number of simultaneous connections.

2. Ease of Use

Flask:
- Flask is very simple and beginner-friendly. It’s often described as a micro-framework because it provides the essentials but leaves out many advanced features, allowing developers to pick and choose the libraries and extensions they need. This makes Flask easy to get started with and highly customizable.
FastAPI:
- FastAPI is also user-friendly, but it assumes some familiarity with Python's type hints and asynchronous programming. It’s easy to use but can have a steeper learning curve compared to Flask, especially if you're new to async programming.

3. Async Support

FastAPI:
- Natively supports asynchronous routes using Python's async and await keywords. This allows you to handle requests asynchronously, making it ideal for applications that need to perform non-blocking I/O operations, like making API calls or querying databases.
Flask:
- Flask doesn’t natively support async programming. However, there are workarounds like using gevent, eventlet, or quart (a Flask-inspired framework with async support). These workarounds can add complexity, and they don't provide the same seamless experience as FastAPI.

4. Data Validation

FastAPI:
- Automatically handles input validation and serialization using Pydantic. This reduces boilerplate code and provides clear error messages. FastAPI’s data validation is integrated into the framework, making it powerful and easy to use.
Flask:
- Flask doesn’t include built-in data validation. You can use libraries like marshmallow or Flask-RESTful to achieve similar functionality, but it requires more setup and additional code.

5. Automatic Documentation

FastAPI:
- FastAPI automatically generates interactive API documentation with Swagger UI and ReDoc. This feature is incredibly useful for development and client interaction, as you get clear and accessible documentation out-of-the-box without any extra configuration.
Flask:
- Flask does not provide automatic API documentation. You can add documentation manually or use tools like Flask-RESTPlus or apispec, but this requires additional setup and effort.

6. Flexibility and Ecosystem

Flask:
- Flask’s minimalistic approach gives you the flexibility to use whatever libraries or tools you prefer. It has a mature and extensive ecosystem, with many extensions available for everything from authentication to ORM integration.
FastAPI:
- FastAPI is less modular than Flask in the sense that it comes with a lot of features baked in (like validation and documentation). While it's still flexible, it offers a more opinionated approach to how certain tasks should be handled.

7. Community and Ecosystem

Flask:
- Flask has been around since 2010 and has a large, active community. There are countless tutorials, extensions, and plugins available, making it easier to find solutions to common problems.
FastAPI:
- FastAPI is newer (released in 2018), but it has quickly gained popularity due to its performance and features. Its community is growing rapidly, but it may not yet have the same level of resources as Flask.

8. Use Cases

Flask:
- Ideal for small to medium-sized projects, MVPs, or applications where simplicity and flexibility are key. It’s also a good choice if your team is already familiar with Flask or if you need to extend an existing Flask application.
FastAPI:
- Best suited for projects that require high performance, API-heavy applications, or microservices. It’s also a great choice for teams looking to leverage modern Python features like type hints and asynchronous programming.

9. Learning Curve

Flask:
- Generally easier to learn and get started with, especially for beginners or those familiar with traditional synchronous programming.
FastAPI:
- While not overly complex, it may require a bit more time to learn, particularly if you’re new to async programming or Python’s type system.

Summary

Choose Flask if:
- You need a simple, easy-to-use framework with a large ecosystem and don’t require async capabilities. It's great for small to medium projects, especially when speed of development is more important than raw performance.
Choose FastAPI if:
- You need high performance, especially for handling a large number of concurrent connections, and want to leverage Python's async capabilities. It’s ideal for modern API development, microservices, or projects where automatic validation and documentation are beneficial.

Would you like to dive deeper into a specific aspect of either framework?

How to deploy FastAPI?

Deploying a FastAPI application involves several steps, including setting up a web server, configuring it to serve your FastAPI app, and ensuring that it runs reliably in production. Below are the typical steps to deploy FastAPI using different methods:

1. Deployment on a Local Server (Using Uvicorn with Gunicorn)

This is one of the most common and robust methods to deploy FastAPI on a production server.

Step 1: Install Dependencies

You need to install Uvicorn and Gunicorn, which are ASGI servers used to serve your FastAPI app in production.

pip install fastapi uvicorn gunicorn

Step 2: Create a Gunicorn Configuration

Gunicorn will manage multiple Uvicorn worker processes. Create a gunicorn_config.py file:

# gunicorn_config.py

workers = 4
worker_class = "uvicorn.workers.UvicornWorker"
bind = "0.0.0.0:8000"

workers: Number of worker processes. Set this according to the CPU cores available.
worker_class: Specify Uvicorn as the worker class.
bind: The address and port where the app should listen.

Step 3: Run Gunicorn

Run Gunicorn to start your application:

gunicorn -c gunicorn_config.py myapp:app

myapp:app refers to the app object in your myapp.py file.

Step 4: Reverse Proxy with Nginx (Optional but Recommended)

Set up Nginx as a reverse proxy to manage your Gunicorn instance, providing features like load balancing and SSL termination.

Nginx Configuration:

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

2. Deployment on Cloud Services

1. Deploying on AWS (Amazon Web Services)

AWS offers several services like EC2, Elastic Beanstalk, or even Lambda for deploying FastAPI.

Using EC2:

Launch an EC2 Instance: Choose an instance, and set up a security group to allow HTTP/HTTPS traffic.
Install Docker or Directly Install Uvicorn: SSH into the instance, and either use Docker or install Uvicorn/Gunicorn as shown above.
Run the FastAPI App: Use the same Gunicorn setup or a Docker container.
Set up Nginx: Optionally configure Nginx as a reverse proxy.

Using Elastic Beanstalk:

Create an Application: Use the Elastic Beanstalk CLI to create and deploy your FastAPI app.
Configure: Customize instance types, scaling, and environment variables.

Using AWS Lambda with API Gateway:

Serverless Deployment: Use a serverless framework or AWS SAM (Serverless Application Model) to deploy FastAPI as a Lambda function.
Set up API Gateway: Expose your FastAPI through API Gateway to handle HTTP requests.

2. Deploying on Heroku

Heroku is a platform as a service (PaaS) that makes deploying applications simple.

Create a Procfile:

web: gunicorn -w 4 -k uvicorn.workers.UvicornWorker myapp:app

Create requirements.txt:
```
fastapi
uvicorn[standard]
gunicorn
```
Deploy to Heroku:
- Install the Heroku CLI and log in.
- Create a new app: heroku create your-app-name.
- Push your code to Heroku: git push heroku main.
- Scale the web process: heroku ps:scale web=1.

3. Deploying on Google Cloud Platform (GCP)

GCP offers services like Google App Engine, Cloud Run, or Compute Engine for deploying FastAPI.

Using Google App Engine:

App Engine Configuration: Create an app.yaml file with your app configuration.
Deploy: Use the gcloud CLI to deploy your app: gcloud app deploy.

Using Google Cloud Run:

Containerize the App: Create a Dockerfile for your FastAPI app.
Deploy: Use the Google Cloud CLI: gcloud run deploy --image gcr.io/your-project-id/your-image.

3. Containerized Deployment (Using Docker)

Docker provides a consistent environment for deploying applications. This is especially useful for deployment across different environments.

Step 1: Create a Dockerfile

# Start with a base image
FROM python:3.11-slim

# Set the working directory
WORKDIR /app

# Install dependencies
COPY requirements.txt requirements.txt
RUN pip install --no-cache-dir -r requirements.txt

# Copy the application code
COPY . .

# Command to run the app with Uvicorn
CMD ["uvicorn", "myapp:app", "--host", "0.0.0.0", "--port", "8000"]

Step 2: Build and Run the Docker Container

docker build -t myfastapiapp .
docker run -d -p 8000:8000 myfastapiapp

Step 3: Use Docker Compose (Optional)

If your app depends on other services (e.g., a database), you can use Docker Compose:

docker-compose.yml:

version: '3.8'
services:
  web:
    build: .
    ports:
      - "8000:8000"
    depends_on:
      - db

  db:
    image: postgres
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: mydb

docker-compose up -d

4. Deploying with CI/CD (Continuous Integration/Continuous Deployment)

You can automate the deployment of your FastAPI app using CI/CD pipelines on platforms like GitHub Actions, GitLab CI/CD, or Jenkins.

GitHub Actions: Set up a workflow that builds and deploys your app whenever you push to the main branch.
GitLab CI/CD: Create a .gitlab-ci.yml file to automate the deployment process.
Jenkins: Configure Jenkins to build, test, and deploy your FastAPI app using pipelines.

5. Other Deployment Methods

DigitalOcean: Use DigitalOcean’s Droplets (for virtual servers) or App Platform for a more managed experience.
Azure: Deploy using Azure App Service, Azure Kubernetes Service, or Azure Functions (for serverless deployment).

Summary

Basic Deployment: Use Uvicorn with Gunicorn, and optionally set up Nginx as a reverse proxy.
Containerized Deployment: Use Docker for consistent and portable deployments.
Cloud Platforms: Use services like AWS, GCP, or Heroku for managed deployment.
CI/CD: Automate deployments using tools like GitHub Actions or GitLab CI/CD.

Would you like more details on any specific deployment method?

"unicorn main:app --reload".why are we using this command?

The command uvicorn main:app --reload is used to run a FastAPI application using Uvicorn, an ASGI (Asynchronous Server Gateway Interface) server. Here's a breakdown of what each part of the command does:

Breakdown of the Command

uvicorn:
- Uvicorn is a fast ASGI server implementation, which is ideal for running asynchronous Python web applications, like those built with FastAPI.
- It can serve both synchronous and asynchronous web applications, but it’s particularly optimized for asynchronous apps.
main:app:
- main: Refers to the Python file where your FastAPI application instance is defined. In this case, it's assumed that your main file is named main.py.
- app: Refers to the FastAPI application instance within that file. So, in main.py, you should have something like:
  from fastapi import FastAPI app = FastAPI() @app.get("/") def read_root(): return {"Hello": "World"}
- Putting main:app together, Uvicorn understands that it should look for the app instance inside the main.py file.
--reload:
- This option enables the auto-reload feature.
- When --reload is used, Uvicorn will automatically restart the server whenever it detects changes in your code. This is very useful during development because it means you don't have to manually restart the server every time you make a change to your code.

Why Use This Command?

Development Convenience: The --reload flag is especially helpful during development. It saves time and makes the development process smoother because it automatically applies any code changes without needing a manual server restart.
Running the Server: uvicorn main:app starts the ASGI server, which is necessary to serve your FastAPI application to handle incoming HTTP requests.
Specifying the Entry Point: main:app tells Uvicorn where to find your FastAPI application instance, allowing it to properly start and serve the app.

When to Use `--reload` and When Not To

Use --reload: During development, when you are actively making changes to your code and need the server to pick up those changes automatically.
Avoid --reload: In production environments, because the auto-reload feature can consume extra resources and isn't necessary once your app is stable. For production, you would typically run the server without --reload and with additional configurations to optimize performance and reliability, often using something like Gunicorn to manage multiple worker processes.

Would you like to know more about deploying or configuring FastAPI for production?

Set up HTTPS?

Setting up HTTPS for your FastAPI application ensures that all data transferred between the server and clients is encrypted, providing a secure communication channel. Here’s a guide to setting up HTTPS using various methods:

1. Using Uvicorn Directly with SSL Certificates

If you’re running your FastAPI app directly with Uvicorn, you can enable HTTPS by providing SSL certificates.

Step 1: Obtain SSL Certificates

You can obtain SSL certificates from a Certificate Authority (CA) like Let's Encrypt, which offers free SSL certificates. Here's how you can use Let's Encrypt with Certbot:

sudo apt-get update
sudo apt-get install certbot
sudo certbot certonly --standalone -d yourdomain.com

After completing this, you will have your SSL certificate (fullchain.pem) and private key (privkey.pem) typically located in /etc/letsencrypt/live/yourdomain.com/.

Step 2: Run Uvicorn with SSL

Use the --ssl-keyfile and --ssl-certfile options with Uvicorn to specify your SSL certificate and key.

uvicorn main:app --host 0.0.0.0 --port 443 --ssl-keyfile=/etc/letsencrypt/live/yourdomain.com/privkey.pem --ssl-certfile=/etc/letsencrypt/live/yourdomain.com/fullchain.pem

--host 0.0.0.0: Binds the server to all available IP addresses on the machine.
--port 443: This is the standard port for HTTPS.
--ssl-keyfile and --ssl-certfile: Paths to your SSL certificate and key.

2. Using Nginx as a Reverse Proxy with HTTPS

A more common approach in production is to use Nginx as a reverse proxy in front of Uvicorn, handling the SSL termination (i.e., Nginx manages the HTTPS connection, and communicates with Uvicorn over HTTP).

Step 1: Install Nginx

If Nginx isn’t installed, you can install it with:

sudo apt-get update
sudo apt-get install nginx

Step 2: Obtain SSL Certificates

Use Certbot to obtain SSL certificates for Nginx:

sudo apt-get install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com

This command will automatically configure Nginx to use the obtained SSL certificates.

Step 3: Configure Nginx

Edit the Nginx configuration file to proxy requests to your Uvicorn server:

sudo nano /etc/nginx/sites-available/yourdomain.com

Here’s a basic configuration:

server {
    listen 80;
    server_name yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8000;  # Uvicorn running on port 8000
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Port 80: Redirects all HTTP traffic to HTTPS.
Port 443: Handles HTTPS traffic and proxies it to the Uvicorn server running on port 8000.

Step 4: Restart Nginx

Apply the changes by restarting Nginx:

sudo systemctl restart nginx

3. Using Docker with Nginx and Let's Encrypt

If you prefer Docker, you can set up a Dockerized environment with Nginx handling HTTPS, using a setup like this:

Step 1: Create a docker-compose.yml

Here’s an example docker-compose.yml that uses Nginx as a reverse proxy with HTTPS:

version: '3.8'

services:
  app:
    image: myfastapiapp:latest
    container_name: fastapi_app
    expose:
      - 8000
    environment:
      - UVICORN_HOST=0.0.0.0
      - UVICORN_PORT=8000
    command: uvicorn main:app --host 0.0.0.0 --port 8000

  nginx:
    image: nginx:latest
    container_name: nginx
    ports:
      - 80:80
      - 443:443
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - /etc/letsencrypt:/etc/letsencrypt
    depends_on:
      - app

  certbot:
    image: certbot/certbot
    container_name: certbot
    volumes:
      - /etc/letsencrypt:/etc/letsencrypt
    command: certonly --webroot --webroot-path=/var/www/certbot --email you@example.com --agree-tos --no-eff-email -d yourdomain.com

Step 2: Create the Nginx Configuration

Create an nginx.conf file:

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://app:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }
}

server {
    listen 443 ssl;
    server_name yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

    location / {
        proxy_pass http://app:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Step 3: Run Docker Compose

Run the stack:

docker-compose up -d

This setup will automatically handle SSL certificates and HTTPS configuration.

Summary

Direct Uvicorn SSL: Simple but suitable mainly for development or simple production cases.
Nginx as Reverse Proxy: A more robust and scalable solution, widely used in production environments.
Dockerized Setup: Ideal for containerized deployments, combining Nginx, FastAPI, and Let's Encrypt in a consistent environment.

Would you like help with a specific step or more details on any of the approaches

from fastapi import FastAPI

app = FastAPI()

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

explain this code?

Certainly! This is a simple FastAPI application with a single endpoint. Here's a detailed explanation of each part of the code:

1. Importing FastAPI

from fastapi import FastAPI

from fastapi import FastAPI: This imports the FastAPI class from the fastapi module. FastAPI is the main class that you use to create your FastAPI application.

2. Creating an Instance of FastAPI

app = FastAPI()

app = FastAPI(): This creates an instance of the FastAPI class. This app instance is your ASGI (Asynchronous Server Gateway Interface) application. You will use this instance to define your routes and handlers.

3. Defining a Route

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

@app.get("/"): This is a decorator that tells FastAPI that the function read_root should handle GET requests to the root URL path ("/"). In FastAPI, decorators are used to map HTTP requests to specific functions.
def read_root():: This defines a Python function named read_root. This function will be called when a client makes a GET request to the root URL ("/").
return {"Hello": "World"}: This returns a JSON response with the content {"Hello": "World"}. FastAPI automatically converts this Python dictionary into a JSON response.

Summary

Import: Import the FastAPI class from the fastapi module.
Create App: Instantiate the FastAPI class to create an application instance.
Define Route: Use the @app.get("/") decorator to define a route that listens for GET requests at the root URL. The associated function returns a JSON response.

What Happens When You Run This Code?

Start the Server: When you run this FastAPI application using a server like Uvicorn (uvicorn main:app --reload), it will start a web server that listens for HTTP requests.
Handle Requests: When you access the root URL (http://localhost:8000/), the read_root function is called, and it returns a JSON response {"Hello": "World"}.
Automatic Documentation: FastAPI also provides automatic interactive API documentation that can be accessed at /docs (Swagger UI) or /redoc (ReDoc) when you run the server.

This basic setup is a starting point for building more complex APIs with FastAPI. You can add more routes, handle different HTTP methods, and include features like request validation, authentication, and more.

Add more routes?

Adding more routes to your FastAPI application allows you to define additional endpoints that your application can handle. Each route corresponds to a specific URL path and HTTP method. Here’s how you can add more routes, handle different HTTP methods, and implement various functionalities.

Example with Additional Routes

Let's expand the initial FastAPI application by adding more routes and demonstrating how to handle different HTTP methods:

from fastapi import FastAPI

app = FastAPI()

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

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

# POST request route
@app.post("/items/")
def create_item(item: dict):
    return {"item": item}

# PUT request route
@app.put("/items/{item_id}")
def update_item(item_id: int, item: dict):
    return {"item_id": item_id, "updated_item": item}

# DELETE request route
@app.delete("/items/{item_id}")
def delete_item(item_id: int):
    return {"message": f"Item with id {item_id} deleted"}

# Route with query parameter
@app.get("/search/")
def search_items(query: str):
    return {"query": query}

Explanation of Each Route

Root Route
```
@app.get("/")
def read_root():
    return {"Hello": "World"}
```
- This handles GET requests to the root URL and returns a simple JSON response.
Path Parameter Route
```
@app.get("/items/{item_id}")
def read_item(item_id: int, q: str = None):
    return {"item_id": item_id, "q": q}
```
- Path Parameter: item_id is a path parameter, which means it's extracted from the URL. In this case, item_id must be an integer.
- Query Parameter: q is an optional query parameter. Query parameters are appended to the URL after a question mark (e.g., /items/42?q=search).
POST Request Route
```
@app.post("/items/")
def create_item(item: dict):
    return {"item": item}
```
- POST: This route handles POST requests, which are typically used to create new resources.
- Request Body: The item parameter is expected to be a dictionary, which FastAPI will automatically parse from the request body.
PUT Request Route
```
@app.put("/items/{item_id}")
def update_item(item_id: int, item: dict):
    return {"item_id": item_id, "updated_item": item}
```
- PUT: This route handles PUT requests, which are used to update an existing resource.
- Path Parameter: item_id is extracted from the URL.
- Request Body: item contains the new data to update the resource.
DELETE Request Route
```
@app.delete("/items/{item_id}")
def delete_item(item_id: int):
    return {"message": f"Item with id {item_id} deleted"}
```
- DELETE: This route handles DELETE requests, which are used to delete a resource.
- Path Parameter: item_id specifies which item to delete.
Query Parameter Route
```
@app.get("/search/")
def search_items(query: str):
    return {"query": query}
```
- Query Parameter: query is a query parameter that the client must provide in the URL (e.g., /search/?query=example).

Testing Your Routes

You can test these routes using tools like:

Browser: For simple GET requests.

Curl: For command-line testing:

curl http://localhost:8000/items/42?q=test

Postman: For more advanced testing, including POST, PUT, and DELETE requests.
Interactive Documentation: FastAPI provides interactive API documentation at /docs (Swagger UI) and /redoc (ReDoc) when the server is running. You can use these interfaces to test your routes directly.

Summary

GET Routes: Used to retrieve data.
POST Routes: Used to create new data.
PUT Routes: Used to update existing data.
DELETE Routes: Used to remove data.
Path Parameters: Extracted from the URL path.
Query Parameters: Appended to the URL after a question mark.

This expanded example provides a solid foundation for building and testing a FastAPI application with multiple routes and different HTTP methods.

why 8000 default ?

The default port 8000 is commonly used for development servers in many web frameworks, including FastAPI, Django, and others. Here’s why 8000 is used as a default and some details about port selection:

Reasons for Using Port 8000

Convention: Port 8000 has become a convention for development servers because it's a high-numbered port that is unlikely to be in use by other standard services. It avoids conflicts with well-known ports used by other protocols (e.g., HTTP on port 80, HTTPS on port 443, etc.).
Non-Privileged Port: Ports below 1024 are considered privileged and typically require administrative rights to bind to. Port 8000 is above this range, so it can be used without special permissions, making it suitable for development.
Avoiding Conflicts: Development environments often need a port that is less likely to conflict with ports used by other applications or services on the same machine. Port 8000 is chosen because it's usually free and not reserved for other applications.

How to Change the Port

While 8000 is the default, you can specify a different port when running your FastAPI application with Uvicorn by using the --port option:

uvicorn main:app --host 0.0.0.0 --port 8080

In this example:

--host 0.0.0.0: Binds to all available IP addresses.
--port 8080: Sets the port to 8080 instead of the default 8000.

Commonly Used Ports

Port 80: Default for HTTP.
Port 443: Default for HTTPS.
Port 3000: Common for development servers, particularly in Node.js environments.
Port 5000: Often used for Flask applications.

Summary

Port 8000 is used by default in many development setups due to its high number (avoiding conflicts with well-known ports) and its non-privileged status.
You can configure your application to run on any available port by specifying it in the server configuration or command-line arguments.

If you have any specific needs or configurations, you can always change the port to fit your development or deployment environment.

PreviousCelery Nextscheduling for basic Python for client.

Last updated 1 year ago

Key Features of FastAPI:

Basic Example:

How FastAPI Works:

Running a FastAPI App:

Use Cases:

Synchronous (Sync) Programming

Asynchronous (Async) Programming

When to Use Async vs. Sync

FastAPI and Async

Summary

1. Performance

2. Ease of Use

3. Async Support

4. Data Validation

5. Automatic Documentation

6. Flexibility and Ecosystem

7. Community and Ecosystem

8. Use Cases

9. Learning Curve

Summary

1. Deployment on a Local Server (Using Uvicorn with Gunicorn)

2. Deployment on Cloud Services

3. Containerized Deployment (Using Docker)

4. Deploying with CI/CD (Continuous Integration/Continuous Deployment)

5. Other Deployment Methods

Summary

Breakdown of the Command

Why Use This Command?

When to Use --reload and When Not To

1. Using Uvicorn Directly with SSL Certificates

2. Using Nginx as a Reverse Proxy with HTTPS

3. Using Docker with Nginx and Let's Encrypt

Summary

1. Importing FastAPI

2. Creating an Instance of FastAPI

3. Defining a Route

Summary

What Happens When You Run This Code?

Example with Additional Routes

Explanation of Each Route

Testing Your Routes

Summary

Reasons for Using Port 8000

How to Change the Port

Commonly Used Ports

Summary

When to Use `--reload` and When Not To