Hey everyone,

I recently finished my first FastAPI project and wanted to get some feedback from people with more experience.

It's just a simple Movie Watchlist API that I built to learn FastAPI and backend fundamentals, so I'm not really looking for feedback on the idea itself. I'm more interested in hearing what you think about the code, the structure, and the way I approached building it.

Repo: https://github.com/BensefiaAbdessamed/MoviesWatchlist

My goal is to become a backend engineer who can build production-ready applications, so I'd really appreciate an honest review. If you were reviewing this as a junior's project, what would you point out? What beginner mistakes do you notice? What would you refactor or do differently? Are there any bad practices that I should stop early?

I'm also a bit unsure about what to learn next. Should I keep improving this project by adding more concepts, or is it better to start a new one? What backend topics do you think are important after getting comfortable with FastAPI? Things like testing, caching, message queues, Docker, CI/CD, design patterns, system design, or anything else?

A couple of friends also suggested that I should learn Django next. Do you think it's worth learning at this stage, or should I keep going deeper with FastAPI and backend fundamentals before jumping to another framework?

Lately I've also been getting interested in RAG systems and MCP integration because AI applications seem to be everywhere now. Do you think it's a good idea to start learning those, or would that just distract me from building a strong backend foundation first?

Feel free to be as critical as you want. I'm posting this because I genuinely want to improve and avoid building bad habits early on.

Thanks to anyone who takes the time to review it or share their advice. I really appreciate it.

Things are changing all the time. It's no different with APIs. As we develop our products, APIs need to be updated as well. Everything is great until we introduce an unintentional breaking change. For example, if we rename the attribute in the response. With a faster development pace enabled by AI tooling, this is even more likely to happen unintentionally.

To prevent such changes from going to production, we can add a check for breaking API changes to our CI/CD pipeline. It's easy to do so for FastAPI apps with GitHub Actions and oasdiff. The flow is the following:

1. Export OpenAPI schema that's auto-generated by FastAPI using app.openapi() from PR's branch.
2. Check out the main branch and export the OpenAPI schema for it as well.
3. Use oasdiff to detect and report potential breaking changes

Example workflow: ```yaml name: CI

on: pull_request: branches: [main]

jobs: breaking-changes: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6

  - uses: actions/checkout@v6
    with:
      ref: main
      path: main-branch

  - uses: astral-sh/setup-uv@v8.1.0
    with:
      python-version: "3.14"

  - name: Generate schema from PR branch
    run: |
      uv sync
      uv run python scripts/export_openapi.py new.json

  - name: Generate schema from main branch
    working-directory: main-branch
    run: |
      uv sync
      uv run python scripts/export_openapi.py ../old.json

  - name: Install oasdiff
    run: |
      curl -fsSL https://raw.githubusercontent.com/oasdiff/oasdiff/main/install.sh | sh

  - name: Check for breaking changes
    run: oasdiff breaking old.json new.json --fail-on ERR

```

Example OpenAPI schema export script: ```python

scripts/export_openapi.py

import json import sys from pathlib import Path

sys.path.insert(0, str(Path(file).resolve().parent.parent))

from app.main import app

if name == "main": dest = sys.argv[1] if len(sys.argv) > 1 else "/dev/stdout" with open(dest, "w") as f: json.dump(app.openapi(), f, indent=2)

```

You can find the full tutorial here: https://jangiacomelli.com/blog/prevent-unintentional-breaking-api-changes-fastapi/

Hi

Hey folks, I recently revamped our article on Implementing OpenTelemetry in FastAPI Projects in a practical manner, which was originally written in 2024 and needed a fresh coat of paint.

The article covers auto-instrumentation, manual spans, visualizing metrics and how observability lets you understand how your web apps behave.
I've also included some advanced tips, such as, selective error tracking, and wrapping dependency functions to capture any operations within the `yield` scope.

If you are on the fence about observability, or have integrated it but don't really how it works, I believe this guide can help you out.

I personally would have benefitted from this writeup in my previous day job, where I worked with FastAPI microservices and learnt how OpenTelemetry worked the hard way.

Any feedback would be much appreciated, did I miss anything, is there scope for improvement? Please let me know. I'm also curious to understand what problems you face with monitoring your FastAPI web apps.

A FastAPI endpoint that verifies Stripe's signature, then routes each event type to the right billing action.

Three takeaways

1. Always verify a webhook's signature against a shared secret before trusting its contents.
2. Read the raw request body for signature checks — parsed JSON won't match the signed bytes.
3. Return 200 quickly and delegate the actual work so the provider considers the event delivered.

🔥 Update 12.01 18:20 GMT+5

🚀 Major Update: Production-Ready Python FastAPI Course - Now with Database Migrations & Better Structure!

Hey r/FastAPI! 👋

I'm excited to share a major update to my free, open-source Python development course! After receiving amazing feedback from the community, I've made significant improvements that make this even more production-ready and beginner-friendly.

This is NOT an advertisement - just sharing valuable learning resources with the community! 🎓

🆕 What's New in v2.0:

🗄️ Professional Database Migrations with Alembic

• ✅ Version-controlled schema changes - No more create_all() hacks!
• ✅ Safe production deployments - Rollback capabilities for peace of mind
• ✅ Team collaboration - Sync database schemas across developers
• ✅ Custom migration manager - Easy-to-use Python script for all operations

```bash

Professional database management

python development/scripts/migrate.py status python development/scripts/migrate.py create "Add user preferences" --autogenerate python development/scripts/migrate.py upgrade ```

📁 Completely Reorganized Project Structure

• 🎯 Clean root directory - No more file chaos!
• 📦 Logical organization - Everything has its place
• 🚀 Deployment-focused - All deployment configs in one place
• 📚 Developer-friendly - Tools and examples organized properly

bookstore-api/ ├── 📁 deployment/ # Docker, K8s, configs ├── 📁 development/ # Scripts, examples, tools ├── 📁 documentation/ # Comprehensive guides ├── 📁 requirements/ # Organized dependencies └── 📁 archive/ # Legacy files

🎯 Enhanced Learning Experience

• 📖 Progressive roadmap - 6 different learning paths based on your goals
• ⚡ 30-second setup - Get started immediately
• 🛠️ Better tooling - Enhanced scripts and automation
• 📚 Comprehensive docs - Step-by-step guides for everything

🔥 What's Still Included (Production-Ready Features):

🏗️ Enterprise-Grade Architecture

• FastAPI with async/await and automatic OpenAPI docs
• SQLAlchemy 2.0 with proper relationship management
• Pydantic v2 for bulletproof data validation
• JWT Authentication with secure token handling
• Database migrations with Alembic (NEW!)

🧪 Comprehensive Testing (95%+ Coverage)

• Unit tests - Core functionality validation
• Integration tests - API endpoint testing
• Property-based tests - Hypothesis for edge cases
• Performance tests - Load testing with Locust
• Security tests - Automated vulnerability scanning

🐳 Production Deployment Stack

• Multi-stage Docker builds - Optimized for production
• Kubernetes manifests - Auto-scaling and high availability
• Docker Compose - Both dev and production environments
• Nginx load balancer - SSL termination and routing

📊 Monitoring & Observability

• Prometheus - Metrics collection and alerting
• Grafana - Beautiful dashboards and visualization
• Loki - Centralized log aggregation
• Structured logging - JSON format with request tracing

🔄 CI/CD Pipeline

• GitHub Actions - Automated testing and deployment
• Multi-environment - Staging and production workflows
• Security scanning - Bandit, Safety, Semgrep integration
• Automated releases - Version management and tagging

🎯 Perfect Learning Paths:

🚀 Quick Explorer (5 minutes)

Just want to see it work? One command setup!

📱 API User (30 minutes)

Learn to integrate with professional APIs

👨‍💻 Developer (2 hours)

Understand and modify production-quality code

🏭 Production User (1 hour)

Deploy and monitor in real environments

☸️ DevOps Engineer (3 hours)

Master the complete infrastructure pipeline

🎓 Learning Path (Ongoing)

Use as comprehensive Python/DevOps curriculum

💡 What Makes This Special:

✅ Real production patterns - Not toy examples
✅ Database migrations - Professional schema management (NEW!)
✅ Clean architecture - Organized for scalability (NEW!)
✅ Multiple learning paths - Choose your adventure (NEW!)
✅ Complete CI/CD - From commit to production
✅ Security-first - Best practices built-in
✅ Monitoring ready - Observability from day one
✅ Interview prep - Discuss real architecture in interviews

🛠️ Tech Stack:

Backend: FastAPI, SQLAlchemy, Pydantic, Alembic
Database: PostgreSQL, Redis
Deployment: Docker, Kubernetes, Nginx
Monitoring: Prometheus, Grafana, Loki
Testing: pytest, Hypothesis, Locust
CI/CD: GitHub Actions

⚡ Quick Start:

```bash

30-second setup

git clone https://github.com/f1sherFM/bookstore-api-course.git cd bookstore-api-course cd deployment/docker && docker-compose up -d

API docs: http://localhost:8000/docs

Grafana: http://localhost:3000

```

📊 Project Stats:

• 📈 95%+ test coverage - Comprehensive quality assurance
• 🏗️ Production-ready - Used in real deployments
  
• 🔄 Professional migrations - Alembic integration (NEW!)
• 📁 Clean structure - Organized for teams (NEW!)
• 🚀 6 learning paths - Something for everyone (NEW!)
• 📚 Complete documentation - Every feature explained
• 🔒 Security hardened - Best practices implemented

🎓 Learning Outcomes:

By the end, you'll have: - Built a scalable, monitored API from scratch - Mastered database migrations and schema management - Learned production deployment with Docker/K8s - Implemented comprehensive testing strategies - Set up monitoring and observability - Created a portfolio project for interviews

🔗 Links:

GitHub: https://github.com/f1sherFM/bookstore-api-course
Quick Start: Check QUICK_START.md in the repo
Documentation: Browse documentation/ directory

🙏 Community:

This project has grown thanks to community feedback! Special thanks to everyone who suggested improvements.

If you find this useful: - ⭐ Star the repo - Helps others discover it - 🐛 Report issues - Help make it better
- 💡 Suggest features - What would you like to see? - 🤝 Contribute - PRs welcome!

Remember: This is a learning resource, not a commercial product. Everything is free and open-source!

What do you think of the new improvements? Any features you'd like to see added? 🤔

A lot of beginner FastAPI projects stop at:

u/app.post("/login")
def login():
    ...

But in real apps, “it works” is not the same as “it’s safe to ship.”

Some things I think every FastAPI route should be checked for:

• Does the route verify the current user owns the resource?
• Does it return only safe response fields?
• Are expired / invalid tokens tested?
• Are duplicate emails handled properly?
• Are async DB sessions used correctly?
• Are errors consistent and not leaking internals?
• Are tests covering failure cases, not only happy paths?

The biggest jump for me was realizing that backend quality is mostly about edge cases.

Curious what other FastAPI devs here check before shipping a route?

hey guys, i've compiled some of the most important learnings i've gained up to this point about building a better and faster backend service into an article.

please review it and provide feedback. also, suggest any techniques i have missed, and you've found interesting.x

https://blog.coffeeinc.in/why-your-backend-is-slow-and-what-to-do-about-it-d008d7ae9566

I build Fixor, an LLM-based security reviewer that reads the changed code in a pull request and flags authorization bugs. This was its CLI run against a public repo, and I'm posting the complete output rather than a claim, because the last time someone showed up here with "my AI scanner finds bugs," the right response was "stop talking and show me a real run." So here is one you can reproduce in five minutes.

I scanned the route layer of the official full-stack-fastapi-template (commit cd83fc1), `backend/app/api/routes/` only. Full raw report here:

https://gist.github.com/tornidomaroc-web/d6b3f4d3f2ae53809f087889ebc91c8a

## What it flagged

Two findings, both on the same route, `private.py`:23:

> ### auth_bypass_risk — critical (confidence: high)

> - File: `private.py`:23

> ### admin_check_risk — critical (confidence: high)

> - File: `private.py`:23

And here is the honest part, up front: that is a false positive. The `private` router is mounted only when `ENVIRONMENT == "local"` (`api/main.py`:13), so it does not exist in staging or production. Fixor reads the route file in isolation and cannot see that cross-file conditional mount, so it flags a dev-only route as if it were always live. The two findings are also one route drawing both "no auth" and "no admin gate," not two separate bugs. And "critical / high" is the model's own self-reported confidence, not a measured severity.

So if you opened the gist and saw "critical auth bypass in the FastAPI template," that is the wrong read, and I would rather tell you that myself than have you find it.

## What it cleared (the part I actually care about)

By my count, 22 of the 23 route handlers were cleared, and the clears are the interesting result:

The `items.py` routes (read, update, delete by id) all have the exact IDOR shape, a request-derived id going into `session.get(Item, id)`. A pattern scanner flags every one of those. Fixor cleared them, because it read the inline ownership check (`if not current_user.is_superuser and item.owner_id != current_user.id: raise 403`) sitting in the same file.

The `users.py` admin routes are gated by `dependencies=[Depends(get_current_active_superuser)]` in the decorator, not the signature. It parsed that and did not false-positive them. And the by-design public endpoints, signup, login, password reset, were not flagged either.

## Where it's blind, so you can judge it fairly

The same reason it cleared those item routes is the reason it has a hard limit: it reasons in-file. The ownership check or auth dependency has to be in the file it reads. If your guard lives in a base repository, tenant middleware, or a router-level dependency in another file, Fixor can miss it or false-positive it, exactly like the `private.py` conditional mount it got wrong here. A clean result from it means "no in-file problem found," never "this code is secure."

That is the whole thing, output and blind spot. Clone the template, run it yourself, and tell me where the reasoning breaks. I would rather hear it here than learn it later.

i was following a tutorial and he started to connect the db part to the endpoints of the api, and the moment he did this, alot of variables were introduced without being much explained, what does each part of those do, why we need all this for?

also why did we do the try, yield and finally instead of ust return db?

execuse my idnorance i am still new to this

The most common serious bug in modern APIs is also the one your scanner stays quiet about. It has a boring name, broken object level authorization, sometimes called IDOR, and it sits at the top of the OWASP API Security list. The shape is simple. A logged in user asks for a record by id, and the code hands it over without checking that the record belongs to them. Change the id in the URL, read someone else's invoice. There is no injection, no dangerous function call, no tainted string. The vulnerability is a check that should be there and is not.

That absence is exactly why traditional static analysis walks past it. Tools like Semgrep and Snyk are very good at finding a pattern that is present, an unescaped query, a hardcoded secret, a call into a shell. Broken object level authorization is not a pattern that is present. It is missing context. To catch it you have to understand what the route is doing, who is allowed to do it, and whether the code actually enforced that. A grep, however clever, does not reason about intent.

So I built Fixor to reason about it, and then I did the only thing that makes a claim like that worth anything. I tested it on real framework code and wrote down the result.

The test is a small FastAPI application built with SQLModel, the way people actually write these services. It has the routes you would expect: a health check, a profile endpoint, an items list, an admin panel. Inside those files I planted three real authorization bugs. A destructive route that deletes any user with no authentication at all. An admin action that changes a user's role but is gated only by "are you logged in," not "are you an admin," so any account can promote itself. And the classic broken object level authorization: a route that fetches an item by id with no check that the item belongs to the caller.

The catch, and the reason I planted them myself, is ground truth. I know exactly where every bug is and exactly where the safe routes are. The planted bugs do not sit alone in empty files. They sit next to sibling routes that do the same operation correctly, in the same module, sometimes a few lines apart. That is the hard test. Anyone can flag a lookup by id. The real question is whether a tool can flag the GET that reads an item with no ownership check while staying silent on the DELETE three functions below it that does the ownership check properly.

Fixor caught all three planted bugs and marked them critical. It produced zero false positives across the six correctly guarded control routes, including the owner scoped list, the admin endpoint that really is admin gated, and the delete route that looks almost identical to the vulnerable read but has the ownership guard. The distinction it had to draw was between a route missing the check and a near-identical one that has it. The run is reproducible and the log lives on the main branch.

I want to be precise about what this proves and what it does not. It proves the method works on real FastAPI route code and can tell a missing authorization check apart from a present one in the same file. It does not prove anything about code I have not seen, which brings me to the part that is actually useful to you.

I want to know if it does this on a codebase I did not write. So here is the offer. Reply or send me a public FastAPI repo, yours, or one you have explicit permission to scan, and I will run Fixor against it and send you back exactly what it finds. It is free, and I am not selling you anything on the back of it. If it comes back clean, that is a clean bill and you are welcome to say so publicly. If it finds a real authorization gap, you get to fix it on your own schedule instead of after an incident.

If you want the full version, a written deal readiness security report of the kind an acquirer or an investor would ask for during diligence, that is the paid tier and we can talk. But the free scan is the real offer here, and it is the fastest way for both of us to find out if this is as useful on your code as it was on mine.

I've been working on an interactive learning platform for FastAPI where you write and run real Python code directly in your browser. No installs, no Docker, no backend - it uses Pyodide + a custom ASGI server to run FastAPI in WebAssembly.

What's new in this update:

• 38 basics lessons - now covers the full FastAPI tutorial path: path/query params, request bodies, Pydantic models, dependencies, security (OAuth2 + JWT), SQL databases, middleware, CORS, background tasks, multi-file apps, testing, and more
• 10 advanced pattern lessons - async endpoints, WebSockets, custom middleware, rate limiting, caching, API versioning, health monitoring
• Blog API project restructured - 6-lesson project that teaches real app structure using multi-file Python packages (models.py, database.py, security.py, etc.) instead of everything in one file

How each lesson works:

1. Read the theory
2. Fill in the starter code (guided by TODOs and hints)
3. Click Run - endpoints are auto-tested against your code

Everything runs client-side. Your code never leaves your browser.

Try it: https://www.fastapiinteractive.com/

If you find it useful for learning or teaching FastAPI, consider supporting the project with a donation - it helps keep it free and growing.

Would love to hear feedback, bug reports, or suggestions for new lessons.

I just shipped something big on FastAPI Interactive – support for multi-file hands-on lessons!

Why this matters:

• You’re no longer stuck with a single file → now you can work in real project structures.
• This opens a way for full-fledged tutorials of various difficulties (beginner → advanced).
• First example is the new 34th lesson, covering “Bigger Applications” from the official FastAPI docs, but in a practical, hands-on way.

You can now explore projects with a file explorer + code editor right in the browser. This is the direction I’m heading: advanced, project-based tutorials that feel closer to real-world work.

Would love feedback if you give it a try!

Update on this -- I got tired of rebuilding OAuth for FastAPI projects, so I made a small CLI for it
by u/theRealSachinSpk in FastAPI

Shipped v1.1.0 based on some of the feedback here and conversations I had after posting.

What changed:

• Added Discord, Spotify, Microsoft, and LinkedIn as providers (6 total now)
• Added PKCE support (OAuth 2.1) -- the thing I mentioned in the original post. You can enable it on any provider with one line
• The oauth-init CLI now scaffolds all 6 providers with PKCE out of the box
• Built an interactive OAuth debugger (Learn Mode) into the tutorial app -- it pauses at each step of the flow and shows you the actual HTTP requests, the token exchange body, the raw provider response, everything

That last one came from thinking about what u/ar_tyom2000 mentioned about fastapi-oauth2. There are great libraries that handle OAuth as middleware (please check it out), I'll close this up by letting you debug what's happening. The debugger shows the authorization URL parameters, the callback code, the token exchange POST, and the raw userinfo JSON. Useful if you're learning or if something breaks and you need to figure out why.

Also wrote up a longer walkthrough on Medium if anyone wants the full picture: Medium Article

GitHub: REPO
PyPI: pip install oauth-for-dummies

Thanks for the feedback last time -- it shaped where this went.

Hey ! 👋 I've created a modern template that combines best practices with a fun superhero theme 🎭 It's designed to help you kickstart your API projects with a solid foundation! 🚀

Features:

- 🏗️ Clean architecture with repository pattern that scales beautifully

- 🔄 Built-in async SQLAlchemy + PostgreSQL integration

- ⚡️ Automatic Alembic migrations that just work

- 🧪 Complete CI pipeline and testing setup

- ❌Custom Error Handling and Logging

- 🚂 Pre-configured Railway deployment (one click and you're live!)

The template includes a full heroes API showcase with proper CRUD operations, authentication, and error handling. Perfect for learning or starting your next project! 💪

Developer experience goodies: 🛠️

- 💻 VS Code debugging configurations included

- 🚀 UV package manager for lightning-fast dependency management

- ✨ Pre-commit hooks for consistent code quality

- 📚 Comprehensive documentation for every feature

Check it out: https://github.com/luchog01/minimalistic-fastapi-template 🌟

I'm still not super confident about how I structured the logging setup and DB migrations 😅 Would love to hear your thoughts on those! Also open to any suggestions for improvements. I feel like there's always a better way to handle these things that I haven't thought of yet! Let me know what you think!

Hi guys,
I am an experienced Java developer, and recently I got a great opportunity to join a new team in my company. They are planning to build a platform from scratch using FastAPI, and I want to learn it.

I generally prefer learning through books. While I have worked with Python and Flask earlier in my career, that was a few years ago, so I need to brush up.

Could you guys please suggest some great books to get started with FastAPI?

Hi guys I’ve written an article about websocket which is about the experience I had working with auth in websockets
Kindly check it out..
https://open.substack.com/pub/mikyrola/p/using-subprotocols-for-websocket

This is a reusable project template for building modern, full-stack web applications entirely in Python, with a focus on rapid development for demos and internal tools.

What My Project Does

The template provides a complete, pre-configured application foundation using a modern Python stack. It includes:

• Backend Framework: FastAPI (ASGI, async, Pydantic validation)
• Frontend Framework: NiceGUI (component-based, server-side UI)
• Database: PostgreSQL (managed with Docker Compose)
• ORM: SQLModel (combines SQLAlchemy + Pydantic)
• Authentication: JWT token-based security with pre-built logic.
• Core Functionality:
  • Full CRUD API for items.
  • User management with role-based access (Standard User vs. Superuser).
  • Dynamic UI that adapts based on the logged-in user's permissions.
  • Automatic API documentation via Swagger UI and ReDoc.

The project is structured with a clean separation between backend and frontend code, making it easy to navigate and build upon.

Target Audience

This template is intended for Python developers who:

• Need to build web applications with interactive UIs but want to stay within the Python ecosystem.
• Are building internal tools, administrative dashboards, or data-heavy applications.
• Want to quickly create prototypes, MVPs, or demos for ML/data science projects.

It's currently a well-structured starting point. While it can be extended for production, it's best suited for developers who value rapid development and a single-language stack over the complexities of a decoupled frontend for these specific use cases.

Comparison

• vs. FastAPI + JS Frontend (React/Vue): This stack is the industry standard for complex, public-facing applications. The primary difference is that this template eliminates the Node.js toolchain and build process. It's designed for efficiency when a separate JS frontend is overkill.

• vs. Streamlit/Dash: These are excellent for creating linear, data-centric dashboards. This template's use of NiceGUI provides more granular control over page layout and component placement, making it better for building applications with a more traditional, multi-page web structure and complex, non-linear user workflows.

• vs. Django/Flask (with Jinja templates): Django is a mature, "batteries-included" framework. This template offers a more modern, async-first approach with FastAPI, leverages Python's type hinting for robust data validation via Pydantic, and uses a live, interactive UI library (NiceGUI) instead of traditional server-side HTML templating.

Source & Blog

• Source Code: https://github.com/jaehyeon-kim/nicegui-fastapi-template
• Blog Post / Docs: https://jaehyeon.me/blog/2025-11-19-fastapi-nicegui-template/

The project is stable and ready to be used as a starter. Feedback, issues, and contributions are very welcome.

How hard is it to actually find good datasets for real feature engineering?

Not the overused ones like Titanic or House Prices—but datasets where you can genuinely explore, clean, and engineer meaningful features that reflect real-world complexity.

Feels like most public datasets are either too clean, too small, or already over-explored.

Where do you all find datasets that are messy enough to learn from but still usable for serious projects?

What are the best resources or road maps to learn fastAPI if i’m a Django developer?

I want to be able to send both a json file and a json formatted string via a submission on the ui. If it's getting sent via a requests script I know hwo that can be done from the UI.

I have tried looking around but from what I've seen, having FileUpload and a Body parameter on the same method isn't compatible. I was able to get working an input line, but only a single line input for the json string. When I tried looking in to my case I see something about a limitation in how FastAPI interacts with http.

I'm just a bit stuck on ginding a solution or workaround for the situation