Ekosystem Trans.info

Redakcja, czytelnicy, wyszukiwarki i reklamy nadal zależą od platformy, kiedy pod spodem zachodzą zmiany inżynierskie. Migracja musiała zachować publikowanie i pomiar, zamiast traktować system jak pusty projekt.

• Wsparcie istniejącej pracy redakcyjnej
• Dokończenie wybranego zakresu migracji
• Zachowanie wielojęzycznych URL-i i relacji treści

Kiedy dołączyłem do projektu, migracja z Next.js 12 do 14 była już rozpoczęta, ale do końca było daleko. W idealnych warunkach kolejne strony i endpointy przenosilibyśmy stopniowo z Pages Routera do App Routera. Ta decyzja nie została jednak podjęta na początku, co zwiększyło koszt późniejszego porządkowania zakresu.

Dzięki alignmentowi i wspólnej pracy ograniczyliśmy migrację: część funkcji została tymczasowo wycięta, żeby dokończyć podstawę, a następnie zrealizować je osobno. Z perspektywy zarządzania był to mismanagement, a nie dowód, że migracja etapowa jest niemożliwa. Developer musi mieć przestrzeń, żeby przedstawić odważniejszą, mniejszą i odwracalną opcję — także wtedy, gdy wymaga ona dodatkowych adapterów, pomiaru i równoległego utrzymania.

• Pages Router i App Router jako osobne granice migracji
• Mniejszy zakres zamiast udawania kompletnego przepisania
• Wspólne decyzje, które pozwalają bezpiecznie domknąć etap

Po wdrożeniu pierwszych wersji optymalizację grafik przenieśliśmy do WordPressa, a później poprawiliśmy ich przekazywanie przez Next.js. Pamięć podręczna działała wielopoziomowo: po stronie WordPressa, Elasticsearcha i Next.js. Większość rozwiązania była plikowa, bo rozbudowa stosu byłaby zbyt kosztowna i niedopuszczona w tym środowisku.

Dopiero po około dwóch latach pojawił się problem z niektórymi statusami wpisów, które nie odświeżały się wystarczająco szybko. Dodaliśmy mechanizmy wymuszonego odświeżania konkretnych danych. To nie przekreślało cache — pokazało, że wydajność musi mieć zaprojektowaną drogę powrotu do aktualnego stanu.

• Optymalizacja grafik poza serwerem Next.js
• Warstwy WordPress, Elasticsearch i Next.js
• Rewalidacja jako część utrzymania, nie awaryjny dodatek

Przy prototypach widoków zdarzało się, że projektowano tylko szeroki ekran. Zwracałem uwagę, że wersja mobilna jest częścią produktu, szczególnie gdy ruch z Google Discover potrafił dawać jej zaskakująco dobre rezultaty. Nie traktuję tego jako statystyki dla każdego serwisu, tylko jako lekcję: sprawdzaj własnych odbiorców, zanim uznasz desktop za domyślny przypadek.

Wersje hiszpańska, włoska i francuska wymagały współpracy pipeline'ów treści, konfiguracji WordPressa, routingu frontendu, analityki i monetyzacji. PolyTrans stał się częścią tej infrastruktury wydawniczej.

Praca była kontynuowana przy serwisach WordPress, implementacji designu, analityce i innych inicjatywach technologicznych Trans.eu. Dłuższy kontekst pozwala zmieniać pojedyncze elementy bez utraty obrazu całego systemu wydawniczego.