pwachara/life-outreach-church

1. This repo is a split SvelteKit + PocketBase application. The SvelteKit side provides the user-facing site and the custom admin dashboard, while PocketBase provides the backend API, authentication, database, file storage, and built-in admin/runtime.

2. The public-facing SvelteKit routes are centered around church content: a homepage, a videos listing page, and event detail pages under src/routes/events/[id]. These pages are likely read-only consumers of PocketBase collections.

3. The admin area is separated by route structure: src/routes/(admin)/login for sign-in, and src/routes/dashboard for the authenticated management UI. The dashboard contains CRUD flows for banners, events, and videos, plus a change-password screen.

4. Data access is centralized through src/lib/pocketbase.js, which is the main client boundary between the SvelteKit app and the backend. Route +page.js files likely load records from PocketBase and pass them into Svelte components for rendering and editing.

5. PocketBase is the system of record. The presence of pocketbase.exe, pb_data/data.db, and pb_data/logs.db indicates an embedded PocketBase runtime with SQLite storage. Uploaded media is persisted under pb_data/storage, so file assets are part of the backend state, not just the frontend build.

6. The data model is evolved through PocketBase migrations in pb_migrations. The migration names show three primary content collections: banners, events, and videos. That means the app’s architecture is content-management oriented rather than generic CRUD.

7. pb_public contains generated PocketBase web assets, including the built admin UI and immutable bundles. This is runtime/static output, not application source, and it supports the PocketBase server’s built-in browser interface.

8. The frontend is a standard SvelteKit app using Vite, Tailwind, and PostCSS. src/app.html, src/app.css, src/routes, and src/lib are the main source boundaries; src/fonts and static/robots.txt indicate additional asset and SEO handling.

9. Authentication and authorization are handled at the application boundary, not by a separate service. The login route and dashboard layout suggest the app gates admin pages in SvelteKit, while PocketBase likely supplies the auth session and user identity used by the admin UI.

10. Deployment is containerized and production-oriented. Dockerfile, fly.toml, and .github/workflows/fly-deploy.yml show the app is designed to run on Fly.io, probably as a single deployable unit that serves both the SvelteKit frontend and the PocketBase backend with persistent data volume attached.

11. From an architecture-diagram perspective, the key request flow is: browser → SvelteKit route/component → PocketBase client → PocketBase API/database/storage. For admin content updates, the same path writes back to PocketBase, which persists records in SQLite and files in the storage directory.

12. The important boundaries are: public site vs authenticated dashboard, frontend code vs PocketBase backend, and source code vs generated/runtime artifacts (pb_public, pb_data). Those boundaries are the main ones to show if you are drawing the system diagram.