357 lines
12 KiB
Plaintext
357 lines
12 KiB
Plaintext
You are a senior software architect and backend engineer.
|
|
|
|
Your task is to design and bootstrap a NEW backend system for a product called "FastCheck".
|
|
|
|
IMPORTANT CONTEXT:
|
|
- There is an EXISTING backend written in Node.js + TypeScript.
|
|
- That backend is already working in production and contains many more internal features than what clients need.
|
|
- The existing backend MUST NOT be rewritten or replaced directly.
|
|
- We want to build a NEW backend in Python using FastAPI.
|
|
- This new backend will run IN PARALLEL and will be exposed to CLIENTS as a clean SaaS/API product.
|
|
- The current ecosystem already uses MongoDB and RabbitMQ.
|
|
- The existing MongoDB database name is: duxiter
|
|
|
|
CRITICAL RULE:
|
|
The new FastAPI backend must reuse the CURRENT database and CURRENT collections for EVERYTHING.
|
|
|
|
That means:
|
|
- authentication must use the current db and current collections
|
|
- users must use the current db and current collections
|
|
- tenants/accounts/companies must use the current db and current collections
|
|
- checks must use the current db and current collections
|
|
- reports must use the current db and current collections
|
|
- permissions/roles must use the current db and current collections
|
|
- audit/log structures must reuse current collections if they already exist
|
|
- webhook-related persistence must reuse current structures if possible
|
|
- usage tracking must reuse current structures if possible
|
|
|
|
DO NOT create:
|
|
- a new database
|
|
- a parallel schema
|
|
- a new auth model
|
|
- a new user store
|
|
- a new tenant store
|
|
- new collections unless absolutely unavoidable and explicitly justified
|
|
|
|
The priority is compatibility with the existing `duxiter` persistence model.
|
|
|
|
==================================================
|
|
PRIMARY GOAL
|
|
==================================================
|
|
|
|
Design and generate a production-ready FastAPI backend that:
|
|
- runs in parallel to the current Node.js backend
|
|
- reuses the CURRENT MongoDB database and CURRENT collections for all data access
|
|
- exposes only the subset of features needed for clients
|
|
- stays compatible with the current schema and data model
|
|
- avoids any unnecessary persistence redesign
|
|
|
|
==================================================
|
|
MANDATORY FIRST STEP: ANALYZE EXISTING SCHEMA
|
|
==================================================
|
|
|
|
Before generating any implementation, you must FIRST inspect the current codebase and infer the real MongoDB usage.
|
|
|
|
You must analyze:
|
|
- MongoDB connection code
|
|
- model definitions
|
|
- repository classes
|
|
- service classes
|
|
- auth logic
|
|
- login flow
|
|
- token/session handling
|
|
- user collections
|
|
- tenant/account/company collections
|
|
- permissions/roles structures
|
|
- checks collections
|
|
- reports collections
|
|
- audit collections
|
|
- webhook collections or equivalent
|
|
- usage/metering collections or equivalent
|
|
- RabbitMQ integration points
|
|
|
|
Then provide an ANALYSIS SECTION with:
|
|
|
|
1. Existing database detected
|
|
2. Existing collections detected
|
|
3. Existing auth collections and fields
|
|
4. Existing user/account/company/tenant collections and fields
|
|
5. Existing permission model
|
|
6. Existing checks/reports collections and fields
|
|
7. Existing audit/log collections and fields
|
|
8. Existing webhook or callback-related persistence
|
|
9. Existing usage/metering-related persistence
|
|
10. Which existing collections will be reused by the FastAPI backend
|
|
11. Which existing fields must be preserved for compatibility
|
|
12. Which parts will be wrapped with adapters rather than redesigned
|
|
|
|
DO NOT proceed to implementation until this mapping is complete.
|
|
|
|
==================================================
|
|
STRICT COMPATIBILITY RULES
|
|
==================================================
|
|
|
|
1. Reuse the existing MongoDB database called `duxiter`
|
|
2. Reuse the existing collections for ALL business areas wherever they already exist
|
|
3. Preserve existing field naming whenever possible
|
|
4. Preserve existing document structures whenever possible
|
|
5. Preserve existing identifiers and references
|
|
6. Preserve current authentication compatibility
|
|
7. Preserve current tenant/account/company compatibility
|
|
8. Preserve current permission compatibility
|
|
9. Preserve current check/report compatibility
|
|
10. Do not create new collections unless absolutely unavoidable
|
|
|
|
If a new collection is truly unavoidable:
|
|
- explain exactly why
|
|
- explain why no existing collection can be reused
|
|
- keep it minimal
|
|
- do not continue silently
|
|
|
|
==================================================
|
|
ARCHITECTURAL PRINCIPLES
|
|
==================================================
|
|
|
|
1. Parallel backend strategy
|
|
- New FastAPI backend = CLIENT PRODUCT BACKEND
|
|
- Existing Node.js backend = INTERNAL / LEGACY BACKEND
|
|
- Both run in parallel
|
|
|
|
2. Reuse-first strategy
|
|
- The FastAPI backend must adapt itself to the CURRENT persistence model
|
|
- Do not force the data layer to adapt to a new idealized design
|
|
- Compatibility is more important than architectural purity
|
|
|
|
3. Productization
|
|
- The FastAPI backend should expose only the client-facing subset of functionality
|
|
- It should be stable, documented, secure, and multi-tenant
|
|
- But its persistence must remain aligned to the current system
|
|
|
|
==================================================
|
|
TECH STACK
|
|
==================================================
|
|
|
|
Use:
|
|
- FastAPI
|
|
- Pydantic v2
|
|
- MongoDB (existing `duxiter` database)
|
|
- RabbitMQ
|
|
- Redis only if absolutely optional and isolated
|
|
- Python typing throughout
|
|
|
|
Important constraints:
|
|
- Do NOT use PostgreSQL
|
|
- Do NOT use SQLAlchemy
|
|
- Do NOT use Docker
|
|
- Do NOT generate a new persistence architecture
|
|
- Do NOT generate greenfield Mongo models disconnected from the existing collections
|
|
|
|
==================================================
|
|
AUTHENTICATION AND AUTHORIZATION
|
|
==================================================
|
|
|
|
The new backend must use the CURRENT authentication and authorization data model already present in the codebase.
|
|
|
|
You must inspect:
|
|
- how users are stored
|
|
- how passwords are stored
|
|
- how tokens are generated or validated
|
|
- how sessions or JWTs are currently handled
|
|
- how roles/permissions are attached
|
|
- how tenant/account/company membership is resolved
|
|
|
|
Then:
|
|
- reuse the same collections
|
|
- reuse the same fields
|
|
- preserve compatibility with existing users
|
|
- preserve compatibility with current access control logic where possible
|
|
|
|
Do NOT invent:
|
|
- a new auth collection
|
|
- a new users collection
|
|
- a new tenants collection
|
|
- a parallel RBAC model
|
|
|
|
If API keys do not already exist, do not casually invent a new storage model unless necessary and justified.
|
|
|
|
==================================================
|
|
BUSINESS SCOPE
|
|
==================================================
|
|
|
|
The new FastAPI backend is a CLIENT-FACING PRODUCT API for FastCheck.
|
|
|
|
It should expose only essential client-facing APIs such as:
|
|
|
|
- login
|
|
- token refresh
|
|
- list checks
|
|
- create check
|
|
- get check result
|
|
- get report
|
|
- get usage
|
|
- manage webhooks if current schema supports it or can be adapted cleanly
|
|
|
|
But all of this must use current database structures and current collections.
|
|
|
|
==================================================
|
|
LEGACY INTEGRATION REQUIREMENTS
|
|
==================================================
|
|
|
|
The existing Node.js backend must be treated as the current internal source of truth for business behavior.
|
|
|
|
The new FastAPI backend must:
|
|
- reuse the same MongoDB database and collections
|
|
- optionally call legacy services through an integration layer
|
|
- avoid reimplementing every internal behavior immediately
|
|
|
|
Create an integration layer such as:
|
|
services/
|
|
legacy_service.py
|
|
|
|
This layer should:
|
|
- abstract interactions with the legacy backend
|
|
- support gradual migration
|
|
- avoid tight coupling in the API layer
|
|
|
|
==================================================
|
|
RABBITMQ / ASYNC REQUIREMENTS
|
|
==================================================
|
|
|
|
RabbitMQ is already part of the ecosystem and must be reused.
|
|
|
|
Use it for asynchronous check processing.
|
|
|
|
Suggested flow:
|
|
- client submits a check
|
|
- FastAPI writes using the existing MongoDB collections/patterns
|
|
- FastAPI publishes a message to RabbitMQ
|
|
- worker consumes the message
|
|
- worker processes the check via legacy integration or compatible logic
|
|
- worker writes results back using the current schema
|
|
- optional webhook/callback behavior should reuse existing persistence patterns if available
|
|
|
|
Do not invent a separate async persistence model.
|
|
|
|
==================================================
|
|
PROJECT STRUCTURE
|
|
==================================================
|
|
|
|
Generate a production-grade FastAPI structure such as:
|
|
|
|
app/
|
|
main.py
|
|
core/
|
|
config.py
|
|
security.py
|
|
mongodb.py
|
|
logging.py
|
|
api/
|
|
dependencies.py
|
|
v1/
|
|
routers/
|
|
auth.py
|
|
checks.py
|
|
reports.py
|
|
usage.py
|
|
webhooks.py
|
|
services/
|
|
auth_service.py
|
|
check_service.py
|
|
report_service.py
|
|
usage_service.py
|
|
webhook_service.py
|
|
legacy_service.py
|
|
rabbitmq_service.py
|
|
audit_service.py
|
|
repositories/
|
|
middleware/
|
|
tenant_context.py
|
|
request_logging.py
|
|
schemas/
|
|
workers/
|
|
check_worker.py
|
|
utils/
|
|
tests/
|
|
|
|
IMPORTANT:
|
|
repositories, services, schemas, and models must be based on the EXISTING `duxiter` collections, not on invented collections.
|
|
|
|
==================================================
|
|
OUTPUT REQUIRED
|
|
==================================================
|
|
|
|
Generate the project as a real implementation starter.
|
|
|
|
Required output:
|
|
|
|
1. Analysis of the existing MongoDB schema usage from the current codebase
|
|
2. Explicit collection mapping table:
|
|
- collection name
|
|
- purpose
|
|
- reused as-is / reused via adapter / not used
|
|
3. Full proposed project structure
|
|
4. Implementation of key files:
|
|
- app/main.py
|
|
- app/core/config.py
|
|
- app/core/mongodb.py
|
|
- app/core/security.py
|
|
- app/api/v1/routers/auth.py
|
|
- app/api/v1/routers/checks.py
|
|
- app/middleware/tenant_context.py
|
|
- app/services/auth_service.py
|
|
- app/services/check_service.py
|
|
- app/services/legacy_service.py
|
|
- app/services/rabbitmq_service.py
|
|
- app/workers/check_worker.py
|
|
5. Pydantic schemas aligned with the current collection structures
|
|
6. Auth flow aligned with current persistence
|
|
7. RabbitMQ async publish/consume example
|
|
8. Audit handling aligned with existing persistence
|
|
9. README with local run instructions without Docker
|
|
10. .env.example
|
|
11. requirements.txt
|
|
|
|
==================================================
|
|
IMPLEMENTATION PREFERENCES
|
|
==================================================
|
|
|
|
- Keep code modular and production-minded
|
|
- Prefer pragmatic compatibility over clean-slate redesign
|
|
- Use strong typing
|
|
- Use structured logging
|
|
- Add centralized exception handling
|
|
- Add a GET /health endpoint
|
|
- Preserve naming alignment with the current codebase
|
|
- Add TODO markers where legacy behavior must be completed
|
|
- Avoid abstract theory; generate concrete starter code
|
|
|
|
==================================================
|
|
VERY IMPORTANT CONSTRAINTS
|
|
==================================================
|
|
|
|
DO NOT:
|
|
- create a new MongoDB database
|
|
- create new collections unless absolutely unavoidable
|
|
- create a parallel auth system
|
|
- create a parallel user model
|
|
- create a parallel tenant/account model
|
|
- redesign persistence from scratch
|
|
- introduce SQL or PostgreSQL
|
|
- introduce Docker
|
|
- mirror every internal feature unnecessarily
|
|
|
|
DO:
|
|
- build a new FastAPI backend in parallel
|
|
- reuse the existing `duxiter` database for everything
|
|
- reuse the existing collections for everything wherever possible
|
|
- adapt FastAPI code to the current persistence model
|
|
- keep legacy integration abstract and replaceable
|
|
- expose only the subset of features needed by clients
|
|
|
|
==================================================
|
|
FINAL INSTRUCTION
|
|
==================================================
|
|
|
|
Before generating code, explicitly confirm through analysis that the new FastAPI backend will use the EXISTING `duxiter` database and EXISTING collections for ALL areas of the system.
|
|
|
|
Only after that, generate implementation code. |