Jak prosty moduł dla jednego turnieju rozwinął się w platformę sportową na pokładzie — zaprojektowaną z myślą o niskiej przepustowości i ograniczonych możliwościach testowania.

Założenie było proste: pasażer śledzi Euro 2024 na pokładzie. Na pokładzie samolotu ciężka aplikacja webowa nie wchodziła w grę. Oznaczało wyniki na żywo, statystyki meczów, komentarze, składy, kartki i kluczowe momenty dostarczane przez połączenie, w którym przepustowość mogła spaść poniżej 1 Mb/s, a każde zapytanie miało wymierny koszt.
Prawdziwe wyzwanie leżało w ograniczeniach technicznych. Adresy URL musiały być wcześniej dodane do listy dozwolonych, aplikacji nie dało się przetestować na żywo na pokładzie przed startem, a pierwsze wydanie produkcyjne musiało zadziałać od razu. To właśnie te ograniczenia wyznaczyły architekturę produktu.
Zanim zaprojektowaliśmy interfejs, określiliśmy ograniczenia: wolną i kosztowną łączność, stałą listę dozwolonych adresów URL, brak możliwości iterowania na żywo w samolocie, wysokie opóźnienia oraz zasadę, że liczy się każdy kilobajt. Te ograniczenia wpłynęły zarówno na system techniczny, jak i UX.
Dostawcę danych sportowych wybraliśmy pod kątem małego rozmiaru odpowiedzi z API oraz szybkich aktualizacji. Pierwsze wydanie utrzymaliśmy bez zbędnych zależności od CMS, a interfejs pasażera zaprojektowaliśmy z myślą o czytelności, małej liczbie interakcji i odporności na niestabilne warunki sieciowe. Lekką analitykę dodaliśmy od początku, żeby mierzyć użycie bez konkurowania o transfer z danymi sportowymi na żywo.
Pierwszym wydaniem była aplikacja Next.js uruchamiana w kontenerze, hostowana na Azure i zaprojektowana specjalnie pod warunki pokładowe. Nie miała odtwarzać pełnego portalu sportowego. Miała dostarczać najbardziej przydatne informacje o meczu na żywo, przy przewidywalnym zachowaniu sieci, stałych endpointach i jak najmniejszym transferze danych.
Aby zmniejszyć ryzyko wdrożenia, stworzyliśmy symulowane środowisko testowe odtwarzające kluczowe ograniczenia pokładowe: limitowanie łącza, ograniczenia adresów URL, zachowanie aplikacji podczas inicjalizacji i brak możliwości iterowania na żywo w kabinie. To środowisko stało się miejscem końcowej weryfikacji przed wdrożeniem.
Po Euro 2024 system rozwinął się z funkcji przygotowanej pod jeden turniej w szerszą platformę sportową. Objął kolejne rozgrywki piłkarskie, ligi kobiece i męskie, sporty zimowe oraz wydarzenia związane z Zimowymi Igrzyskami Olimpijskimi.
Gdy produkt zaczął być używany szerzej, analityka stała się narzędziem produktowym, a nie tylko dodatkiem do raportowania. Pokazywała, z jakich typów treści pasażerowie faktycznie korzystają, jak angażują się w widoki na żywo w porównaniu ze statycznymi i gdzie można uprościć produkt bez szkody dla UX.
Prace nad wydajnością trwały także po starcie. Wybrane zewnętrzne skrypty przenieśliśmy do własnego środowiska hostingowego, aby zmniejszyć liczbę żądań, poprawić przewidywalność ładowania i dać zespołowi kontrolę nad rozmiarem zasobów oraz wersjonowaniem. Później dodaliśmy Umbraco w trybie headless, z wielopoziomowym cachowaniem, tak aby możliwość edycji treści nie obciążała aplikacji.
Rezultatem był produkt sportowy, który mógł się dalej rozwijać, nie zamieniając się w ciężką aplikację pełną zależności. To było kluczowe, bo właśnie taki typ rozwiązania nie sprawdziłby się w ograniczeniach pokładowych, dla których produkt został zaprojektowany.
„Na początku wyglądało to jak prosta aplikacja sportowa na żywo. W rzeczywistości trzeba było zbudować niezawodny produkt dla warunków pokładowych, gdzie lista dozwolonych adresów jest stała, łączność ograniczona, a każdy kilobajt ma znaczenie.”
[ DANE SPORTOWE → POZYSKIWANIE → API → APLIKACJA LIVE SPORTS ]Aplikacja Live Sports dla pasażerów zaczęła się od jednego turnieju, a przekształciła się w szerszą platformę sportową zaprojektowaną pod ograniczoną łączność w samolocie. System łączy lekką aplikację dla pasażerów, kontrolowane dostarczanie danych, niestandardową analitykę, zarządzanie treścią w modelu headless i odtwarzalną infrastrukturę chmurową.
Warto zaangażować nas, zanim lista dozwolonych adresów zostanie zatwierdzona. Pomożemy zaprojektować aplikacje najpierw wokół realnych ograniczeń — niskiej przepustowości, wysokich opóźnień, ograniczonych adresów URL i stanu w pamięci podręcznej.