Boty Discord

Społeczności naszych marek żyją na Discordzie, a nie na stronie. To tam trafia nowy klient, tam otwiera zgłoszenie, tam czeka na rolę dającą dostęp do właściwych kanałów. Przy kilkuset członkach ręczne ogarnianie ticketów, powitań i ról po prostu przestaje się spinać - ktoś musi być na miejscu, patrzeć i klikać, a to nie skaluje się z liczbą osób.

Zamiast pisać jednego uniwersalnego bota do wszystkiego, zbudowaliśmy jeden rdzeń i zestaw modułów, z których składa się każdego bota osobno. Cztery serwery, cztery role, cztery konfiguracje - ale jedno miejsce, w którym żyje logika. Ten case study jest o tym, dlaczego taki podział opłacał się bardziej niż wygodny na początku monolit.

Kuszące jest napisać jednego bota, który robi całą robotę na wszystkich serwerach. Problem w tym, że każdy serwer ma trochę inne potrzeby: inny zespół do pingu przy tickecie, inną ścieżkę wejścia nowego członka, inne role i inny próg weryfikacji. Uniwersalny bot, który ma obsłużyć je wszystkie, z czasem robi się choinką z flag, w której nikt nie chce niczego ruszać, bo nie wiadomo, co jeszcze od tego zależy.

Druga pułapka to współdzielony stan. Jeden proces obsługujący cztery serwery naraz to jeden punkt awarii - błąd w logice ticketów potrafi położyć powitania na zupełnie innym serwerze. A im więcej serwer wozi kodu, którego nie używa, tym trudniej cokolwiek w nim bezpiecznie zmienić.

Poszliśmy w drugą stronę: jeden rdzeń z modułami, które w ekosystemie Discorda nazywają się cogami, a każdy bot to zestaw włączonych cogów. Serwer ticketowy bierze cog ticketów, serwer, który tego nie potrzebuje, po prostu go nie włącza.

W praktyce ekosystem to cztery odrębne boty, z których każdy robi jedną rzecz porządnie. Ticketowy otwiera wątki zgłoszeń i pinguje właściwy zespół, żeby zgłoszenie nie utknęło w próżni. Powitalny prowadzi nowego członka przez pierwsze kroki. Weryfikacyjny potwierdza adres e-mail przy wejściu. Porządkowy pilnuje higieny ról i przydziela je automatycznie.

Ten podział nie jest kosmetyczny. Każdy bot ma własny zakres uprawnień i własny stan, więc awaria jednego nie pociąga reszty, a zmiana w jednym nie wymaga myślenia o trzech pozostałych. Wspólny jest tylko rdzeń - to, jak cog wpina się do bota, jak czyta konfigurację i jak gada z API.

Cog to zamknięta jednostka: własne komendy, własne nasłuchy, własny stan. Wpinasz go do bota jedną linią, wypinasz tak samo. Nie ma globalnego splątania - cog ticketów nie wie nic o cogu ról i nie musi. Poniżej wycinek weryfikacji: nowy członek dostaje rolę oczekującego i prompt do potwierdzenia adresu, zanim zobaczy resztę serwera.

Nazwy takie jak on_member_join czy add_roles narzuca API Discorda i zostają jak są - reszta identyfikatorów idzie po naszej konwencji. To granica, na której idziesz za biblioteką, a nie za własnym stylem, i jedyne miejsce, gdzie mieszają się dwie konwencje nazewnicze.

Największy zysk nie jest widoczny na serwerze, tylko w tym, jak się te boty utrzymuje. Poprawka w logice ticketów idzie w jednym miejscu i trafia wszędzie tam, gdzie ten cog jest włączony - nie przepisujesz jej cztery razy i nie zapominasz o jednym serwerze. Żaden serwer nie wozi kodu, którego nie używa, więc jego konfiguracja jest dokładnie tak złożona, jak jego realne potrzeby.

Dorzucenie piątego serwera nie oznacza pisania piątego bota od zera. Składa się go z tego, co już jest: bierzesz cogi, które pasują, ustawiasz konfigurację i tyle. To jest różnica między czterema osobnymi projektami a jednym ekosystemem, który rośnie przez dokładanie modułów, a nie przez mnożenie kodu.