Boty Discord

Le community dei nostri marchi vivono su Discord, non su un sito. È lì che arriva un nuovo cliente, lì che apre un ticket, lì che aspetta il ruolo che dà accesso ai canali giusti. Con qualche centinaio di membri, gestire a mano ticket, benvenuti e ruoli semplicemente smette di reggere - qualcuno deve essere lì, guardare e cliccare, e questo non scala con il numero di persone.

Invece di scrivere un bot universale che faccia tutto, abbiamo costruito un nucleo e un insieme di moduli con cui ogni bot viene assemblato separatamente. Quattro server, quattro ruoli, quattro configurazioni - ma un unico posto in cui vive la logica. Questo caso di studio spiega perché questa divisione ha reso più di un monolite che sarebbe stato comodo all'inizio.

È allettante scrivere un bot che faccia tutto il lavoro su ogni server. Il problema è che ogni server ha esigenze un po' diverse: un team diverso da pingare sul ticket, un percorso d'ingresso diverso per un nuovo membro, ruoli diversi e una soglia di verifica diversa. Un bot universale che dovrebbe gestirli tutti col tempo diventa un albero di Natale di flag che nessuno vuole toccare, perché non si sa cos'altro dipenda da essi.

La seconda trappola è lo stato condiviso. Un processo che serve quattro server insieme è un unico punto di guasto - un bug nella logica dei ticket può mettere ko i benvenuti su un server del tutto diverso. E più codice inutilizzato un server porta con sé, più difficile è cambiare qualcosa in esso in sicurezza.

Siamo andati dall'altra parte: un nucleo con moduli, che nell'ecosistema Discord si chiamano cog, e ogni bot è un insieme di cog attivati. Il server dei ticket prende il cog dei ticket; un server che non ne ha bisogno semplicemente non lo attiva.

In pratica l'ecosistema è fatto di quattro bot separati, ciascuno che fa una cosa bene. Il bot dei ticket apre thread di ticket e pinga il team giusto perché una segnalazione non resti nel vuoto. Il bot di benvenuto guida un nuovo membro attraverso i primi passi. Il bot di verifica conferma un indirizzo e-mail all'ingresso. Il bot dei ruoli mantiene l'igiene dei ruoli e li assegna automaticamente.

Questa divisione non è cosmetica. Ogni bot ha il proprio ambito di permessi e il proprio stato, così il guasto di uno non trascina gli altri, e un cambiamento in uno non richiede di pensare agli altri tre. Comune è solo il nucleo - come un cog si aggancia al bot, come legge la configurazione e come parla con l'API.

Un cog è un'unità autonoma: comandi propri, listener propri, stato proprio. Lo agganci al bot in una riga e lo sganci allo stesso modo. Non c'è alcun intreccio globale - il cog dei ticket non sa nulla del cog dei ruoli e non ne ha bisogno. Sotto un estratto della verifica: un nuovo membro riceve un ruolo di attesa e un invito a confermare il suo indirizzo prima di vedere il resto del server.

Nomi come on_member_join o add_roles sono imposti dall'API di Discord e restano così come sono - il resto degli identificatori segue la nostra convenzione. È il confine in cui si segue la libreria, non il proprio stile, e l'unico posto in cui due convenzioni di denominazione si mescolano.

Il guadagno maggiore non è visibile sul server ma nel modo in cui questi bot vengono mantenuti. Una correzione nella logica dei ticket atterra in un solo posto e raggiunge ovunque quel cog sia attivo - non la riscrivi quattro volte e non dimentichi un server. Nessun server porta codice che non usa, quindi la sua configurazione è complessa esattamente quanto i suoi bisogni reali.

Aggiungere un quinto server non significa scrivere un quinto bot da zero. Lo si assembla da ciò che esiste già: prendi i cog che servono, imposti la configurazione, e basta. È la differenza tra quattro progetti separati e un ecosistema che cresce aggiungendo moduli, non moltiplicando codice.