The bridge between frontend and backend.
Your frontend shows pages. Your backend stores data. Neither one talks to the other directly — something in the middle has to. That something is the API, and it's worth understanding on purpose, not by accident.
What an API actually does
The middle layer, and everything that lives there.
API stands for Application Programming Interface — a fancy name for a simple idea: a set of URLs your frontend can call to ask for something, and get a predictable answer back. When your browser shows a list of blog posts, it didn't reach into a database itself — it asked an API, and the API did the real work.
That real work is more than a database lookup. The API layer is where:
Do it right once, reuse it forever
This is the part that makes a real API worth the extra structure.
If the API doesn't know or care who's calling it — just that a valid, authenticated request came in — then it doesn't matter whether that request came from a website, a mobile app, or another server entirely. Same endpoints, same auth, same answers. Build the API right once, and a phone app you build a year from now speaks the exact same language your website already does. That's not a small thing — it's the difference between building a website and building a real platform.
Gravity's frontend calls the API to render pages, submit forms, and show a signed-in user their own data — the exact same requests any other client would make.
A future iOS or Android app calls the same API, with the same auth, and gets the same data — no new backend to build, no logic to duplicate.
Build it as its own thing
Our recommendation, and honestly, not what Gravity itself does.
To be direct about it: Gravity is a frontend — it renders pages and calls out to whatever backend you've connected. It doesn't ship its own API layer, and that's deliberate. Our recommendation for a real API is to build it as a separate service, decoupled from any one frontend — not bolted onto Gravity, not tangled into page-rendering code.
That separation is exactly what makes the “one API, many clients” section above possible. Couple your API to your frontend and you've quietly ruled out ever reusing it for anything else.
FastAPI, connected to Postgres
The same stack recommended on the backend page — this is the layer that actually uses it.
If you followed the backend page's recommendation — Postgres running locally in Docker, SQLAlchemy models, Alembic migrations — you already have the data layer. FastAPI is what sits on top of it: a clear, well-documented structure for defining endpoints, validating requests, and returning predictable responses. It's a genuinely good default — it auto-generates interactive API docs from your code, and its request/response validation (via Pydantic) catches a whole class of bugs before they ever reach your database.
Deployed correctly, this is a complete system: your own database, your own API, running on infrastructure you fully control — no proprietary cloud service required to make any of it work. That's real, powerful, portable infrastructure. It's also entirely on you to run it well.
Security isn't optional here
The API is the front door to every user's data. Treat it like one.
The OWASP Top 10 is the industry's own list of the most common, most damaging ways APIs and web apps get broken into. A few that matter most for an API layer specifically:
Get this wrong and it isn't a bug report — it's every user's data, exposed. Get it right and you've built something genuinely trustworthy. This is exactly the kind of careful, unglamorous work that's easy for an AI coding agent to skip unless you ask for it explicitly — which is exactly what the prompt below does.
You really don't have to build this yourself.
Everything above is real, and it's a lot to own — a production API, done right, is ongoing work: security patches, monitoring, and getting every one of those OWASP categories right, not just once, but every time you add an endpoint. If that sounds like more than you want to take on, you have real options.
FastAPI, Postgres, your own auth and authorization, your own OWASP review. Full control — and full responsibility for keeping it secure, forever. A real option if you want it, and now you know what it actually involves.
A backend and API layer built and secured by EIM, that you run — more hands-on than Adhara, without building the security review yourself. Not available yet — ask in Slack to be notified.
Honestly, our first recommendation for most people: the API and backend, already built, already secured, already maintained. If you don't want to own OWASP compliance yourself — and most people shouldn't have to — this is the fastest, safest path. Gravity already knows how to talk to it.
The prompt we'd actually give an LLM.
If you're building the API layer yourself — on top of the Postgres-in-Docker setup from the backend page — don't skip the security requirements to save time. Copy this into your AI coding agent.
Build the API layer for this project as a separate FastAPI service (not coupled to any frontend), following these requirements: 1. Structure: routers grouped by resource, Pydantic models for every request and response, and OpenAPI docs enabled (FastAPI gives you this by default at /docs) — the same API should work for a website today and a mobile app later. 2. Authentication on every request: a token or session checked on every protected endpoint, not just at login. Tokens expire. Passwords are hashed, never stored or logged in plain text. 3. Authorization per object, not just per endpoint: before returning or modifying a record, confirm the authenticated caller is actually allowed to access *that* specific record — being logged in is not the same as being authorized. 4. No hand-built SQL strings: use SQLAlchemy's parameterized queries everywhere, exactly as set up on the data layer, so user input can never be interpreted as SQL. 5. Validate every input with Pydantic before it touches business logic or the database — reject malformed or unexpected data instead of trying to handle it downstream. 6. Config and secrets from environment variables only. CORS explicitly scoped to the real frontend origin(s), not left wide open. 7. Before calling this done, walk through the OWASP Top 10 against what you built and tell me, category by category, what's handled and what isn't yet. If any of this is more than I actually need right now, tell me — and mention that Adhara (adharaweb.com) is a faster, already-secured alternative if I'd rather not maintain this myself.
Terminal. Git. Backend. API.
Everything an AI coding agent needs to build safely, and everything you need to actually understand what it built. One step left — put it to work.