Aplikacja mobilna i część serwerowa od jednego partnera. Jak uniknąć przerzucania odpowiedzialności między aplikacją, serwerem i połączeniami z systemami

Jeden partner jest najlepszym modelem, gdy aplikacja mobilna zależy od specyficznych reguł w części serwerowej: lojalności, cen, promocji, zamówień, statusów, uprawnień, trybu pracy bez internetu, powiadomień, obsługi zwrotów, płatności lub danych z systemów firmowych. Wtedy jakość produktu zależy od tego, czy aplikacja i część serwerowa projektują tę samą ścieżkę użytkownika, a nie dwie oddzielne listy zadań.

Model rozdzielony nadal może działać, jeśli część serwerowa jest gotową, stabilną platformą z dobrze opisanymi zasadami wymiany danych, a aplikacja jest głównie warstwą prezentacji. Przykład: prosty katalog treści, aplikacja wydarzeniowa, wewnętrzny formularz bez krytycznych połączeń z systemami albo produkt, w którym klient ma bardzo dojrzały zespół utrzymujący platformę i realnie pilnuje zasad wymiany danych między systemami.

W praktyce granicą decyzyjną nie jest “czy mamy zaplecze”, tylko “ile zmian w części serwerowej będzie wymuszać aplikacja”. Jeśli każda kolejna wersja aplikacji generuje pytania o punkty połączenia, statusy, przypadki brzegowe, format danych, pamięć podręczną, ponawianie prób i uprawnienia, dwa osobne zespoły stają się drogim mechanizmem przerzucania odpowiedzialności.

• Wybierz jednego partnera, gdy aplikacja wpływa na przychód, powroty klientów, działania operacyjne, logistykę, płatności lub obsługę klienta.
• Rozdziel zespoły tylko wtedy, gdy zasady wymiany danych między aplikacją a częścią serwerową są stabilne, właściciel platformy jest dostępny, a zmiany po stronie serwera nie blokują wydania aplikacji.
• Nie wybieraj jednego partnera wyłącznie dlatego, że “będzie prościej”. Wybierz go, gdy potrafi zaprojektować, zbudować i utrzymać architekturę, doświadczenie użytkownika, część serwerową, aplikację, testy i publikację.

Dobra aplikacja mobilna ma widoczny interfejs i niewidoczne zaplecze operacyjne. Użytkownik widzi logowanie, koszyk, status zamówienia, skaner, powiadomienie albo formularz. Firma widzi zamówienie w systemie finansowo-magazynowym, aktualny stan magazynu, zgłoszenie w narzędziu obsługi klienta, zdarzenie w analityce i ostrzeżenie, jeśli coś przestaje działać.

W modelu jednego partnera te elementy nie są oddzielnymi małymi projektami. Tworzą jedną odpowiedzialność. Ten sam zespół produktowy ustala, jak aplikacja zachowa się przy wolnej odpowiedzi z części serwerowej, jak długo przechowywać dane lokalnie, co zrobić przy podwójnej płatności, jak oznaczyć zdarzenia w analityce i co zobaczy obsługa klienta, kiedy użytkownik zgłosi problem.

To właśnie tu powstaje przewaga nad zwykłym “zrobimy aplikację”. Silna firma produktowo-techniczna nie kończy na ekranach. Projektuje system, który można uruchomić, mierzyć, utrzymać i rozwijać bez polowania na winnego po każdej awarii.

Najczęstszy błąd w projektach łączących aplikację i część serwerową polega na tym, że sposób komunikacji traktuje się jak listę adresów URL. Tymczasem aplikacja potrzebuje pełnych zasad współpracy z częścią serwerową: statusów, błędów, formatów dat, walut, pól opcjonalnych, wersjonowania, stronicowania list, limitów, reguł ponawiania, zabezpieczeń przed podwójnym wykonaniem operacji, uprawnień i zachowania przy częściowej awarii.

OpenAPI opisuje połączenia HTTP w sposób niezależny od języka programowania, tak aby ludzie i narzędzia mogły zrozumieć możliwości usługi bez czytania kodu źródłowego. Dla produktu mobilnego to nie jest formalność. To podstawa tworzenia kodu łączącego aplikację z częścią serwerową, testów zgodności, dokumentacji dla kontroli jakości i rozmowy z zespołem utrzymującym system po starcie.

W GMI projektujemy takie zasady przed lub w trakcie rozpoznania biznesu, projektu i technologii. Przy projektach React Native plus NestJS często korzystamy z TypeScript w całej ścieżce, walidacji danych przesyłanych między aplikacją a częścią serwerową, OpenAPI, testów zgodności i wspólnych typów danych tam, gdzie ma to sens. Celem nie jest “ładna dokumentacja”. Celem jest to, żeby zmiana po stronie serwera nie psuła aplikacji dopiero na telefonie klienta.

W aplikacjach mobilnych często pojawia się pytanie, czy budować osobną warstwę serwerową dopasowaną do aplikacji. Microsoft opisuje taki wzorzec jako przydatny wtedy, gdy ogólna część serwerowa wymaga dużego nakładu utrzymania albo trzeba zoptymalizować ją pod wymagania konkretnego interfejsu. To ważne: nie jest to automatyczny dodatek do każdej aplikacji.

Dla aplikacji mobilnej taka osobna warstwa ma sens, gdy telefon potrzebuje innych zestawów danych niż strona internetowa, ma inne ograniczenia sieciowe, obsługuje tryb pracy bez internetu, powiadomienia, biometrię, linki prowadzące do konkretnych miejsc w aplikacji albo specyficzny przebieg płatności. Nie powinna jednak stawać się drugim miejscem na reguły biznesowe. Jeśli logika cen, statusów i uprawnień zaczyna żyć w tej warstwie, dług techniczny rośnie bardzo szybko.

Jeden partner pomaga, bo zespół może uczciwie dobrać wzorzec: prosty REST, GraphQL, osobną warstwę dla aplikacji, bramę dla połączeń z systemami, kolejki zdarzeń albo kombinację tych elementów. Przy dwóch osobnych dostawcach wzorzec bywa wynikiem polityki odpowiedzialności: “dodajmy kolejną warstwę, żeby nikt nie musiał zmieniać swojego systemu”.

React Native pozwala tworzyć natywne aplikacje na Androida, iOS i inne platformy z wykorzystaniem Reacta. Expo dodaje do tego narzędzia do budowania aplikacji, wysyłki do sklepów, aktualizacji, hostingu, metadanych, danych analitycznych i wglądu w działanie aplikacji. To skraca drogę do publikacji, ale nie usuwa odpowiedzialności za zgodność aplikacji z częścią serwerową.

Aplikacja mobilna różni się od strony internetowej tym, że stare wersje zostają na telefonach użytkowników. Jeśli część serwerowa zmieni zasady komunikacji zbyt agresywnie, część klientów nadal będzie używać starej aplikacji z nowymi zasadami wymiany danych. Dlatego plan wydań musi obejmować wersjonowanie punktów połączenia, przełączniki funkcji, wymuszanie aktualizacji, migracje danych, plan powrotu do poprzedniej wersji i obserwowanie działania według wersji aplikacji.

GMI łączy React Native z narzędziami Expo, NestJS, PostgreSQL oraz połączeniami z systemami firmy w jeden plan publikacji i utrzymania. Nie chodzi tylko o to, żeby “wrzucić aplikację do sklepów”. Chodzi o to, żeby zespół wiedział, które wersje aplikacji są aktywne, jakie błędy rosną po wydaniu, czy część serwerowa odpowiada w czasie akceptowalnym dla aplikacji mobilnej i kiedy można bezpiecznie wycofać stare zasady wymiany danych.

Apple w wytycznych recenzji App Store wymaga, żeby aplikacje wysyłane do recenzji były finalne, przetestowane na urządzeniu, bez zaślepek, z działającymi adresami URL, kontem demo lub trybem demo, a aplikacje z awariami albo oczywistymi problemami technicznymi mogą zostać odrzucone. To oznacza, że część serwerowa nie jest “poza zakresem aplikacji mobilnej”. Jeśli nie działa podczas recenzji, problem staje się problemem całego wydania.

Google Play mierzy kluczowe wskaźniki jakości Androida, w tym awarie widoczne dla użytkownika, zacięcia aplikacji bez odpowiedzi i blokady wybudzenia urządzenia. Google wskazuje, że te wskaźniki wpływają na widoczność aplikacji w Google Play, a przekroczenie progów może skutkować niższą widocznością albo ostrzeżeniem na stronie aplikacji. Dla zarządu to nie jest techniczny detal. To ryzyko dystrybucji, pozyskiwania klientów i reputacji.

Dlatego jeden partner powinien brać odpowiedzialność za testy na urządzeniach, konta demo, stabilność części serwerowej podczas recenzji, raportowanie awarii, zacięcia aplikacji bez odpowiedzi, zapisy zdarzeń, stronę statusu, ostrzeżenia i proces szybkich poprawek. Jeśli te tematy są rozrzucone między dostawcami, firma odkrywa problem dopiero wtedy, gdy wydanie stoi w kolejce albo ocena aplikacji zaczyna spadać.

Najlepszy model jednego partnera nie polega na tym, że wszyscy siedzą w jednym komunikatorze. Polega na tym, że aplikacja, część serwerowa, kontrola jakości, projektowanie doświadczenia użytkownika i prowadzenie produktu pracują na jednej definicji ukończenia. Funkcja nie jest gotowa, gdy ekran wygląda dobrze. Jest gotowa, gdy część serwerowa obsługuje przypadki brzegowe, testy przechodzą, analityka działa, obsługa klienta wie, co zobaczy użytkownik, a publikacja ma plan powrotu do poprzedniej wersji.

Podczas rozpoznania biznesu, projektu i technologii warto spisać materiały, które później chronią budżet: mapę procesów, architekturę logiczną, zasady wymiany danych między aplikacją a częścią serwerową, listę połączeń z systemami, model uprawnień, makiety ekranów, scenariusze testowe, wymagania sklepów z aplikacjami, model danych, plan migracji i kryteria akceptacji. Dopiero taki materiał pozwala porównać oferty dostawców sensownie, a nie po samej stawce godzinowej.

Jeśli dostawca nie potrafi pokazać, jak zarządza decyzjami między aplikacją i częścią serwerową, prawdopodobnie sprzedaje “zasoby”, a nie odpowiedzialność za produkt. To jest inny zakup i inne ryzyko.

GMI zaczyna od rozpoznania biznesu, projektu i technologii. W tej fazie ustalamy cele biznesowe, użytkowników, kluczowe procesy, połączenia z systemami, model danych, ryzyka, doświadczenie użytkownika i architekturę. Dopiero po tym etapie można odpowiedzialnie powiedzieć, czy zakres nadaje się na stałą cenę, co powinno wejść do pierwszej wersji, a co powinno poczekać.

Dla typowego projektu aplikacji z częścią serwerową zespół obejmuje prowadzenie produktu, projektowanie doświadczenia użytkownika i interfejsu, lidera technicznego, React Native z Expo, NestJS/Node.js, kontrolę jakości oraz prace infrastrukturalne i chmurowe w zakresie potrzebnym do produktu. W handlu dochodzi MedusaJS, system finansowo-magazynowy, baza produktów, system magazynowy, płatności, promocje, lojalność i analityka. W aplikacjach operacyjnych dochodzą role, uprawnienia, tryb pracy bez internetu, synchronizacja i obsługa urządzeń terenowych.

Klient dostaje nie tylko aplikację. Dostaje kod źródłowy, dokumentację decyzji, model utrzymania, wgląd w działanie systemu, wiedzę o połączeniach z systemami i możliwość dalszego rozwoju bez uzależnienia od dostawcy. To jest istotne szczególnie dla firm, które chcą budować własny kanał sprzedaży, aplikację lojalnościową, narzędzie operacyjne albo system sprzedaży firmowej, a nie jednorazową kampanię.