DEV Community: fastapier (Freelance Backend)

Building a Production-Aware AI Backend with FastAPI

fastapier (Freelance Backend) — Wed, 25 Mar 2026 17:13:45 +0000

Most AI backend examples stop at one thing:

send a prompt, get a response.

That is fine for demos, but real systems usually need more than that.

Once you try to use AI inside an actual product, a few practical questions show up immediately:

How much does each request cost?
How long does each response take?
Can we stream output instead of waiting for a full response?
Can we reduce hallucinations by grounding responses in known data?
Can we log usage for billing and analytics?

I wanted to build something closer to that reality.

So instead of making another thin OpenAI wrapper, I built a FastAPI-based AI backend with:

synchronous responses
streaming responses
usage logging
token-based cost estimation
response time monitoring
lightweight context-based answering
Docker reproducibility

The result is a backend that feels much closer to something you could actually extend into an internal AI tool or SaaS feature.

Why I Built It This Way

A lot of AI tutorials focus on model output.

I wanted to focus on backend behavior.

That means:

responses should be explainable
system behavior should be predictable
logs should support observability
the backend should be structured for extension, not just for demo screenshots

In other words, I was less interested in “Can this call OpenAI?”
and more interested in “Can this behave like a real backend feature?”

Tech Stack

Python 3.11
FastAPI
SQLAlchemy 2.0
Alembic
OpenAI API
SQLite
Docker

What the Backend Does

The project currently includes:

POST /ai/test for standard AI responses
POST /ai/stream for streaming output
POST /ai/upload for adding text-based context data
POST /seed for inserting sample context
GET /ai/logs for inspecting stored usage logs

It also stores request-level data such as:

prompt
response
total tokens
estimated cost
response time
endpoint name
user id
timestamp

That logging layer turned out to be one of the most important parts of the project.

Because once you can see how AI is being used, the backend starts becoming operational instead of experimental.

Lightweight RAG-Style Answering

One of the goals was to reduce hallucinated answers.

Instead of letting the model answer freely from its general knowledge, I added a lightweight retrieval flow:

search relevant records from the database
inject the retrieved content into the prompt
instruct the model to answer only from that context

This is not a full vector database setup.
It is intentionally lightweight.

The retrieval logic uses:

simple keyword-based matching
basic query pre-processing for Japanese text
AND search first
OR fallback if needed
safe fallback responses when no context is found

So the project is better described as a lightweight RAG-style backend rather than a full enterprise retrieval system.

That was deliberate.

I wanted something small enough to understand, but structured enough to feel useful.

Why Streaming Matters

Streaming changes the feel of an AI product a lot.

Without streaming, the user waits for the full answer.
With streaming, the user gets feedback immediately.

That makes the backend feel much closer to a real assistant feature.

So I added /ai/stream and then made sure streaming requests were not treated like second-class citizens.

I wanted them logged too.

That meant tracking:

total tokens
estimated cost
response time
endpoint name

This was important because a lot of examples show streaming output, but do not show how to observe or measure it properly.

In practice, that observability layer is what makes the feature maintainable.

Cost Tracking and Latency Monitoring

For regular /ai/test responses, token usage was straightforward to capture.

For streaming, it required a bit more work.

I refactored the provider layer so the streaming flow could still capture usage data at the end, then calculate an estimated cost and store it together with the final response log.

That gave me a much more useful log structure.

Instead of only storing “prompt” and “response,” I could now see:

how many tokens were used
how much the request approximately cost
how long the request took
which endpoint generated it

That is a much stronger foundation for:

cost visibility
future billing models
usage analytics
performance monitoring

One Practical Issue I Hit

Alembic autogeneration tried to include unrelated schema changes while I was extending the logging table.

It detected the new columns I wanted:

estimated_cost
response_time_ms
endpoint

But it also tried to remove an unrelated documents table.

That was a good reminder that migration generation is helpful, but not magical.

I manually cleaned the migration so it only included the actual intended schema change.

That was one of those small but very real backend moments:
not “how do I make the feature work?”
but “how do I make the change safe?”

Current Logging Model

The request log now stores:

prompt
response
total_tokens
estimated_cost
response_time_ms
endpoint
user_id
created_at

That makes the backend feel much more production-aware than a simple AI demo.

What This Project Is Really About

The most important thing I learned is that AI backend work is not just model integration.

It is also about:

structure
safety
logging
reproducibility
monitoring
extension paths

Calling an API is easy.

Building something that behaves predictably when it grows is the harder part.

That is what I wanted this project to reflect.

What I Would Add Next

The next natural steps would be:

JWT authentication
token quota control
admin-facing usage analytics
Stripe integration
richer retrieval strategies
vector-based search when the use case really needs it

But even in its current form, the backend already demonstrates something important:

AI features become much more valuable when they are treated as backend systems, not just model calls.

Repository

GitHub: fastapi-ai-core

The repository includes Docker setup, logging examples, and a lightweight context-retrieval flow.

If you are building AI-enabled backend systems with FastAPI, I think this kind of structure is worth caring about early.

Because once usage grows, observability stops being a nice-to-have.
It becomes part of the product itself.

Building a Production-Ready AI Backend with FastAPI and OpenAI

fastapier (Freelance Backend) — Wed, 18 Mar 2026 22:16:54 +0000

Introduction

Most developers today use ChatGPT.

But in real-world systems, the real value is not using AI —

it's integrating AI into a reliable backend system.

Connecting to the OpenAI API is easy.

However, in production, you quickly run into real problems:

Slow responses causing user drop-off
Uncontrolled token usage and unpredictable costs
AI logic becoming a black box

This project focuses on solving those issues by building a

manageable, production-oriented AI backend using FastAPI.

What I Built

A simple but practical AI backend API:

FastAPI-based endpoint
OpenAI API integration
Clean JSON response design
Dockerized for environment consistency

Example endpoint:

POST /ai/test

Request:

{
  "prompt": "Explain FastAPI and AI integration"
}

Response:

{
  "result": "..."
}

Tech Stack

FastAPI
OpenAI API
SQLAlchemy (for logging design)
Docker

Key Implementation Points

1. Secure API Key Management

The OpenAI API key is handled via environment variables:

OPENAI_API_KEY=your_api_key

2. Fully Asynchronous Design

The backend is built using async/await to prevent blocking during AI response time.

This ensures the system remains responsive under concurrent requests.

3. Clean Response Structure

The API returns a simple JSON format, making it easy to integrate with:

Frontend applications
External services
Automation pipelines

4. Dockerized Environment

To eliminate environment inconsistencies:

docker build -t fastapi-ai .
docker run -p 8000:8000 fastapi-ai

Challenges

Handling environment variables inside Docker
Debugging API key issues
Differences between local and container execution

These are common pitfalls when moving from “it works locally” to production.

Design Philosophy

The goal is not just to "use AI", but to:

build AI as a controllable backend component

Key principles:

API-first design (modular and reusable)
Async processing (scalable)
Dockerized deployment (reproducible)
Logging-ready structure (cost & monitoring)

🛠 Roadmap (Toward SaaS)

Streaming responses (real-time UX)
Usage tracking (token-level logging per user)
JWT authentication integration
RAG-based knowledge integration

Conclusion

This setup is intentionally simple, but designed with production in mind.

It demonstrates how to:

Treat AI as part of your backend architecture
Control cost and performance
Build systems that can scale beyond prototypes

Moving from "using AI" to "integrating AI into real systems"

is a key step for backend engineers today.

🔗 Source Code

GitHub Repository:

https://github.com/hiro-kuroe/fastapi-ai-core

This repository is part of a series:

Authentication (JWT)
Payment Integration (Stripe)
AI Backend (this project)

Together, they form a production-ready backend foundation.

If you're building an AI-powered product and facing issues like:

API rate limits (429 errors)
unstable batch processing
usage tracking / token logging
OpenAI integration problems

I specialize in fixing and stabilizing FastAPI backends.

Feel free to check the repository or contact me directly.

📩 fastapienne@gmail.com

Building a Stripe Subscription Backend with FastAPI

fastapier (Freelance Backend) — Sun, 08 Mar 2026 13:28:20 +0000

Many Stripe tutorials stop at Checkout integration.

But real SaaS products require more than that.

A production subscription backend must handle:

subscription state management
webhook processing
access control
expiration logic
duplicate webhook protection

To explore this architecture, I built a small project:

FastAPI Revenue Core

Repository
https://github.com/hiro-kuroe/fastapi-revenue-core

This project demonstrates a minimal SaaS-style subscription backend using FastAPI and Stripe.

What This Project Implements

The backend includes the essential components required for subscription-based services.

JWT authentication
Stripe Checkout integration
Stripe Webhook processing
Subscription state engine
Automatic expiration logic
Docker deployment

The goal was to build a reusable revenue backend foundation that could power subscription products.

Architecture

The system is intentionally simple.

Client
   ↓
FastAPI API
   ↓
Stripe Checkout
   ↓
Stripe Webhook
   ↓
Subscription Status Engine

Stripe handles payment processing.

The FastAPI backend manages user access state.

This separation keeps payment logic clean and allows the API to control feature access.

Subscription State Engine

Each user has a subscription status stored in the database.

FREE
PRO
EXPIRED

Stripe webhook events update these states.

Example transitions:

subscription.created
FREE → PRO

subscription.deleted
PRO → EXPIRED

This state engine ensures the backend always knows whether a user has access to paid features.

Handling Subscription Expiration

Stripe provides the timestamp:

current_period_end

Example extraction:

period_end_ts = items[0]["current_period_end"]

This timestamp is stored in the database and used to determine whether the user's subscription has expired.

Whenever a protected API endpoint is accessed, the backend checks the expiration timestamp.

If the subscription is no longer valid:

PRO → EXPIRED

This guarantees that access control stays correct even if webhook timing changes.

Webhook Design

Stripe webhooks are essential for subscription systems.

The backend processes events such as:

customer.subscription.created
customer.subscription.deleted

The webhook updates user subscription status and expiration timestamps.

Because Stripe may resend webhook events, the backend design supports idempotent event handling to avoid duplicate processing.

Running the Project

Clone the repository:

git clone https://github.com/hiro-kuroe/fastapi-revenue-core
cd fastapi-revenue-core

Install dependencies:

pip install -r requirements.txt

Run the server:

uvicorn app.main:app --reload

Swagger documentation will be available at:

http://localhost:8000/docs

Running with Docker

The project also supports Docker deployment.

Build the image:

docker build -t fastapi-revenue-core .

Run the container:

docker run -p 8000:8000 fastapi-revenue-core

What This Project Demonstrates

This repository demonstrates a minimal backend architecture for subscription-based services.

It combines:

FastAPI
Stripe subscription billing
webhook processing
access control logic
Docker deployment

This type of backend is commonly used for:

SaaS products
paid API services
membership platforms
subscription-based applications

Repository

Full source code:

https://github.com/hiro-kuroe/fastapi-revenue-core

Final Thoughts

Stripe integration tutorials often focus only on payment processing.

But real subscription systems require:

backend state management
expiration handling
webhook reliability
API access control

This project demonstrates how these pieces can be combined into a simple but practical backend architecture.

If you're building a FastAPI SaaS backend or working with Stripe subscriptions, feel free to check out the repository.　　

Incident Intake

If you are experiencing issues with Stripe payments or subscription systems,

you can submit a diagnosis request through the intake form below.

Typical problems include:

Stripe Webhook not triggering
Subscription status not updating
Checkout succeeds but user access does not change
Cancelled subscriptions still retaining access

Submit an incident report here:

https://github.com/hiro-kuroe/fastapi-revenue-core/blob/main/Intake-en.md

401 Is Not the Bug. It’s the Signal.

fastapier (Freelance Backend) — Sat, 21 Feb 2026 12:56:21 +0000

You fixed the endpoint.
You rewrote the dependency.
You regenerated the token.

Still 401.

Here’s the uncomfortable truth:

401 is not the root cause.
It’s the signal that something deeper is inconsistent.

In FastAPI authentication flows, 401 usually appears when:

The SECRET_KEY used to sign the token is not the one used to verify it

Docker injects a different .env than your local environment

Multiple instances are running with inconsistent configurations

The token algorithm (HS256 / RS256) does not match

Clock drift invalidates the token timestamp

The controller is fine.
The route is fine.
The dependency is fine.

The layers are not aligned.

Authentication is not just code.
It’s configuration.
It’s environment.
It’s deployment consistency.

When /token works but /me returns 401,
your application is telling you:

“The layers don’t agree.”

Stop fixing the endpoint.

Start mapping the layers:

Environment variables

Key consistency

Container configuration

Token structure

Deployment topology

401 is not your enemy.

It’s the signal that your architecture is out of sync.

Treat it as a bug, and you’ll chase symptoms.
Treat it as a signal, and you’ll repair the architecture.

I built a reproducible playground for this type of incident:
https://github.com/hiro-kuroe/fastapi-auth-crud-docker

Your API Is Replying… But Authentication Is Already Broken (FastAPI JWT)

fastapier (Freelance Backend) — Fri, 20 Feb 2026 15:00:41 +0000

🔥 Opening

/token works.

You receive a JWT.

Swagger shows “Authorized”.

Everything looks correct.

And then —

/me returns 401.

You check the endpoint.

You rewrite the dependency.

You add print logs.

Nothing changes.

The API is replying.

But authentication is already broken.

🧩 Why This Happens

Most of the time, the endpoint is not the problem.

The token is valid.

The route is correct.

The dependency is wired properly.

The failure happens one layer deeper.

Common structural causes:

Different SECRET_KEY between environments
Docker using a different .env file
Multiple instances running with inconsistent configs
Clock drift causing token validation issues
Algorithm mismatch (HS256 vs RS256)

Nothing is “wrong” in the controller.

The structure is inconsistent.

🧠 The Real Problem

When authentication fails, most developers try to fix code.

They debug the endpoint.

They rewrite dependencies.

They patch logic.

But authentication is not just code.

It is configuration.

It is environment.

It is instance consistency.

It is key management.

If those layers are misaligned,

no endpoint fix will solve it.

🛠 My Approach

I specialize in structural FastAPI/JWT authentication incidents.

I don’t start by modifying code.

I map the layers first:

Environment variables
Key consistency
Instance configuration
Token structure
Deployment differences

Playground (reproducible setup): 👉 https://github.com/hiro-kuroe/fastapi-auth-crud-docker

Only after the structure is clarified, modification makes sense.

🏁 Closing

If your API keeps replying

but authentication keeps failing,

you may be debugging the wrong layer.

I built a reproducible playground for this exact type of incident:

👉 https://github.com/hiro-kuroe/fastapi-auth-crud-docker

Analysis-first. Structure before patching.

This is not a patch guide.
It’s a structural diagnosis.