Kalendarz był pierwszą rzeczą, dla której w ogóle zacząłem budować Algebrę, i długo wydawał mi się najprostszą częścią projektu. Uczeń wybiera termin, zostawia dane i dostaje potwierdzenie, a ja widzę rezerwację w panelu. Przez kilka tygodni na przełomie roku ten prosty mechanizm był jednak moim największym problemem, bo rezerwacje po prostu znikały.
To najważniejsza lekcja z całego projektu, więc opisuję ją dokładnie, łącznie z drogami, które okazały się ślepe.
Co musiał umieć kalendarz
Od początku chciałem mieć w jednym kalendarzu lekcje indywidualne i grupowe, a to oznaczało więcej niż zwykłą listę wolnych godzin. Każda lekcja ma swoją długość, grupy mają limit miejsc, a ja muszę móc zablokować termin, wpisać urlop i przenieść zajęcia. Do tego doszedł formularz kontaktowy, wiadomości w panelu i maile: potwierdzenie rezerwacji dla ucznia, powiadomienie dla mnie, a później przypomnienie z linkiem do lekcji.
Maile wysyłałem na początku ze zwykłej skrzynki w Gmailu, z której aplikacja korzystała tak, jak korzysta z niej program pocztowy. Na małą skalę to wystarczało, a w lutym doszły jeszcze powiadomienia na telefon i na WhatsAppa, żeby nowa rezerwacja nie czekała, aż zajrzę do poczty.
Objawy
W listopadzie zaczęły się dziwne rzeczy. Po wgraniu nowej wersji na serwer (informatycy nazywają to wdrożeniem) strona potrafiła pokazać błąd, bo z bazy danych nagle znikała tabela z rezerwacjami albo z wiadomościami. Przepadały blokady terminów ustawione w panelu, a razem z nimi rezerwacje, choć nikt ich nie odwoływał.
Szukałem błędu tam, gdzie wydawało się to logiczne, czyli w kodzie. Dopisałem zabezpieczenie, żeby brak tabeli nie wywracał całej strony, osobną stronę do podglądania, co dzieje się w środku, i odtwarzanie brakujących tabel przy każdym uruchomieniu aplikacji. Pod koniec listopada kazałem jej jeszcze dokładnie notować, co się dzieje przy zapisywaniu blokad, bo podejrzewałem, że gdzieś po drodze zapis się nie udaje. Każda z tych poprawek łagodziła objawy, ale żadna nie usuwała przyczyny.
Przyczyna, czyli dysk, który nie pamięta
Algebra stała na darmowym planie Rendera, firmy, która trzymała mój serwer, a cała baza danych była jednym plikiem na tym samym dysku co aplikacja. Tego, czego wtedy nie wiedziałem, nie da się wyczytać z kodu, bo zależy od serwera: przy każdym wgraniu nowej wersji Render buduje aplikację od nowa, na czystym dysku. Wszystko, co aplikacja zapisała u siebie od poprzedniego razu, przepada.
To tłumaczyło wszystko naraz. Nowe wersje wgrywałem często, czasem kilka razy dziennie, więc baza równie często wracała do stanu, w jakim leżała razem z kodem. Znikały nie tylko rezerwacje, ale wszystko, co aplikacja trzymała w plikach na serwerze: ustawienia, urlopy i wiadomości. Kod robił dokładnie to, co miał robić, tylko zapisywał dane w miejscu, które z założenia jest tymczasowe.
Trzy podejścia do bazy
Najpierw spróbowałem uporządkować to, co miałem, i przeniosłem wiadomości oraz ustawienia z osobnych plików do bazy, żeby wszystko leżało w jednym miejscu. Problem został, bo to jedno miejsce nadal stało na znikającym dysku.
W styczniu sięgnąłem po rozwiązanie nietypowe: przeniosłem bazę do Arkuszy Google. Aplikacja czytała i zapisywała dane w arkuszu, więc leżały one wreszcie poza serwerem, a ja mogłem je obejrzeć, poprawić albo wyeksportować jak w każdym arkuszu kalkulacyjnym. Działało, ale wolno, bo każde sięgnięcie po dane szło przez internet do arkusza. Szybko dodałem więc odświeżanie na żądanie, żeby panel administratora nie mielił przy każdym kliknięciu.
Pod koniec stycznia przeszedłem wreszcie na prawdziwą bazę danych (PostgreSQL) w Neonie, firmie, która trzyma ją na osobnym serwerze. Taka baza nie wie nic o tym, ile razy wgrywam nową wersję aplikacji, więc od tej chwili nowa wersja zmienia tylko kod, a dane zostają tam, gdzie były. Przy przeprowadzce trzeba było jeszcze uzupełnić brakujące pola, poprawić zabezpieczenia formularzy i posprzątać stare dane, ale rezerwacje przestały znikać.
Co z tego wynika
Najważniejszy wniosek brzmi banalnie, ale kosztował mnie kilka tygodni: baza danych nie może mieszkać na tym samym dysku co aplikacja, jeśli ten dysk jest tymczasowy. Przy każdej aplikacji, która cokolwiek zapisuje, warto więc najpierw zapytać, gdzie fizycznie leżą dane i co się z nimi stanie przy wgraniu następnej wersji. Drugi wniosek jest mniej oczywisty: kiedy objawy są dziwne i nie dają się powtórzyć na zawołanie, przyczyny warto szukać poza kodem, w tym, jak i gdzie aplikacja jest uruchamiana.
Trzeci dotyczy ludzi, a nie techniki. Zgubiona rezerwacja może oznaczać ucznia, który przychodzi na lekcję, o której nic nie wiem, albo termin sprzedany dwa razy. Przy kalendarzu, z którego korzystają inni, błąd w zapisie danych nie jest więc drobną usterką, tylko czyimś zmarnowanym popołudniem.
Cała seria
To druga część serii o tym, jak powstawała Algebra i Spółka:
- Pierwsza Algebra: Flask, szablony i PHP, z którego szybko zrezygnowałem
- Rezerwacje, które znikały po każdym wdrożeniu
- Algebra od nowa: z szablonów Flaska na Reacta i TypeScript
- Cennik w pliku, Premium i pierwsza bramka płatności
- Zadania, karta wzorów i rysunki, które nie chciały się zgadzać
Jak całość wygląda dzisiaj, opisuję we wpisie Algebra i Spółka od środka.