Kontakt z redakcją
Zachęcamy do współpracy. Jeśli masz ciekawy tekst i chcesz go u nas opublikować, napisz do nas. Chętnie go przeczytamy i odezwiemy się z odpowiedzią.
Dane z formularza wykorzystujemy wyłącznie do odpowiedzi na Twoją wiadomość.
Aplikacja webowa czy strona internetowa: gdzie przebiega granica
Granica między stroną internetową a aplikacją webową nie przebiega tam, gdzie większość osób jej szuka – nie decyduje o niej wygląd ani liczba podstron, tylko to, co dzieje się z danymi użytkownika między jedną wizytą a drugą. Ten tekst pokazuje, kiedy projekt faktycznie zmienia kategorię, co daje progresywna aplikacja webowa, a czego wciąż nie potrafi, oraz dlaczego to model danych, a nie interfejs, ustala ostateczny koszt budowy.
Gdzie faktycznie przebiega granica
Strona internetowa prezentuje treść: odwiedzający czyta, ogląda, ewentualnie wypełnia formularz kontaktowy, a serwer za każdym razem generuje odpowiedź na nowo, praktycznie bez pamięci o tym, co użytkownik robił wcześniej. Aplikacja webowa zarządza stanem: pamięta, w jakim miejscu procesu jest konkretny użytkownik, przechowuje jego dane między sesjami i pozwala mu na coś więcej niż odczyt, na przykład edycję, zapis, przetwarzanie.
Praktyczny test jest prosty: jeśli usunięcie połączenia z internetem w trakcie korzystania z serwisu oznacza tylko brak nowej treści, to jest strona. Jeśli oznacza utratę pracy, niespójny stan formularza albo błąd synchronizacji, mamy do czynienia z aplikacją, nawet jeśli wygląda jak zwykła witryna z menu i stopką. Sklep internetowy z koszykiem, panelem klienta i historią zamówień technicznie już jest aplikacją, choć potocznie nazywa się go stroną – o różnicach w podejściu do takich projektów pisaliśmy przy okazji platform sklepowych.
Drugi test dotyczy uprawnień i ról. Strona zwykle ma jeden poziom dostępu: publiczny. Aplikacja niemal zawsze ma więcej niż jeden – użytkownik zalogowany widzi inne dane niż gość, administrator ma inne możliwości niż zwykły użytkownik. Ten drugi test tłumaczy, dlaczego projekty „tylko trochę bardziej zaawansowane” potrafią eksplodować kosztowo – logika uprawnień mnoży liczbę przypadków, które trzeba przewidzieć i przetestować.
Trzeci test, mniej oczywisty, dotyczy tego, co się dzieje, gdy dwie osoby próbują skorzystać z tego samego zasobu jednocześnie. Strona nie ma tego problemu, bo nie ma współdzielonego zasobu – każdy odwiedzający dostaje tę samą treść niezależnie od innych. Aplikacja musi rozstrzygać konflikty: kto pierwszy zarezerwował ostatni termin, co się stanie, gdy dwóch administratorów edytuje ten sam rekord jednocześnie, jak system ma się zachować, gdy zapytania nakładają się w czasie. Ten problem nie znika wraz z wyborem prostszej technologii, jest wpisany w samą naturę systemu, który zarządza wspólnym stanem dla wielu użytkowników naraz.
Co daje PWA, a czego nie da
Progresywna aplikacja webowa (PWA) to zestaw technologii przeglądarkowych, głównie service worker i plik manifestu, które pozwalają stronie zachowywać się bardziej jak aplikacja natywna: działać offline dla wcześniej odwiedzonych zasobów, wysyłać powiadomienia push, dodać ikonę na ekranie głównym telefonu bez przechodzenia przez sklep z aplikacjami.
To, co PWA rzeczywiście daje, to możliwość cache’owania zasobów i danych po stronie klienta, dzięki czemu aplikacja startuje szybciej przy kolejnej wizycie i może pokazać ostatnio załadowane dane nawet bez połączenia. Daje też jeden kod źródłowy zamiast osobnej aplikacji na Androida i iOS, co obniża koszt utrzymania przy prostszych przypadkach użycia.
To, czego PWA nie daje, jest równie istotne. Dostęp do części sprzętu telefonu wciąż jest ograniczony w porównaniu z aplikacją natywną – integracja z niektórymi czujnikami, głębsza integracja z systemem plików czy stabilna praca w tle poza aktywną kartą przeglądarki są słabsze niż w aplikacji ze sklepu Apple czy Google. Na iOS wsparcie dla powiadomień push i niektórych API PWA historycznie było opóźnione względem Androida i bywa bardziej ograniczone, więc projekt zakładający równorzędne działanie na obu platformach powinien to uwzględnić na etapie planowania, nie po wdrożeniu.
Przypadek offline i tryb kioskowy
Tryb offline i tryb kioskowy to dwa różne problemy, które często są mylone, bo oba kojarzą się z „aplikacją działającą bez nadzoru”.
Offline oznacza, że aplikacja musi działać sensownie bez połączenia z siecią przez dłuższy czas, nie tylko przez chwilę przerwy. To wymaga strategii synchronizacji: co się dzieje, gdy dwóch użytkowników zmieni te same dane offline i połączenie wróci jednocześnie u obu. Bez przemyślanej strategii konfliktów aplikacja offline po prostu nadpisuje dane losowo w kolejności powrotu połączenia, co w praktyce oznacza utratę pracy użytkownika bez ostrzeżenia.
Tryb kioskowy to inny scenariusz: urządzenie stoi w miejscu publicznym, uruchamia jedną aplikację w pełnym ekranie, bez paska przeglądarki i bez możliwości wyjścia do innych stron przez zwykłego użytkownika. Wymaga to zablokowania nawigacji przeglądarki, obsługi bezczynności (powrót do ekranu startowego po określonym czasie bez interakcji), odporności na przypadkowe gesty oraz mechanizmu zdalnego restartu, gdy urządzenie się zawiesi, bo nikt nie będzie go restartował ręcznie w środku nocy w pustej galerii handlowej. To zupełnie inny zestaw wymagań niż offline i zwykle wymaga osobnej warstwy konfiguracji urządzenia, nie tylko kodu aplikacji.
Do trybu kioskowego dochodzi jeszcze zagadnienie, które łatwo pominąć na etapie planowania: kto i jak aktualizuje treść na urządzeniu, które fizycznie stoi w oddalonej lokalizacji. Aplikacja kioskowa dobrze zaprojektowana pobiera nową treść automatycznie z centralnego źródła, bez potrzeby fizycznego dostępu do urządzenia, a mechanizm ten musi działać odpornie na chwilowy brak połączenia, nie zawieszając całej aplikacji, gdy sieć akurat nie odpowiada. Brak takiego mechanizmu oznacza, że każda zmiana treści wymaga wysłania kogoś na miejsce, co w praktyce czyni z wielu wdrożonych kiosków projekty statyczne mimo technicznej możliwości aktualizacji zdalnej.
Dlaczego model danych, nie interfejs, ustala koszt
Wycena projektu aplikacji webowej bywa robiona na podstawie liczby ekranów i przycisków, a to najmniej kosztowna część pracy. Prawdziwy koszt siedzi w modelu danych: w tym, jakie encje istnieją w systemie, jak się do siebie odnoszą i co się dzieje, gdy jedna z nich się zmienia.
- Prosty formularz kontaktowy ma jeden model danych: zgłoszenie, bez relacji do niczego innego. Koszt implementacji jest niski niezależnie od tego, jak skomplikowany wizualnie jest interfejs.
- System rezerwacji ma już kilka powiązanych encji: użytkownik, termin, zasób, płatność – a każda zmiana jednej z nich (na przykład anulowanie rezerwacji) musi poprawnie zaktualizować pozostałe, inaczej system pokaże sprzeczne dane różnym użytkownikom.
- Aplikacja z rolami i uprawnieniami dodaje kolejną warstwę: te same dane muszą być widoczne inaczej w zależności od tego, kto pyta, co mnoży liczbę przypadków testowych, nawet jeśli interfejs wygląda identycznie dla każdej roli.
Dlatego dwa projekty o wizualnie identycznym interfejsie mogą różnić się kosztem budowy kilkukrotnie – różnicę robi to, co dzieje się pod spodem, gdy dane się zmieniają, a nie to, co widać na ekranie. Dobra wycena projektu aplikacji zaczyna się od narysowania modelu danych, nie od makiety ekranów, bo to model danych, a nie warstwa graficzna, decyduje, ile pracy programistycznej faktycznie potrzeba.
Jak to przekłada się na decyzję projektową
Zanim padnie pytanie „strona czy aplikacja”, warto zadać inne: czy system musi pamiętać stan użytkownika między wizytami, czy różni użytkownicy mają widzieć różne dane, i czy praca ma przetrwać brak połączenia z internetem. Odpowiedź twierdząca na którekolwiek z tych pytań przesuwa projekt w stronę aplikacji, niezależnie od tego, jak prosty wydaje się interfejs na etapie pierwszych szkiców.
Warto też zapytać, co się stanie za rok, gdy przybędzie nowa funkcja, której dziś nikt nie planuje. Aplikacja z dobrze przemyślanym modelem danych przyjmuje nowe wymagania jako rozszerzenie istniejącej struktury. Aplikacja, w której model danych powstał przypadkiem, jako efekt uboczny kolejnych ekranów dodawanych pod presją terminu, każda nowa funkcja wymaga przebudowy fragmentu systemu, który miał już nigdy się nie zmieniać. Ta różnica nie widać w dniu wdrożenia, widać ją dopiero przy drugiej albo trzeciej rundzie rozwoju produktu, i to ona najczęściej rozstrzyga, czy aplikacja da się rozwijać dalej, czy trzeba ją zbudować od nowa.
