The FastAPI Template Is the One My Non-Frontend Friends Actually Use

Most scaffolders are Node-only, and that's fine — Node is the default runtime for web tooling. But my non-frontend friends (the data people, the ML people, the infra people) don't want a Node project when they want a backend. They want Python.

The FastAPI template in scaffoldx-cli is the one I hand them. It's a small, complete FastAPI service — async, Pydantic-validated, with OpenAPI docs and a pytest setup — generated by the same npx command as the Node templates. One tool, two ecosystems, and the Python side is where the unexpected adoption happened.

This post is about that template, and about why a "Node CLI that also does Python" is a better pattern than a separate Python scaffolder.

What the template ships

The generated service is a minimal-but-complete FastAPI app:

• An async app — async def handlers from the start, because "make it async later" is a refactor you don't want to do after the handlers are written. The template's position: if you're building a modern service, it's async from the first file.
• A Pydantic model — a request/response schema that's the single source of truth for validation. The handler takes a typed model, not a raw Request you have to parse by hand. Type validation is the framework's job, not yours.
• A health endpoint — /health that returns {"status": "ok"}, so the service has a liveness check from the first deploy. Boring, and exactly the right kind of boring for a starter.
• OpenAPI docs for free — FastAPI generates /docs and /openapi.json automatically. The template doesn't add anything here; it just doesn't get in the way of the framework's best feature.
• A pytest setup — a test_health.py that hits the health endpoint, so the first test run is green and the "how do I add a test" question has an answer in the repo.

The whole service is a handful of files: main.py, a models.py, a test, a requirements.txt. It runs with uvicorn main:app and the docs are at /docs before you've written a line of your own logic.

Why it lives in a Node CLI

The obvious question: why is a Python template in an npx command? Isn't that weird?

It's not, for three reasons:

1. The user's entry point is the CLI, not the language. My non-frontend friends are already in a terminal running npx for their Node projects. Adding a Python backend to the same command means one tool to remember, one muscle memory, one place to look when they want to start a project of any kind. The npx entry point is a convenience, not a statement about what the generated code is.

2. The scaffolder is language-agnostic by design. scaffoldx-cli is a file writer — it writes template files to disk. The templates are content, not code the scaffolder executes. A Python template is just a set of Python files; the scaffolder doesn't care what language they're in. That's the whole reason a single CLI can serve multiple ecosystems: the scaffolder's job (write files, git init, first commit) is orthogonal to the template's language.

3. A separate Python scaffolder is a separate maintenance burden. A second tool means a second package to publish, a second version to track, a second "where did I put that" for the user. Folding the Python templates into the existing CLI keeps the surface area at one tool. The user doesn't need to know or care that the scaffolder is a Node script; they need npx scaffoldx-cli to give them a FastAPI app, and it does.

What the non-frontend friends actually do with it

The adoption pattern is consistent:

• The data person uses it as the API layer for a data pipeline — the Pydantic models become the contract between the pipeline and the consumer, and the OpenAPI docs are the integration spec.
• The ML person uses it as the serving wrapper for a model — the async handler loads the model, the Pydantic model validates the inference request, and /docs is the endpoint reference the front-end team uses.
• The infra person uses it as a reference implementation — "here's what a minimal, correct, tested FastAPI service looks like" — and copies the structure rather than the code.

In all three cases, the value isn't "it saved me 30 minutes of typing." It's that the template encodes the shape of a correct FastAPI service (async, validated, documented, tested) in a way that's easier to copy than to derive, and the npx entry point means they can get that shape without leaving the tool they already use.

The honest limit

The template is a starter, not a framework. It doesn't add ORM integration, auth, or deployment config — those are decisions your specific service will make. Its job is to get you from "I want a FastAPI service" to "I have a running, validated, documented, tested service I can extend" in the minimum number of steps. Everything after that is your architecture, on a base that's already correct in the places that are easy to get wrong.

npx scaffoldx-cli
# choose: FastAPI Backend

One tool, two ecosystems, and the Python side is the one that surprised me. Sometimes the most useful feature is the one in the language you didn't expect to need it in.

npx scaffoldx-cli

---

More Tools

Tool	What it does	Command
scaffoldx-cli	Production-ready project templates in seconds	npx scaffoldx-cli
dotguard	Scan .env files for exposed secrets	npx @wuchunjie/dotguard
gitpulse	Git repo analytics in your terminal	npx @wuchunjie/gitpulse
snippetx	Terminal code snippet manager	npx @wuchunjie/snippetx

If these save you time, consider buying me a coffee. All tools are MIT-licensed, zero-dependency, and run fully offline.