Lo stato d’animo
Era il 2017. Da un anno si era abbattuta una sventura nella mia casa e avevo bisogno di creare, perché è lì che mi rifugio quando tutto sembra insopportabile. Che si tratti di musica, programmazione o della creazione di un oggetto, lì trovo la pace.
Avevo bisogno di uscire, di riprendere la vita dopo anni difficili. Ma le occasioni per socializzare e conoscere persone con gli stessi interessi mi sembravano sempre più rare. Quindi quale occasione migliore se non tapparsi in casa davanti a un computer? 😄
L’idea
Avevo in mente una cosa semplice: creare un’app per essere meno soli, un cinema, una passeggiata, un momento di condivisione… cominciai a sviluppare in un ambiente a me molto più familiare ovvero il web. Una web app rozza e ridicola per creare attività e cercare amici nella zona, però mi fece capire che poteva essere una buona idea, io l’avrei usata sicuramente!
Poi la accantonai e rimase in una cartella piena di polvere per anni.
Nel 2022 sviluppai un’app per un cliente. Una cosa fatta bene, non un progettino veloce: un lavoro di svariati mesi. Questo mi portò ad approfondire molto le mie conoscenze, sia lato server che client, usando Node.js e React.
Finito questo lavoro ripresi in mano il progettino, era il 2023, e mi dissi: farò un’app per dispositivi mobile ma dovrà usare tutto il meglio della tecnologia disponibile! Dovrà essere fatta bene!
Poi da bravo programmatore non pensai a costi, marketing, guadagni… pensai solo: e se venisse usata da tantissime persone contemporaneamente? Dovrà esser veloce e scalabile per più utenti! Nel caso diventasse un’app super popolare dovrò solo aggiungere un server in 10 minuti ed ecco serviti altri utenti! Insomma mi sono concentrato sulla parte tecnica perché volevo imparare e fare le cose al meglio!
Una vecchia screen delle prime versioni della chat
Il perfezionismo esasperato
L’utilizzo di più server per distribuire il carico è sicuramente un’idea ottima ma ha una difficoltà ulteriore rispetto ad un singolo server, ovvero i dati devono essere disponibili per tutti i server. Per dati non intendo il classico database che per sua natura può già fornire i dati a più server ma i media (foto, video, audio) e soprattutto i dati in tempo reale (messaggi, completamento di operazioni, etc)
Immaginate un utente, apre l’app, il proxy lo indirizza al server migliore (più vicino e con meno carico) l’utente invia un messaggio diretto ad un altro utente che però è connesso ad un altro server. Senza un sistema che faccia comunicare i due server, il messaggio potrebbe essere salvato nel database, ma non verrebbe recapitato in tempo reale al destinatario.
Redis, questo sconosciuto
Per fare in modo che il messaggio raggiunga l’utente connesso ad un altro server serve un “Messaggero”, nel mio caso, questo messaggero si chiama Redis. L’adapter Redis di Socket.IO permette proprio di distribuire gli eventi tra server diversi.
Prendiamo il caso di due utenti connessi a due server diversi: l’utente A vuole inviare un messaggio all’utente B.
Il percorso è questo:
- L’utente A invia un messaggio tramite Socket.IO al server 1.
- Il server 1 salva il messaggio nel database e, attraverso Redis Pub/Sub, un sistema di pubblicazione e ascolto, diffonde l’evento agli altri server.
- Il server 2, al quale è connesso l’utente B, riceve l’evento e consegna il messaggio a B tramite la sua connessione Socket.IO.
Poi bisogna gestire anche le conferme di consegna e gli eventuali tentativi di reinvio: spedire un messaggio e sapere che è arrivato sono due cose diverse.
Quanta fatica solo per inviare un messaggino vero? Ma se si vuole un’app performante e “scalabile” questo è un ottimo metodo!
Prima che diventasse codice, spesso Khora iniziava così: frecce, appunti e qualche dubbio.
Se avessi fatto l’app con un solo server sarebbe stato molto più semplice. Ma volevo che, in caso di crescita, l’app fosse già pronta a distribuire il lavoro su più server. E poi, per me, era anche una sfida: volevo capire come si costruisce un sistema del genere.
Foto, video e audio
Parliamo ora dei media: foto, video e audio. Devono essere accessibili a tutti i server dell’app, ma anche protetti quando si tratta di contenuti privati.
Invece di salvarli nelle cartelle di un singolo server, ho scelto un object storage: uno spazio condiviso in cui vengono archiviati i file, chiamati “oggetti”.
Tutti i server possono così recuperare ciò che serve dallo stesso posto.
Naturalmente, condiviso non significa pubblico! Gli accessi devono essere configurati correttamente. Per una foto privata, ad esempio, l’app può verificare che l’utente abbia il permesso di vederla e generare un link firmato con una scadenza. Chi possiede quel link può visualizzare la foto finché è valido; dopo la scadenza, il link non permette più di accedervi.
Queste sono solo due delle scelte tecniche che stanno dietro a Khora. Nelle prossime puntate racconterò come il progetto ha preso forma: i problemi da risolvere, le arrabbiature e le soddisfazioni, ma anche la moderazione di post e messaggi, le foto sconvenienti e gli spammer… e tanto altro!
E soprattutto racconterò come, da un’idea nata per essere meno solo, mi sono ritrovato a costruire tutto questo… da solo davanti a un PC! 😄
Commenti