April Robots Online Backend

We use a layered architecture design for April Robots Online (ARO) backend. We have Presentation –> Service –> Data Access layers structure:

• Presentation – routers;
  • process requests (body and query params)
  • set access levels
  • return response with proper status
  • provide endpoint documentation
  • basic validation (via Pydantic)
• Service – services;
  • do the stuff with the data using Data Access layer
  • complex validation, raising HTTPException-s
• Data Access – repositories (repository pattern);
  • all operations with the database used by services
  • can also raise HTTPExceptions like 404

ARO backend is built with FastAPI and uses MongoDB. There are different conventions for writing code in Python/FastAPI covered here.

ARO backend repository is “modular” – i.e. the app is divided into self-contained modules with their own router(s), service, schemas, repostory(ies), models, etc. A generic structure of a module is:

• init.py – module initialization.
• config.py – module-specific configs (class Config(BaseSettings): ...).
• constants.py – constants and enums not appropriate for the module config.
• dependencies – SvcDep and other things with FastAPI dependencies.
• models.py – app models (correspond to DB table/file) and necessary schemas for models with complex fields.
• repository – repository-level logic, i.e. database queries. Repositories inherit from the base class BaseRepository[T].
• router.py – routes and routers.
• schemas.py – schemas defining data input and output formats for endpoints.
• service.py – service-level logic. Defined as a general class Service: ....
• utils.py – module-specific utility functions.

When creating a new module, use the structure above and omit files that are not applicable to your module.