Timerise Offline: Tryb wyspowy dla operacji terenowych

Sobotnie popołudnie na strzelnicy trzydzieści kilometrów za miastem. Dwudziestu klientów na miejscu, kolejna grupa właśnie melduje się przy kiosku. Wtedy modem LTE traci sygnał — przeciążona stacja bazowa podczas lokalnej imprezy albo po prostu rzeczywistość pracy w miejscu otoczonym betonowymi ścianami i lasem. Panel w chmurze gaśnie.

Co się dzieje z rezerwacjami? Ze stanami magazynowymi? Z elektronicznymi zamkami zabezpieczającymi magazyn broni? Jeśli system rezerwacji żyje wyłącznie w chmurze, odpowiedź brzmi: wszystko staje. Obsługa przerzuca się na papier, klienci czekają, a gdy internet wraca, reszta dnia schodzi na uzgadnianie odręcznych notatek z bazą danych.

Dlaczego sam cloud nie wystarcza w terenie

Architektura cloud-first sprawdza się znakomicie w biurach, klinikach i miejskich przestrzeniach coworkingowych — miejscach z redundantnym światłowodem i stabilnym Wi-Fi. Ale rosnąca kategoria firm działa w środowiskach, gdzie nieprzerwany internet to luksus, nie standard:

Strzelnice — często zlokalizowane w strefach przemysłowych lub na terenach wiejskich z kiepskim zasięgiem komórkowym, grube betonowe ściany tłumią sygnał
Pola paintballowe i airsoftowe — leśne polany, opuszczone budynki, otwarty teren bez stałego łącza szerokopasmowego
Parki offroad i trasy rajdowe — odległe lokalizacje, gdzie najbliższy kabel światłowodowy jest kilometry dalej
Obozy bushcraftowe i eventy survivalowe — celowo poza siecią, czasem z łączem satelitarnym lub hotspotem komórkowym jako jedynym łączem z cywilizacją

Te obiekty łączy wspólny wzorzec: potrzebują systemu rezerwacji, śledzenia magazynu i kontroli dostępu tak samo jak każdy miejski biznes — ale nie mogą zagwarantować nieprzerwanej łączności. Pracują z oknami synchronizacji — okresami, gdy internet jest dostępny — zamiast z połączeniem always-on.

Tryb wyspowy: Twoja lokalizacja staje się samowystarczalna

Timerise rozwiązuje to za pomocą trybu wyspowego (Island Mode) — lokalnego serwera wdrożonego na miejscu, który utrzymuje kompletną replikę danych lokalizacji i automatycznie przejmuje obsługę, gdy chmura staje się nieosiągalna.

Serwer lokalny działa na kompaktowej maszynie z Linuksem (mini PC, Intel NUC, nawet urządzenie klasy Raspberry Pi z wystarczającą ilością RAM) podłączonej do tej samej sieci LAN co kiosk i terminale obsługi. Ciągle replikuje dane z chmury w tle. Gdy internet przestaje działać, terminale płynnie przełączają się na serwer lokalny. Gdy łączność wraca, wszystko synchronizuje się z powrotem.

Bez ręcznej interwencji. Bez utraty danych. Bez przestojów.

Architektura: chmura, serwer lokalny i terminale

                    Internet
                       |
              +--------+--------+
              |     Chmura      |
              |  Firestore SSOT |
              +--------+--------+
                       |
             Replikacja na poziomie BD
                  (w czasie rzeczywistym)
                       |
              +--------+--------+
              |  Serwer lokalny |
              |  NestJS + RxDB  |
              +--------+--------+
                       |
                  LAN (Wi-Fi/ETH)
                       |
           +-----------+-----------+
           |           |           |
        Kiosk       Obsługa     Sprzęt
        (PWA)       (PWA)     (Zamki)

Tryb online: Terminale komunikują się z API w chmurze. Serwer lokalny cicho replikuje wszystkie dane w tle — rezerwacje, magazyn, cennik, dane pracowników, stany zamków — osiem kolekcji synchronizowanych w czasie rzeczywistym.

Tryb offline (tryb wyspowy): Gdy chmura staje się nieosiągalna, terminale przekierowują się na serwer lokalny w sieci LAN. Rezerwacje trwają, aktualizacje magazynu przepływają, elektroniczne zamki reagują na polecenia. Lokalizacja działa jako autonomiczna wyspa.

Powrót online: Serwer lokalny wykrywa przywrócenie łączności, wypycha wszystkie lokalnie utworzone dane do chmury, a terminale migrują z powrotem do API chmurowego. Przejście jest niewidoczne dla obsługi i klientów.

Heartbeat i automatyczne przełączanie

Serwer lokalny wysyła heartbeat do chmury co 30 sekund. Jeśli chmura nie wykryje heartbeatu przez ponad 60 sekund, oznacza lokalizację jako offline. Ten status propaguje się w czasie rzeczywistym — publiczna strona rezerwacji wyłącza nowe rezerwacje dla danej lokalizacji (ponieważ chmura nie może zagwarantować dostępności slotów, gdy lokalizacja jest w trybie wyspowym), podczas gdy operacje na miejscu kontynuują nieprzerwanie przez serwer lokalny.

Replikacja na poziomie bazy danych: dlaczego to ma znaczenie

Większość systemów z obsługą offline próbuje rozwiązać synchronizację na warstwie aplikacji — kolejkując wywołania API, odtwarzając zapytania REST, rozwiązując konflikty przez middleware. To podejście jest kruche. Każdy endpoint potrzebuje własnej kolejki offline. Rozwiązywanie konfliktów jest doraźne. Nieudane odtworzenie może pozostawić dane w niespójnym stanie.

Timerise przyjmuje fundamentalnie inne podejście: replikacja odbywa się na poziomie bazy danych.

Serwer lokalny używa RxDB — reaktywnej bazy danych zaprojektowanej do replikacji w czasie rzeczywistym — zsynchronizowanej bezpośrednio z Firestore w chmurze. To nie jest cache API. To pełna dwukierunkowa replika bazy danych z wbudowanym rozwiązywaniem konfliktów.

Zalety są znaczące:

Szybkość — Dane replikują się jako dokumenty, nie jako serializowane cykle HTTP request-response. Brak narzutu REST, brak kolejek ponawiania, brak translacji middleware.
Spójność — Silnik bazy danych obsługuje rozwiązywanie konfliktów za pomocą znaczników czasu i rewizji dokumentów, nie kodu aplikacji. Każdy rekord ma jedno źródło prawdy.
Bezpieczeństwo — Replikacja używa uwierzytelnionych kanałów bazy danych z poświadczeniami konta serwisowego, nie eksponowanych endpointów API. Powierzchnia ataku jest mniejsza niż w warstwie synchronizacji opartej na API.
Kompletność — Wszystkie osiem kolekcji danych (lokalizacje, rezerwacje, magazyn, transakcje, zamki, logi zamków, cennik, personel) replikuje się jako jednostka. Nie ma ryzyka częściowej synchronizacji, gdzie rezerwacje się aktualizują, a magazyn nie.

Gdy połączenie wraca po okresie offline, lokalna instancja RxDB i chmurowy Firestore uzgadniają się automatycznie. Bez ręcznego scalania. Bez utraconych rekordów.

Kiosk i terminale obsługi

Tryb wyspowy zasila dwa typy terminali na miejscu, oba zbudowane jako Progressive Web Apps (PWA) działające w przeglądarce:

Kiosk samoobsługowy

Terminal z ekranem dotykowym, gdzie klienci rezerwują i meldują się bez pomocy obsługi. Kiosk działa w trybie pełnoekranowym na dedykowanym wyświetlaczu — bez paska adresu, bez interfejsu systemowego, bez rozpraszaczy. Obsługuje wiele języków, resetuje się automatycznie po okresie bezczynności i wyłącza wszystkie sposoby ucieczki z przeglądarki (prawy klik, pinch-zoom, nawigacja gestami).

W trybie wyspowym kiosk łączy się z serwerem lokalnym przez LAN i nadal pokazuje dostępne sloty, przyjmuje rezerwacje i przetwarza zameldowania. Klienci nie wiedzą, że internet nie działa.

Terminal obsługi

PWA dla pracowników do zarządzania codziennymi operacjami: przeglądanie dzisiejszych rezerwacji, meldowanie klientów, wydawanie i przyjmowanie inwentarza (broń, amunicja, sprzęt ochronny), sterowanie elektronicznymi zamkami i korekta stanów magazynowych. Personel uwierzytelnia się swoimi poświadczeniami — w trybie online weryfikowanymi przez chmurę, w trybie offline weryfikowanymi na podstawie lokalnej repliki danych personelu.

Terminal obsługi obejmuje operacyjny rdzeń lokalizacji: rezerwacje, magazyn i fizyczną kontrolę dostępu — wszystkie trzy działają w trybie wyspowym.

Przypadki użycia: gdzie tryb wyspowy będzie najbardziej przydatny

Strzelnice

Oryginalny przypadek użycia. Strzelnice łączą kilka czynników wrogich dla pracy online: gruba betonowa konstrukcja (tłumienie sygnału), wiejskie lokalizacje (słaby zasięg) i inwentarz wysokiego ryzyka (broń i amunicja, które muszą być śledzone precyzyjnie). Tryb wyspowy utrzymuje przepływ rezerwacji, księgę magazynową i elektroniczne zamki zbrojowni w działaniu niezależnie od łączności. Gdy internet wraca — czy to po minutach, czy pod koniec dnia — wszystkie dane synchronizują się z chmurą.

Pola paintballowe i airsoftowe

Zazwyczaj zlokalizowane w lasach, opuszczonych obiektach przemysłowych lub na otwartych polach. Infrastruktura jest minimalna. Internet często pochodzi z mobilnego hotspota, który traci sygnał, gdy zmienia się pogoda lub zbyt wiele telefonów się podłącza. Z trybem wyspowym kiosk do zameldowań przy wejściu dalej przetwarza grupy, personel śledzi wydanie i zwrot sprzętu, a operacja działa płynnie przez okno synchronizacji — poranny setup z internetem, offline w godzinach szczytu, wieczorna synchronizacja, gdy personel wraca do strefy biurowej.

Parki offroad i eventy rajdowe

Tymczasowe lub półstałe obiekty w odległym terenie. Łączność może być satelitarna z wysokim opóźnieniem i ograniczoną przepustowością, lub mobilny hotspot, który działa tylko ze wzgórza przy wjeździe. Tryb wyspowy jest zaprojektowany dokładnie pod ten scenariusz: replikuj wszystko podczas okna łączności, działaj autonomicznie podczas eventu, zsynchronizuj wyniki, gdy ekipa pakuje się i wraca w zasięg.

Bushcraft i eventy survivalowe

Wielodniowe wydarzenia w celowo odciętych od sieci lokalizacjach. Dostępność internetu może być ograniczona do 30-minutowego okna satelitarnego każdego ranka. Tryb wyspowy zamienia to okno w okazję do synchronizacji — serwer lokalny wypycha wszystkie nocne rezerwacje, logi sprzętu i rekordy dostępu do chmury, pobiera aktualizacje (nowy cennik, zmiany harmonogramu), a następnie działa niezależnie do następnego okna.

Jak synchronizacja działa w praktyce

Cykl życia typowego dnia w obiekcie terenowym z trybem wyspowym:

Poranny start — Serwer lokalny uruchamia się z maszyną (automatyczna usługa systemd). Łączy się z internetem i rozpoczyna replikację. W ciągu sekund wszystkie osiem kolekcji danych jest zsynchronizowanych z chmurą.
Rozpoczęcie operacji — Klienci przybywają. Kiosk i terminale obsługi łączą się przez API chmurowe, gdy internet jest dostępny. Serwer lokalny kontynuuje replikację w tle, utrzymując żywe lustro.
Internet pada — Heartbeat nie dochodzi. Po trzech kolejnych nieudanych heartbeatach (konfigurowalne) serwer lokalny przełącza się w tryb offline. Terminale wykrywają zmianę i przekierowują się na adres LAN serwera lokalnego. Operacje trwają bez przerwy.
Operacje wyspowe — Nowe rezerwacje tworzone są lokalnie. Ruchy magazynowe są rejestrowane. Polecenia zamków wykonują się. Wszystkie dane są przechowywane w lokalnej instancji RxDB z pełną spójnością.
Internet wraca — Serwer lokalny wykrywa łączność, wysyła heartbeat i rozpoczyna wypychanie lokalnie utworzonych danych do Firestore. Chmura oznacza lokalizację jako online. Terminale stopniowo migrują z powrotem do API chmurowego. Publiczna strona rezerwacji ponownie się aktywuje.
Koniec dnia — Wszystkie dane są spójne między lokalem a chmurą. Manager może przeglądać operacje dnia z dowolnego miejsca — każda rezerwacja, każda transakcja magazynowa, każde zdarzenie zamka jest w chmurze, niezależnie od tego, ile okresów offline wystąpiło.

Zbudowany dla prawdziwego świata

Tryb wyspowy to nie teoretyczne zabezpieczenie — to produkcyjna funkcjonalność zaprojektowana dla obiektów, gdzie praca offline to codzienność, nie przypadek brzegowy. Replikacja na poziomie bazy danych oznacza, że synchronizacja jest szybka, spójna i bezpieczna. Terminale PWA oznaczają brak natywnych aplikacji do instalacji czy aktualizacji. Automatyczne przełączanie oznacza, że personel nie musi naciskać żadnego przycisku ani dzwonić do IT.

Jeśli Twój obiekt działa tam, gdzie internet nie sięga, Timerise dalej pracuje.

Gotowy, żeby zabezpieczyć swoje operacje przed brakiem internetu? Skontaktuj się z nami, aby omówić wdrożenie trybu wyspowego dla Twojego obiektu, lub poznaj Timerise, żeby zobaczyć pełną platformę.