Przez pierwsze miesiące Algebra działała tak jak większość prostych stron. Przeglądarka prosiła serwer o stronę, a serwer, napisany we Flasku (popularnym narzędziu do budowania stron), brał gotowy szkielet, czyli szablon, wstawiał w niego dane z bazy i odsyłał całość. Przy stronach, które się nie zmieniają, i przy formularzu rezerwacji to w zupełności wystarczało.
Zimą Algebra przestała być jednak stroną z kalendarzem. Doszedł panel ucznia z zadaniami, w których wzory muszą wyglądać jak w podręczniku, karta wzorów, diagnoza poziomu, pierwsze gry i pokój lekcyjny z wideo i tablicą. Wszystko to dzieje się na ekranie ucznia: reaguje na kliknięcia, przelicza i zmienia się bez przeładowania strony. Przy starym sposobie oznaczało to coraz więcej osobnych kawałków kodu doklejanych do stron, z których każdy wiedział o pozostałych coraz mniej.
Dlaczego budować od nowa
W styczniu próbowałem jeszcze ratować stary układ. Z największych stron, czyli panelu zadań i karty wzorów, wydzieliłem wygląd i działanie do osobnych plików, żeby dało się je w ogóle przeczytać. Pomogło na chwilę, ale przy każdej nowej funkcji wracał ten sam kłopot: to, jak działała jedna strona, było rozsiane po kilku plikach w różnych miejscach, więc poprawka w jednym psuła coś w drugim.
React, narzędzie do budowania stron, które zachowują się jak aplikacje, rozwiązuje dokładnie ten problem. Dzieli ekran na klocki, a każdy z nich, na przykład okienko z zadaniem, ma swój wygląd i zachowanie w jednym miejscu. TypeScript dokłada do tego ścisły opis danych, które krążą między częściami aplikacji. Brzmi to jak formalność, ale w praktyce sporą część błędów komputer wyłapuje, zanim nowa wersja trafi na stronę, a nie dopiero u ucznia, który akurat próbuje zarezerwować lekcję.
Najpierw wierna kopia, potem zmiany
Kiedy buduje się od nowa coś, co działa, kusi, żeby przy okazji poprawić wszystko naraz. Uznałem, że to prosta droga do sytuacji, w której nic nie działa i nie wiadomo dlaczego. Pod koniec lutego przenosiłem więc strony po kolei, każdą tak, żeby wyglądała i działała dokładnie jak dotąd. Najpierw poszły te, bez których platforma nie istnieje: zadania, logowanie przez Google, rezerwacje i wiadomości. Potem kalendarz, profil, diagnoza, płatności i pokój lekcyjny, a na końcu dziesięć mniejszych stron, które do tej pory istniały tylko z nazwy.
Dopiero kiedy nowa wersja robiła wszystko to, co stara, zabrałem się do zmian. Na początku marca serwer przestał składać strony i od tej pory tylko przechowuje dane i odpowiada na pytania strony, a to, co widzi użytkownik, powstaje już w jego przeglądarce. Stare szablony usunąłem z projektu i obie części zaczęły żyć zupełnie osobno.
Strona i dane w dwóch miejscach
Rozdzielenie obu części zmieniło też to, gdzie co stoi. Część, którą ogląda użytkownik, to teraz zestaw gotowych plików, które rozsyła Cloudflare, firma trzymająca kopie stron blisko odwiedzających, bez serwera, którego musiałbym pilnować. Część z danymi została u Rendera, który uruchamia aplikacje na swoich serwerach, a w kwietniu przeniosłem ją do podobnego Koyeba. Baza danych przeszła w marcu z Neona do Supabase i tam działa do dziś.
Z takim podziałem przyszły kłopoty, o których wcześniej nie miałem pojęcia. Przeglądarka dba o bezpieczeństwo i nie pozwala stronie spod jednego adresu swobodnie rozmawiać z serwerem spod innego, więc serwer z danymi musiał dostać listę adresów, z których wolno go pytać. Najbardziej podstępny okazał się drobiazg: serwer odsyłał pytania skierowane pod adres bez ukośnika na końcu pod ten sam adres z ukośnikiem, a przeglądarka przy takim przekierowaniu odrzucała pytanie, zanim w ogóle do niego dotarło.
Pokój lekcyjny, który zmieniał się co kilka dni
Równolegle szukałem sposobu na lekcje online bez skakania między aplikacjami. Pod koniec stycznia wstawiłem na stronę tablicę z Miro. Na początku lutego zastąpiłem ją tablicą tldraw z rozmową wideo przez Jitsi, a dzień później tablicą WBO, bo tldraw wyłączył pokoje, z których korzystałem. Po kolejnych dwóch dniach okazało się, że ogólnodostępny serwer Jitsi po pięciu minutach przerywa rozmowy wstawione na cudzą stronę. Tego samego dnia spróbowałem więc JaaS, czyli Jitsi w formie gotowej usługi, a wieczorem przeszedłem na własne połączenie wideo, zbudowane na PeerJS, narzędziu, które łączy przeglądarki bezpośrednio ze sobą.
Każda z tych zmian coś naprawiała, a coś odbierała. Z tamtych tygodni wyniosłem jedno: cudza usługa wstawiona na własną stronę zawsze gra według cudzych zasad, a te mogą się zmienić z dnia na dzień.
Po przesiadce
Dziś wszystko, co widzi uczeń, zbudowane jest w Reakcie i TypeScripcie, a serwer na Flasku zajmuje się już wyłącznie danymi. Nowa funkcja to zwykle nowy klocek na ekranie i nowe pytanie, na które serwer umie odpowiedzieć, a nie kolejny kawałek kodu doklejony do starej strony. Najważniejsza lekcja z tej przesiadki nie dotyczy jednak Reacta: kiedy przebudowuje się coś, co działa, warto najpierw odtworzyć to jeden do jednego, a poprawiać dopiero potem.
Cała seria
To trzecia 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.