Skip to main content

System Overview

Orbit Classroom is composed of six runtime concerns that work together to deliver the full product experience.

Runtime Concerns​

1. Frontend​

SvelteKit + TypeScript + Tailwind CSS

The browser application delivers a three-pane shell:

  • Left pane — Navigation rail and workspace tree (classes, modules, lessons)
  • Center pane — Primary workspace (lesson viewer, assignment editor, grades, settings)
  • Right pane — AI assistant panel with chat interface and citations

The v1 application targets desktop browsers only.

2. Application API​

FastAPI + Python

The backend handles all product logic:

  • REST endpoints for CRUD operations on academic objects (classes, modules, lessons, assignments, materials)
  • Server-Sent Events (SSE) for streaming chat responses to the browser
  • Authorization enforcement on every request
  • Chat orchestration and context assembly
  • Grading operations
  • Admin settings management

3. Background Worker​

Python worker + Redis + RQ queue

Long-running operations are offloaded from the API to a background worker:

  • File text extraction from uploaded materials
  • Chunking and embedding generation
  • Vector index updates
  • AI-generated material summaries

4. Database​

PostgreSQL 16 + pgvector

A single PostgreSQL instance serves as the primary store for all product data:

  • All relational entities (users, classes, content, grades, chat history)
  • Vector embeddings stored in pgvector columns for RAG retrieval
  • No separate vector database required

5. Object Storage​

Supabase Storage or S3-compatible

Raw binary files are stored separately from the database:

  • Teacher-uploaded material files (PDFs, Word documents, etc.)
  • Student assignment submissions

6. Model Providers​

OpenAI API, OpenRouter, Anthropic, Ollama

External or local model endpoints provide:

  • Chat inference (one active provider/model at a time)
  • Embedding generation for RAG indexing and retrieval

Request Flow​

Browser → [SvelteKit Frontend] → [FastAPI Backend] → [PostgreSQL + pgvector]
                                       ↓                      ↑
                                  [Redis Queue] → [Worker] ───┘
                                       ↓
                               [Model Providers]
                               [Object Storage]

Synchronous path — The browser sends requests to the SvelteKit frontend, which calls the FastAPI backend. The backend reads and writes PostgreSQL for most operations and streams SSE responses back to the browser for chat.

Asynchronous path — When a material is uploaded, the API enqueues a job to Redis. The worker picks it up, extracts and chunks the file, calls the configured embedding model, and writes the resulting vectors back to PostgreSQL.

Storage path — Uploaded files are written directly to Object Storage. The worker reads from Object Storage during ingestion.