rovierrhq/rovierr

1. Repository shape

- This is a TypeScript monorepo organized around a shared platform for university students.

- The main runtime surfaces are a Next.js web app, an Expo/React Native app, a Tauri desktop app, a Bun-based API server, and a realtime service.

2. Primary product split

- The product is not one app; it is a platform with multiple user-facing surfaces:

- Web for the full student platform experience

- Native for mobile access

- Desktop for a lighter companion client

- Docs for public documentation

- The web app appears to be the most complete client, with routes for academics, career, societies, profile, people, discussions, forms, expenses, roadmap, and login/signup flows.

3. Backend API boundary

- apps/server is the central application backend.

- It is structured as routers + services + lib helpers, with routers exposing domain APIs and services holding business logic.

- The server is built around oRPC contracts and uses shared schema definitions from packages/orpc-contracts.

4. Domain modules on the server

- The server is divided into feature routers/services such as:

- academics, calendar, campus feed, career, chat, connection, discussion

- expenses, forms, people, resume, roadmap

- society registration, society email, student organizations, tasks, university, user profile

- This indicates a modular monolith backend rather than a single generic API layer.

5. Shared contract layer

- packages/orpc-contracts is the API contract boundary shared between clients and server.

- It contains feature-specific schema modules for the same domains exposed by the backend.

- This package is the key coupling point that keeps frontend clients aligned with backend request/response shapes.

6. Persistence layer

- packages/db defines the database schema, likely via Drizzle based on the config and schema layout.

- The schema is split by domain: auth, users, institutions, programs, courses, academic achievements, campus feed, career, chat, discussion, expenses, forms, roadmap, society registration, tasks, and more.

- The server reads/writes through this layer; the schema package is the canonical data model boundary.

7. Data seeding and institutional data

- packages/db-seed is a separate ingestion/seeding pipeline.

- It contains structured datasets for institutions, terms, faculties, programs, and a large course catalog, plus scraper infrastructure for collecting institutional data.

- This package is an offline data-preparation subsystem, not part of request-time serving.

8. Realtime subsystem

- packages/realtime is a separate realtime service built around Centrifugo.

- The server has realtime helpers and routers, and the web app has a Centrifugo client integration plus presence hooks.

- Data flow here is distinct from the main API: the server publishes events, and clients subscribe for presence/chat/feed-like live updates.

9. Authentication and identity

- packages/auth provides shared auth clients for web and native, plus permissions logic.

- The web, native, and desktop apps each have their own auth-client wrappers, but they share the same auth package abstraction.

- This suggests authentication is centralized, while each client adapts it to its runtime.

10. Client applications

- apps/web is the main application frontend, built with Next.js and a large component tree for feature-specific screens and dialogs.

- apps/native uses Expo-style routing and platform-specific components for mobile.

- apps/desktop uses Vite + React + Tauri, giving a desktop shell over similar app logic.

- All clients depend on shared UI and contract packages rather than duplicating domain models.

11. Shared UI and cross-cutting libraries

- packages/ui provides reusable design-system components, form controls, rich text editor pieces, and visual blocks.

- packages/shared contains common domain-neutral utilities and types used across the platform.

- These packages form the presentation-layer foundation used by multiple apps.

12. External service integrations

- The server includes integrations for Google Calendar, S3, email delivery/templates, and a separate Python ID parser service with a TypeScript client wrapper.

- These are important boundary services because they extend core platform behavior beyond the database-backed modules.

13. Operational/deployment topology

- The README describes a split deployment model: Vercel for frontend hosting, Cloudflare for backend API, and Fly.io for microservices.

- Realtime is treated as its own infrastructure component.

- The repo also includes Docker, Docker Compose, GitHub Actions, and deployment docs, so the system is designed for containerized local development and multi-target deployment.

14. How data moves through the system

- Typical flow: UI in web/native/desktop → shared oRPC contracts → server routers → domain services → DB and external services.

- Realtime updates follow a separate path through the Centrifugo-based service.

- Seed data and institutional catalogs are loaded offline into the database, then consumed by runtime APIs and client screens.

15. Architecture summary for diagramming

- Think of this repo as a multi-client university platform with:

- a shared API contract layer

- a modular backend

- a shared persistence/schema layer

- a dedicated realtime subsystem

- and multiple presentation clients on web, mobile, and desktop.