Server e client per gestire automaticamente dal browser le partite notturne di lupus in Cavalieri e piazza dei Miracoli
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
Antonio De Lucreziis 39c793583b Primi test su codice dei regolamenti delle partite 2 years ago
_frontend EventBus e WebSocket 2 years ago
auth Slight refactor 2 years ago
database Major refactor into the /handlers system and wrote a bit of the architecture in the README 2 years ago
events Major refactor into the /handlers system and wrote a bit of the architecture in the README 2 years ago
handlers Major refactor into the /handlers system and wrote a bit of the architecture in the README 2 years ago
lupus Primi test su codice dei regolamenti delle partite 2 years ago
model Aggiunta creazione partite 2 years ago
routes Major refactor into the /handlers system and wrote a bit of the architecture in the README 2 years ago
util Primi test su codice dei regolamenti delle partite 2 years ago
.gitignore Initial project structure 2 years ago
LICENSE Added MIT License 2 years ago
README.md Major refactor into the /handlers system and wrote a bit of the architecture in the README 2 years ago
go.mod Primi test su codice dei regolamenti delle partite 2 years ago
go.sum Primi test su codice dei regolamenti delle partite 2 years ago
main.go Major refactor into the /handlers system and wrote a bit of the architecture in the README 2 years ago

README.md

Lupus Lite

Usage

# Development Mode: also starts "npm run dev" inside "_frontend/"
$ MODE=dev go run .

# Production Mode
$ cd _frontend
$ npm run build
$ go build

Architettura

Moduli principali (cose che vengono eseguite e fanno cose di business logic)

  • /main.go

    Entry point principale del server, qui vengono inizializzate concretamente tutte le dipendenze dei vari moduli (come database, router http e servizio di autenticazione).

    Per ora usiamo un semplice database ed un semplice servizio di autenticazione per le sessioni di accesso che tengono tutto in memoria (più avanti passeremo a SQLite, tanto basterà semplicemente scrivere un'altra implementazione per database.Database)

  • /routes

    Questo modulo dipende molto dal router HTTP in quanto contiene tutte le route del server. Oltre questo dipende solo dal modulo /handlers e non sa nulla di /database e /auth.

  • /handlers

    Questo modulo permette di testare tutta l'applicazione in modo isolato dal resto in quanto non sa nulla dei router HTTP e dipende solo da /auth e /database (ed anche da /events, /model e /util ma questi sono moduli "puri") che possono essere facilmente mocked.

Moduli secondari (o boh "terminali" nel senso che dipendono solo da cose esterne a questo progetto)

  • /events

    Questo modulo fornisce una struttura dati di "EventBus" che permette di mandare e ricevere eventi all'interno dell'applicazione.

  • /model

    Questo modulo contiene i modelli di tutte le strutture usate nel database ed alcuni metodi di servizio come User.PublicUser() che converte un User in PublicUser che rappresenta la versione "sicura" senza i campi segreti (come l'hash della password) dell'utente.

  • /database

    L'interfaccia principale è Database e contiene tutte le operazioni possibili da fare sul database. Per ora c'è solo un'implementazione in memoria data da *memDB

  • /auth

    L'interfaccia principale è AuthService e contiene alcuni metodi per autenticare e registrare gli utenti e creare token di sessione. Per ora l'unica implementazione è *memAuth e dipende da un'istanza di database.Database e tiene i token di sessione in memoria.

  • /util

    Questo modulo contiene alcune funzioni di utility e per ora anche varie funzioni di validazione dei form che arrivano dalla frontend, come validazione di username e password per la registrazione degli utenti.

Ed infine c'è il modulo che si occupa del far avanzare le partite e della risoluzione automatica.

  • /lupus

    Questo modulo non dipende da nulla, l'idea è che conterrà le strutture per gestire lo stato delle partite e gli algoritmi per la risoluzione automatica di quest'ultime.

    Al massimo potrebbe contenere alcune informazioni su come serializzare lo stato delle partite però per ora tutte le strutture qui dentro sono annotate per essere serializzate a JSON ed anche quando passeremo ad SQLite forse converrà fare sempre così.

    TODO: Al massimo potrebbe dipendere da /model ma forse non serve.