games/docs/studies/021-UROBURAS_SERVER_REFERENCE_STACK.md

Uroburas — stack serveur de référence

Statut

Étude de référence pour 0.2.0-0-pre.6.

Runtime async

Référence :

Tokio

HTTP / Web

Référence :

Actix Web

Responsabilités initiales :

• auth ;
• compte ;
• maps/assets metadata ;
• Hall of Fame ;
• rewarded grants ;
• admin initiale ;
• pages Web.

HTML server-side

Référence :

Maud

Objectif :

• rendu HTML côté Rust ;
• pages compte ;
• Hall of Fame ;
• administration ;
• pages jeu/portail.

Le JavaScript reste réservé aux interactions qui le nécessitent.

Realtime public

Référence :

Tokio + tokio-tungstenite

Utilisé pour les futurs Modes 3 puis 2.

La logique de gameplay ne dépend pas directement des types Tungstenite.

Le transport doit rester encapsulé derrière le protocole Uroburas afin qu'un benchmark futur puisse justifier un changement d'implémentation sans réécrire la simulation.

gRPC

Référence conditionnelle :

tonic

Utilisation envisagée :

• server-to-server ;
• worker média/replay ;
• orchestration interne ;
• appels typés entre services lorsque la séparation physique le justifie.

gRPC n'est pas obligatoire pour le transport public client/gameplay.

Le client public utilise en priorité :

HTTPS + WebSocket

Localization

Référence :

Fluent / fluent-bundle

Côté client :

• menus ;
• HUD ;
• erreurs ;
• contenu localisé ;
• maps/assets téléchargeables.

Côté serveur :

• HTML ;
• emails ;
• messages utilisateur ;
• administration.

Les protocoles transportent des codes/identifiants métier, pas des chaînes déjà traduites.

Email

Référence :

Lettre

Cas initiaux possibles :

• vérification de compte ;
• reset password ;
• notifications sécurité ;
• magic link si retenu.

Les contenus email utilisent Fluent.

Séparation des modèles

Ne pas partager directement comme modèles métier :

• types Actix ;
• types Tungstenite ;
• messages protobuf ;
• types Maud.

Séparation attendue :

domain model
HTTP DTO
WebSocket protocol
gRPC contracts
HTML view model

Performance

La stack realtime doit être validée par benchmarks de charge avant gel long terme.

Mesures candidates :

• connexions concurrentes ;
• mémoire/connexion ;
• messages/s ;
• bytes/s ;
• p50/p95/p99 ;
• backpressure ;
• coût broadcast ;
• coût interest management ;
• reconnect/resync ;
• CPU par tick.

Le choix tokio-tungstenite est la référence initiale, pas une affirmation non mesurée de supériorité universelle.