samratpro/fastadmin

1. FastAdmin is split into two deployable runtimes: a Python backend in api/ and a standalone Next.js admin UI in admin/. The repository also includes documentation, deployment helpers, and a public-app template, but those are support materials rather than the core runtime.

2. The backend is a FastAPI application entrypointed from api/main.py. It is organized Django-style into feature apps under api/apps/*, and those apps are auto-discovered at startup rather than wired together through a monolithic central module.

3. Each backend feature app owns its own boundary: models.py for domain data and routers.py for HTTP endpoints. The current included domains are auth, blog, seo, settings, backup, and admin, which makes the backend modular and easy to extend with new app folders.

4. Shared backend infrastructure lives in api/core/ and api/common/. This includes configuration, database setup, security, dependency injection, registry logic for admin model registration, and the lightweight ORM layer used by application models.

5. The data layer is SQLite-first. The repository includes Alembic for migrations, but the README makes clear that new tables can be created automatically while schema changes to existing tables still require explicit migration or SQL steps. This matters for diagramming because the system is not relying on a fully managed ORM migration workflow alone.

6. Authentication is backend-driven and cookie-based. The API exposes login, logout, refresh, password reset, email verification, and me endpoints, and it stores JWTs in httpOnly cookies (accessToken and refreshToken). Swagger/OpenAPI docs are also available, but they are protected for superuser access.

7. The admin UI is a separate Next.js app using the App Router. Its main runtime surfaces are login and the dashboard area, with pages for models, individual model views, SEO, backup, and settings. This is the internal staff interface, not the public site.

8. The admin frontend talks to the API through a dedicated client layer in admin/src/lib/api.ts and uses client-side auth state in admin/src/store/authStore.ts. Route protection is handled in the UI via ProtectedRoute, so the browser experience depends on the backend session cookies plus frontend route guards.

9. The dashboard UI is model-centric. Components such as ActionBar, DualListBox, EditorField, FiltersSidebar, and Fieldset indicate that the admin is designed around CRUD, filtering, ordering, and content editing rather than generic page composition. There is also a small Next.js upload route in admin/src/app/api/upload/route.ts, which suggests some file handling happens inside the admin app boundary before or alongside API calls.

10. Extensibility is a first-class architectural concern. Backend models are meant to be registered into the admin system with @register_admin, and the api/apps/admin/ plus api/core/registry.py pieces are the mechanism that turns backend models into admin-manageable resources.

11. Operationally, the repo is container-ready and CI-backed. There are Dockerfiles for both runtimes, a root docker-compose.yml, and a GitHub Actions workflow for validation. Node version files and npm config exist at the root and in admin/, showing that the frontend is treated as its own build target.

12. The tutorials/ folder is part of the architecture story: it documents how to add apps, manage auth, run migrations, configure email, back up data, integrate SEO, and connect a separate public frontend. A reference public Next.js auth app lives under tutorials/templates/public-auth-nextjs, reinforcing the intended shape: public app and admin app both consume the same backend API, but remain separate frontends.