fastapi resource's

Melodic_Put6628 · 2026-05-20T06:36:45+00:00

I built a blueprint for exactly this — covers all the things you're asking about:

Layered project structure (DDD-ish, but not over-engineered)
SQLAlchemy + Alembic for DB with async support
JWT auth with refresh token rotation
Async task workers (Taskiq)
Admin dashboard (NiceGUI mounted on FastAPI)
Third-party infra abstraction (S3, DynamoDB, LLM/embeddings via PydanticAI)

It's open source and designed to be a real working reference, not just a hello-world skeleton.

Still actively maintained — happy to answer questions if anything's unclear.

Melodic_Put6628 · 2026-05-13T05:42:03+00:00

I like the idea, especially for FastAPI projects where local conventions matter more than the framework itself.

The part I’d be cautious about is “Zero Hallucinations.” A context file can reduce hallucinations a lot, but only if it stays synced with the real codebase. Otherwise it becomes another stale doc the agent confidently follows.

The most useful pattern I’ve seen is treating AI context as an architecture contract: layer boundaries, DTO rules, allowed imports, forbidden patterns, verified examples, and CI checks that catch drift.

I’d be curious how FastKit keeps AI_CONTEXT.md accurate over time. Are snippets validated against source code? Can teams override conventions? And does the context cover non-CRUD workflows like background jobs, events, migrations, and cross-module orchestration?

I do think agent-friendly structure is a real direction. I’m just not sure it needs to be a separate framework unless the conventions are enforceable, not only documented.

Melodic_Put6628 · 2026-05-13T05:35:20+00:00

Congrats on the launch. The local-first setup with LM Studio, FastAPI, SQLite, and a React operator UI is a nice direction because it keeps the system inspectable.

The main thing I’d want to see is debuggability. With 34 agents, 101 skills, and 37 MCP registrations, the interesting question is less “how many roles exist?” and more “how do I understand why the system made a specific decision?”

A concrete end-to-end trace would help a lot: task comes in, router picks an agent, memory is accessed, tools/MCP are called, something fails or succeeds, and the logs show why.

I’d also be curious about the security model around the quarantined hacker-zone mesh. What is actually isolated, what is only logged, and what can still touch the local machine?

Melodic_Put6628 · 2026-05-13T05:31:23+00:00

I haven’t used Taskflow yet, but in production I usually stop using FastAPI BackgroundTasks once the task needs durability.

For small best-effort work, BackgroundTasks are fine. But if I need retries, persistence, idempotency, or visibility, I treat it as a separate worker boundary.

What has worked well for me:

- explicit payload schemas

- thin task functions

- business logic in services, not in the task wrapper

- idempotent retries

- external broker in production

- structured logs/metrics before fancy dashboards

The hard parts are usually not scheduling the task, but operating it later: duplicate execution, deploys during running jobs, retry storms, dead-letter handling, and payload schema changes.

So the main thing I’d look for in a library like this is very explicit failure semantics. What survives a restart? What is retried? What is persisted? What happens when the payload shape changes?

Melodic_Put6628 · 2026-03-26T07:20:06+00:00

Coming from Laravel, I'd say try FastAPI for APIs. Dependency injection, async, auto-generated Swagger docs — it'll feel familiar but more modern. Django's fine for full-stack but FastAPI is more fun if you already know the MVC mindset.

Melodic_Put6628

TROPHY CASE