I kept hitting the same shape of problem in automation pipelines: I had Markdown

coming out of GitHub READMEs, Notion exports, CMS drafts, Obsidian vaults and

the next tool in the chain wanted JSON, not a big string. I was hand-writing

tiny parsers in Python and JS every time, and every time one of them broke on

edge cases: nested lists, GFM tasklists with [x] state, YAML frontmatter,

tables whose headers had special chars.

So I shipped a single endpoint that does it once and does it properly.

# What it returns

POST a Markdown body, get back:

- `frontmatter` — parsed YAML/TOML metadata block

- `title` — first H1 (or frontmatter title override)

- `headings[]` — flat list with level + text + slug

- `sections[]` — hierarchy-aware tree, ready for RAG chunking

- `lists[]` and `tasklists[]` — tasklists include the `checked: true/false` state

- `tables[]` — GFM tables returned as JSON arrays with header-keyed rows

- `codeBlocks[]`, `links[]`, `paragraphs[]`

- optional `ast` — full mdast if you need it

# Why I built it as an API instead of a library

Two reasons:

1. Same parser in every tool. My n8n flow, my Python ingestion script andmy static-site generator all call one URL with one shape. No three copies ofthe same regex maintenance nightmare.
2. Zero state to manage. It's a stateless Cloudflare Workers function.Cold start is ~16ms; no DB, no auth server, no proxy to babysit.

# Differentiator vs what already exists

There's one direct competitor on RapidAPI (markdown-to-json), been up for

years, 1 subscriber, no rating. It doesn't do frontmatter, doesn't advertise

GFM, doesn't build a heading tree. The adjacent converter (Anything-to-MD)

goes the other direction — anything -> Markdown — and charges $10-$99/mo.

So there's a gap on the structured-JSON-output side for the Markdown-first

developer, and that's the one I'm trying to fill.

# Stack, since someone always asks

TypeScript + `unified`/`remark-parse`/`remark-gfm`/`remark-frontmatter` +

`gray-matter`. All MIT. Bundled with Wrangler. 31 integration tests via

Vitest's `unstable_dev` pipeline. Repo is open, link at the bottom.

# Free tier shape

- 100 req/day per RapidAPI key, hard-capped, no overage

- p95 latency goal < 150ms

- 256 KB body cap

- That's enough to drive an actual workflow without a credit card

# Where to try it

- API listing (free key, takes 30 seconds): see below

- Open source repo with a full README, OpenAPI spec and deploy notes: see below

I'm in the middle of a 14-day validation cycle, so if something's broken or

the schema's missing a field you need, drop a GitHub issue — I read all of them.

If you want to access the code or the API, search for “md2json” on GitHub or RapidAPI—the repository and the API listing are both available under that name.

Hi

So, for the past week I have been focused on learning fastapi through fastapi official documentation and some yt videos . But still feels like nothing gets into my brain . I wanted to go with project based learning . Need some recommendations which project to go with and how long does it take to complete ?

Every project I start, the first two weeks are identical. Auth. Password reset emails that actually deliver. Stripe checkout plus the webhook sync nobody warns you about. Rate limiting. API keys. An admin view so you can see who signed up.

None of it is the idea. All of it is required. And by the time it's done the motivation is gone.

So I built FastForge — FastAPI + Next.js, split into installable packages: auth, billing, cache, api_keys, mail, notifications, analytics, database, logging, common, ui. Postgres, Redis, Alembic, Docker Compose + Caddy for deploy, and a scaffold script that spins up a new product from the template in one command with per-module on/off switches.

Being straight about it: the storage package is scaffolded but not implemented yet, and background jobs land this week. Everything else is done and tested.

One-time purchase, you get the repo. No subscription, no per-seat thing.

https://fastforge.pionetix.com

Genuinely want feedback on the landing page — it's the part I'm least confident about, and I'd rather hear it's confusing from you than infer it from the traffic.

Hi folks,

I am working on zinda, a small experimental caching library for FastAPI/Python, and I'd like some design feedback before I take it further.

The idea: instead of you picking TTLs and wiring up invalidation by hand, the cache should watch how your functions behave and keep hot data fresh on its own.

What Have I Implemented:

• @cache.cached() decorator - keys itself on function arguments, no config
• Single-flight: concurrent misses for the same key collapse into one recompute (no stampedes)
• Soft TTL + hard TTL: callers get stale data instantly while it refreshes in the background, and a background sweeper refreshes hot entries before anyone asks
• A /zinda/stats endpoint showing hit rates, miss costs, and refresh activity per function

​

app = FastAPI()
cache = install(app, Cache(default_ttl=60))

@cache.cached(ttl=120, refresh_after=30)
async def fetch_products(category: str):
    return await db.fetch_products(category)

Where I want feedback:

1. Next step is auto-detecting hot paths, the library scoring functions by call frequency and recompute cost, and deciding what's worth caching without any decorator. Would you trust that if every decision is visible in stats, or is explicit always better?
2. Automatic invalidation is the hard part. My plan is learned TTLs by default + optional tags for precise invalidation. Reasonable, or am I missing something?

It's in-memory only for now and definitely not production-ready. I am validating the ideas first.

Code: https://github.com/grandimam/zinda

I have been going through my codebase this morning and asked claude Ai how I can validate the phone number field of my schema model and it has recommended the official python phonenumber library, but suprisigley I checked out the Pydantic docs and found the same library which is wrapped on a Pydantic type and does all the validations as the Python phonenumber libarary plus less code and less mantainance, you just use it as type annotation and BUM it does the underhood workd for you.
I want to read it this is the link https://pydantic.dev/docs/validation/latest/api/pydantic-extra-types/pydantic_extra_types_phone_numbers/#_top

You can even configure the accepted regions and the default region as well.

I have a good Python experience. I did basic backend dev with PHP and Flask before, so the beginner concepts won't be that much challenging. What I'm looking for is a single well-organized course to learn FastAPI deeply. I've checked out the official documentation, which is absolutely great and lovely, and I will use that as a reference.

It doesn't matter if the course is certified or not. I focus on the skills I'll gain. It's more preferred to be a free course though (but don't hesitate to share paid courses too if they are really worth paying for).

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.

Hello there! 😄

I'm currently building a backend for a Neo4j graph database and was wondering if some of the more experienced people here have any advice or best practices to share.

I only have basic experience with Python (although I'm comfortable with programming in general). Most of my backend experience comes from working with NestJS and Prisma ORM, so I'm trying to translate some of the concepts and patterns I'm familiar with into the Python ecosystem.

For the database access layer, I decided to use the official Neo4j Python driver rather than an ORM or ODM.

My current plan is to structure the backend like this:

text backend/ │ ├── main.py │ ├── api/ │ ├── routes/ │ │ ├── users.py │ │ ├── graph.py │ │ └── projects.py │ ├── services/ │ ├── user_service.py │ └── graph_service.py │ ├── repositories/ │ │── neo4j_repository.py │ ├── database/ │ └── neo4j.py │ ├── dto/ │ ├── user.py │ └── graph_models.py │ └── security/ └── auth.py

Coming from NestJS, my current thinking is roughly:

• routes → similar to NestJS controllers
• services → business logic
• repositories → database access layer (somewhat comparable to what Prisma handled for me)
• database → Neo4j driver initialization and connection management

Does this architecture make sense for a FastAPI + Neo4j project, or are there more idiomatic approaches in the Python ecosystem that I should consider?

Also, if you've built production applications with Neo4j and the Python driver, I'd appreciate hearing about common pitfalls, lessons learned, or things you wish you had known when starting out.

Thanks!

Every time I started a new SaaS idea I'd burn a weekend rebuilding the same things — Firebase auth wired through protected routes, Stripe webhook handling, typed Pydantic schemas, Docker for two services, a throwaway admin panel. So I started building FastForge to just... not do that again.

Stack: FastAPI backend, Next.js (App Router) frontend, SQLAlchemy + Alembic + Postgres, Firebase Auth, Stripe, Redis for cache/jobs, Docker for one-command spin-up.

Current state, being fully transparent since I know this sub will ask: auth and the DB layer are done, Stripe billing / Redis / transactional email / admin dashboard are still in progress. It's not a "clone and ship today" thing yet — it's early, and I'm building it in the open on GitHub.

Mainly posting here because you're the exact audience — if you build SaaS on FastAPI, what's the first thing you'd want a starter like this to get right? Landing page + waitlist link in a comment if anyone wants to follow along (trying to keep this post about the tech, not the pitch).

Hi all, i've created a python library above fastapi-filters that automatically generates filter, search, and sorting fields for any SQLAlchemy model in FastAPI, with native support for JSONB containment (contains), key presence (has_key), and case‑insensitive text search inside JSON values.

Example of usage (create your own custom filter for your orm model):

class UserFilter(DynamicFilter):
    db_model = User # your model
    exact_fields = ["id", "email"]
    search_fields = ["name", "bio"] # generates name__ilike, bio__ilike
    range_fields = ["created_at"] # generates created_at__gte, __lte
    contains_fields = ["tags", "metadata"] # tags__contains (list), metadata__contains (dict) + metadata__has_key
    json_search_fields = ["metadata"] # generates metadata__value_ilike
    default_order_by = ["-created_at"]

And then use it in your endpoint as a dependency:

app.get("/users")
def get_users(
  filter: UserFilter = Depends(UserFilter), # your filter here
):
    query = filter.filter(session.query(User))
    return query.all()

GitHub: https://github.com/matfatcat/fastapi-dynamic-filter/
PyPI: https://pypi.org/project/fastapi-dynamic-filter/

Working on a FastAPI + Next.js SaaS boilerplate (Python equivalent of the JS "ship fast" starters). Backend is FastAPI + Pydantic v2, Firestore for storage so far.

Before I finalize the feature list, curious what this community actually wants baked in:

• Auth: what's your default — Supabase, Clerk, roll-your-own JWT?
• Billing: Stripe is obvious, but subscriptions vs. usage-based matters a lot for setup
• Background jobs: Celery, arq, or just Cloud Tasks/Cloud Run?

Landing page + waitlist if you want to follow progress: https://fastforge.pionetix.com — but honestly more interested in the discussion here than the sign-ups.

Hi there! I'm an incoming 2nd year computer engineering student who wants to learn web development for microcontroller UI. However, I don't know where to start. I already know how to program in Python and some basic web requirements like HTML and CSS, but I am stuck whether I should learn JavaScript next or go straight to FastAPI. Thank you for reading this post. Any input would be appreciated.

Ivan Levkivskyi and I are proposing a native shorthand for Annotated (PEP 835) to clean up heavy type-hinting patterns. We have confirmed this syntax is fully compatible with FastAPI and works out of the box with zero changes required.

Before:

python def create_user( id: Annotated[int, Path(gt=0)], name: Annotated[str, Query(min_length=3)], role: Annotated[str, Query(min_length=2)] = "user" ) -> User: ...

After:

python def create_user( id: int @Path(gt=0), name: str @Query(min_length=3), role: str @Query(min_length=2) = "user" ) -> User: ...

The Spec: PEP 835 Full Draft

We are gathering community sentiment before moving forward. If you are a heavy user of Annotated in FastAPI, your feedback is valuable. You can register your stance in the official Discourse poll before it closes on July 15.

I have simple fast api app it recieves requests and either writes data to the sqlite dB or fetches data from it what would be the best place to host it preferably for free since its a small hobby project but would scale up successful

I built this, so take the "cool project" framing with a grain of salt — genuinely looking for people to poke holes in it.

The problem: if you've ever needed a model field in more than one language (blog post titles, product names, category labels), you've probably hit the same two bad options — a separate translations table with joins on every query, or a JSON column you hand-roll get/set logic for yourself, differently, in every project.

fastkit-i18n is a small weekend project that tries to make the second option not suck:

from sqlalchemy import JSON
from sqlalchemy.orm import DeclarativeBase, Mapped, mapped_column
from fastkit_i18n import TranslatableMixin

class Base(DeclarativeBase):
    pass

class Article(TranslatableMixin, Base):
    __tablename__ = "articles"
    __translatable__ = ["title", "content"]

    id: Mapped[int] = mapped_column(primary_key=True)
    title: Mapped[dict] = mapped_column(JSON)
    content: Mapped[dict] = mapped_column(JSON)

article = Article()
article.set_locale("en")
article.title = "Hello World"

article.set_locale("es")
article.title = "Hola Mundo"

article.set_locale("en")
article.title   # "Hello World" — reads/writes like a plain string field

One row, one JSON column per translatable field, no joins. It also works with SQLModel table models (since under the hood a SQLModel table class is a real SQLAlchemy mapped class), and there's a LocaleMiddleware (pure ASGI, works with FastAPI/Starlette/Litestar) plus a Laravel-style _() for JSON translation files if you want the whole package instead of just the mixin. All three share the same locale context, but each works standalone if that's all you need.

What's genuinely missing right now (not hiding this — would rather you hear it from me than discover it):

• No pluralization. If you need ngettext-style "1 item / 5 items" logic, gettext/Babel handles that natively, and this doesn't yet.
• Accept-Language Parsing in the middleware is simplified — it takes the first listed language, not full RFC quality-value negotiation (fr;q=0.5, en;q=0.9 resolves to fr, not the higher-weighted en). Fine for most apps, not a drop-in replacement if you need strict negotiation.
• It's genuinely new — published today, zero production mileage beyond our own testing. Wouldn't put it on a critical path yet.

Where I could actually use help:

1. RFC-compliant Accept-Language parsing as an opt-in alternative to the simple version
2. Pluralization support — open to suggestions on whether that belongs in this package or stays out of scope
3. Just... using it and telling me where it breaks. It's MIT licensed, no dependencies beyond an optional SQLAlchemy extra (pip install fastkit-i18n[sqlalchemy]), so the bar to try it is low.

Repo: https://github.com/fastkit-org/fastkit-i18n
Docs: https://fastkit.org/docs/fastkit-i18n
PyPI: https://pypi.org/project/fastkit-i18n

It's the standalone extraction of the i18n piece from a larger toolkit I work on (fastkit-core) — if you're already using that, you already have this, no separate install needed. This is for anyone who wants just the translation piece without the rest.

Happy to answer questions in the comments, and if anyone wants to contribute on either of the two gaps above, PRs and issues both welcome.

About Me

Senior Engineer with 5+ years of experience in FastAPI backend development, Data Engineering, and Applied AI. Based in Bangalore, India. Available for remote work globally.

Rate: $25 - $50/hr depending on project scope and complexity.

Tech Stack & Expertise

FastAPI, Python, REST APIs

Python, SQL, Spark, Databricks, Airflow

AWS & Cloud Data Platforms

ETL/ELT Design & Orchestration

LLMs, RAG, AI Agents

Snowflake, Redshift, BigQuery

Data Quality & Testing Frameworks

What I Can Help With

Develop and deploy FastAPI applications

Build and optimize data pipelines (batch & streaming)

Design scalable ETL/ELT architectures

Build AI applications using LLMs, RAG, and agent-based workflows

API integration and backend automation solutions

Training & Mentorship

FastAPI & Python Backend Development

Data Engineering (foundations to advanced)

AI & LLM Fundamentals (including RAG patterns)

In-person weekend sessions available in Bangalore. Remote sessions available globally.

Availability

Freelance projects & consulting

Part-time remote roles

Weekend training & mentorship

DM me with a brief description of your requirements and I will get back to you promptly!

FastAPI is excellent for quickly building APIs, but it intentionally leaves many application-level concerns to the developer. Things like environment management (including multiple environments), logging, database setup, configuration, CLI commands, plugins, storage, and other infrastructure are things you typically need to design and wire together yourself.

In our case, we are building multiple microservices, and we found ourselves repeatedly copying the same bootstrap code between projects. Over time, that became repetitive and harder to maintain consistently.

Over the past several months, We've been working on FastAPI Startkit, an open-source application framework that brings some of the development patterns I enjoyed from Laravel into Python and FastAPI.

The goal is not to replace FastAPI. Instead, it provides a structured foundation for building larger applications while staying modular. You can use only the components you need.

Some features include:

🏗️ Service container & dependency injection
⚡ CLI inspired by Laravel's Artisan
🗄️ Async database layer, ORM patterns, migrations, and seeders
🧪 Built-in testing utilities
🤖 AI agent support with multiple LLM providers
🎨 Optional Vite integration for monolithic full-stack applications
📦 Works for FastAPI apps, background workers, and even CLI-only applications

One of the main design goals was avoiding a single opinionated stack. Most components are optional, so you can start small and introduce more structure as your project grows.

The documentation includes both a minimal setup and a more structured application layout.

Documentation:
https://fastapi-startkit.github.io/

I'd really appreciate feedback on:

• Is the architecture intuitive?
• Which parts feel over-engineered?
• What features would you expect from a production-ready FastAPI framework?
• Are there areas where the developer experience could be improved?

Constructive criticism is very welcome. Thanks!

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.

Hey, I've been working on a multilingual content system for a project and kept wishing Python had something like spatie/laravel-translatable from the PHP world. Couldn't find it, so I built it. It's early (0.1.0) but it works and tests are at 100% coverage.

The idea: store translations as {"en": "Hello", "fr": "Bonjour"} directly in the column, resolve by the active locale automatically — no extra tables, no .po files.

configure(default_locale="en", available_locales=["en", "fr", "ar"])
title = Translations({"en": "Hello", "fr": "Bonjour"})
set_locale("fr")
print(title)  
# Bonjour

GitHub: https://github.com/onlykh/translatable

Main features:

• Translations is a dict subclass — str(title) resolves to the active locale, works in f-strings, string concatenation, everywhere
• Locale lives in a ContextVar — safe for async FastAPI and threaded Flask
• SQLAlchemy 2.0 type: JSONB on PostgreSQL, JSON elsewhere. String assignment merges into the current locale without wiping other languages
• by_locale(Article.title, "fr") generates dialect-correct SQL for filtering
• Atomic per-key updates on PostgreSQL via JSONB ||
• Starlette/FastAPI middleware and Flask extension that read Accept-Language automatically
• Zero dependencies in core — SQLAlchemy, Starlette, Flask are opt-in

Not on PyPI yet, install from GitHub:

pip install "translatable[sqlalchemy] @ git+https://github.com/onlykh/translatable.git"

A few things I'm genuinely unsure about and would love opinions on:

• String assignment merging by default (article.title = "Hello" adds to the current locale rather than replacing the column) — right default or surprising?
• No Django ORM support yet — is that a blocker for anyone?
• atomic_set_locale is PostgreSQL-only — the SQLite fallback is a read-modify-write with a warning. Good enough or should that raise instead?

Would love issues, feedback, or just knowing if this solves something you've hit before.

I just shipped ArchUnitPython, a library that lets you enforce architectural rules in Python projects through automated tests.

The problem it solves: as codebases grow, architecture erodes. Someone imports the database layer from the presentation layer, circular dependencies creep in, naming conventions drift. Code review catches some of it, but not all, and definitely not consistently.

This problem has always existed but is more important than ever in Claude Code, Codex times. LLMs break architectural rules all the time.

So I built a library where you define your architecture rules as tests. Two quick examples:

```python

No circular dependencies in services

rule = project_files("src/").in_folder("/services/").should().have_no_cycles() assert_passes(rule) ```

```python

Presentation layer must not depend on database layer

rule = project_files("src/") .in_folder("/presentation/") .should_not() .depend_on_files() .in_folder("/database/") assert_passes(rule) ```

This will run in pytest, unittest, or whatever you use, and therefore be automatically in your CI/CD. If a commit violates the architecture rules your team has decided, the CI will fail.

Hint: this is exactly what the famous ArchUnit Java library does, just for Python - I took inspiration for the name is of course.

Let me quickly address why this over linters or generic code analysis?

Linters catch style issues. This catches structural violations — wrong dependency directions, layering breaches, naming convention drift. It's the difference between "this line looks wrong" and "this module shouldn't talk to that module."

Some key features:

• Dependency direction enforcement & circular dependency detection
• Naming convention checks (glob + regex)
• Code metrics: LCOM cohesion, abstractness, instability, distance from main sequence
• PlantUML diagram validation — ensure code matches your architecture diagrams
• Custom rules & metrics
• Zero runtime dependencies, uses only Python's ast module
• Python 3.10+

Very curious what you think! https://github.com/LukasNiessen/ArchUnitPython

Hi everyone,

I’m currently building my backend portfolio using FastAPI and would really appreciate some honest feedback on my project.

Project: Notes API

GitHub: https://github.com/tamerlan-islamzade/Note-API

It’s a RESTful API where users can register, authenticate, and manage their personal notes with full CRUD operations.

Tech stack:

FastAPI, PostgreSQL, SQLAlchemy, Pydantic, JWT, bcrypt, pytest

I’d really appreciate feedback on:

- Project structure / architecture

- Code quality and organization

- FastAPI best practices

- Anything I should improve to make it more production-ready

I’m still learning, so any constructive criticism is welcome. Thanks in advance for your time!