Newsfeed od środka: serwer wysyła dane, przeglądarka składa karty
Od pierwszych dni Moonlight newsfeed działał tak, że serwer sklejał każdą kartę w gotowy HTML i wysyłał ją do przeglądarki w całości. To podejście ma jedną wielką zaletę — jest proste — i kilka wad, które rosły razem z platformą. Każde doładowanie strony niosło kilobajty znaczników zamiast samej treści. Każda zmiana na liście (nowy post, edycja, usunięcie) wymagała dłubania w gotowym HTML-u na żywo. A powiadomienia na żywo o nowych wpisach nie miały się jak wpiąć w listę, którą serwer traktował jak jednorazowy wydruk.
Dziś ta architektura się odwraca. Serwer wysyła czyste dane: tytuł, autora, okładkę, liczniki, uprawnienia widza. Karty składa przeglądarka — z komponentów, po jednym na każdy typ treści: post, komiks, rozdział, książka, fanart, utwór, album, wpis bonusowy i tak dalej, trzynaście typów w komplecie, łącznie z pełnym drzewem posta (media, podglądy linków, osadzone wideo) i wpisami bonusowymi z ich progami dostępu.
Dlaczego warto było to przejść
Najkrótsza odpowiedź: lista, która rozumie własną zawartość, umie dużo więcej niż wydruk.
Kiedy publikujesz post, karta pojawia się na górze feedu od razu, złożona z tych samych danych, które właśnie zapisał serwer. Kiedy edytujesz — karta odświeża się sama. Kiedy ktoś, kogo obserwujesz, opublikuje coś nowego, powiadomienie na żywo ma wreszcie którędy wjechać na listę. A ten sam feed, bez drugiej implementacji, daje się osadzić w innych miejscach platformy — pierwszym jest widget feedu w Kokpicie, który korzysta z identycznych kart i wspólnego silnika.
Jest i strona praktyczna: mniej danych w locie. Ta sama treść w formie czystych danych waży ułamek tego, co gotowy HTML, więc doładowywanie kolejnych stron feedu robi się lżejsze — co czuć zwłaszcza na telefonie.
Największe wyzwanie: żeby nikt niczego nie zauważył
Przepisanie kilkunastu typów kart to dużo okazji, żeby coś przestawić o piksel albo zgubić jakiś przycisk. Przyjęliśmy więc twardą zasadę: nowa karta ma wyglądać i zachowywać się identycznie jak stara, co do klasy CSS. Zbudowaliśmy do tego automatyczną kontrolę, która składa każdą kartę oboma sposobami i porównuje wyniki — różnica oznacza czerwony test, a czerwony test blokuje zmianę. Przy okazji tej drobiazgowej inwentaryzacji wyszło kilka zadawnionych błędów starego kodu: linki prowadzące w złe miejsca, okładka czytana z niewłaściwego pola, uśpiony błąd w wpisach bonusowych. Wszystkie naprawione.
Nowa ścieżka weszła za bezpiecznikiem: w każdej chwili można wrócić do poprzedniego renderowania jednym parametrem, a obie wersje działały równolegle przez cały okres prób. Stary kod nigdzie nie zniknął — pozostałe miejsca platformy korzystają z niego jak dotąd, a jego wymiana przyjdzie w swoim czasie, tym samym trybem.
Co dalej
Ten sam model — dane z serwera, karty w przeglądarce — będzie wchodził w kolejne zakątki platformy, między innymi wpisy bonusowe na stronach fanpage'y. Fundament już jest: jeden zestaw kart, jeden kontrakt danych, jedna lista, która wie, co wyświetla.