Kalli
Server

Server Overview

Vue d'ensemble du serveur

Le serveur (apps/server) est l'API backend de l'application web de back-office. Il gère l'authentification, la base PostgreSQL, le pipeline d'ingestion des documents, la curation des chunks et des paires Q&A, les tags et rôles, et déclenche la régénération des index.

Le chat ne passe pas par le serveur : il est servi par rag-agent, qui lit les index et la base directement.

Stack

TechnologieUsage
BunRuntime TypeScript
HonoServeur HTTP, CORS, logs
oRPC (@orpc/server)Procédures RPC typées, exposées sous /rpc/*
Drizzle ORM + pgAccès PostgreSQL, migrations
Better AuthSessions, OAuth Microsoft, plugin admin
ZodValidation des entrées des procédures

Responsabilités

  • Authentification et sessions (Better Auth). Contrôle d'accès des procédures : protectedProcedure et adminProcedure.
  • Ingestion : upload, envoi à document-processor en job asynchrone, insertion des chunks et des tags.
  • Curation : catégories, tags, contenu et historique des chunks et des paires Q&A.
  • Rôles et tags applicatifs, qui déterminent le contenu de chaque index.
  • Régénération des index : appel de l'API d'index de rag-agent (INDEX_API_URL).
  • Santé : GET /, GET /health et GET /ready répondent OK.
  • Traductions : GET /api/i18n.
  • Création des rôles applicatifs admin et user au démarrage.

Routes HTTP

RouteRôle
POST/GET /api/auth/**Better Auth
/rpc/*Procédures oRPC
GET /api/i18nTraductions frontend (variable I18N_JSON, sinon fichier i18n.json)
GET /, GET /health, GET /readySondes de santé

Routeurs oRPC

RouteurFichierPérimètre
authRouterrouters/auth.tsUtilisateurs
naiviRouterrouters/naivi.tsFichiers, chunks, paires Q&A, logo, index, feedback, transcription
rolesTagsRouterrouters/roles-tags.tsTags, rôles, associations
healthCheck, i18nrouters/index.tsProcédures publiques

Le détail des procédures est dans Fonctionnement & logique principale.

Variables d'environnement clés

VariableDescription
DATABASE_URLBase PostgreSQL principale (schémas auth et naivi)
CHAINLIT_DATABASE_URLBase Chainlit, lue pour le logo et les feedbacks
BETTER_AUTH_SECRET, BETTER_AUTH_URLBetter Auth
CORS_ORIGINOrigine du front autorisée (utilisée aussi comme trustedOrigins)
MICROSOFT_CLIENT_ID, MICROSOFT_CLIENT_SECRET, MICROSOFT_TENANT_IDOAuth Microsoft
DOCUMENT_PROCESSOR_URLURL de document-processor (défaut dans le code : http://localhost:8001)
INDEX_API_URLURL de l'API d'index de rag-agent ; sans elle, regenerateIndex échoue
I18N_JSONTraductions en JSON inline
LITELLM_API_BASE, LITELLM_API_KEY, TRANSCRIPTION_MODEL_IDTranscription audio (transcribeAudio)

La liste complète et les valeurs d'exemple sont dans .env.example à la racine du dépôt et dans la page Déploiement.

Contrat des procédures

Une procédure oRPC lève une ORPCError en cas d'échec et renvoie son payload en cas de succès. Le client gère les erreurs avec try/catch.

Quelques procédures renvoient encore une enveloppe { success, error } : processUploadedFile, processUploadedQA, regenerateIndex et les helpers d'ajout manuel. Cette forme est à considérer comme un écart au contrat, pas comme la norme.

Choix techniques

  • Bun + Hono : démarrage rapide, peu de surcharge, API Web standards.
  • oRPC : contrat typé entre le front et le back, middlewares de contrôle d'accès.
  • Drizzle : schéma TypeScript, migrations SQL versionnées.
  • Better Auth : sessions, OAuth Microsoft, plugin admin.
  • document-processor séparé : les dépendances de parsing (Docling, PyTorch) restent hors du runtime TypeScript.