REST API dla aplikacji webowych i mobilnych
API określa, jakie dane i operacje udostępnia backend. Projektujemy komunikację aplikacja mobilna ↔ API, uwzględniając walidację danych, autoryzację oraz obsługę błędów.
W ZEiT backend Laravel obsługuje sklep, panel administracyjny i API dla Fluttera. Dzięki temu aplikacja mobilna jest częścią systemu sprzedaży, a dane przechowuje PostgreSQL.
Integracje biznesowe i zadania w tle
Łączymy aplikacje z systemami zewnętrznymi przez API. Zakres integracji wynika z procesu biznesowego: ustalamy, które dane mają być wymieniane i kiedy dana operacja powinna się wykonać.
PostgreSQL odpowiada za trwałe przechowywanie danych. Redis wykorzystujemy do cache lub kolejek, kiedy zadanie powinno działać w tle. Kolejki Redis są częścią zaplecza aplikacji Spontan.
Komunikacja w czasie rzeczywistym
Nie każda funkcja powinna czekać na ponowne pobranie danych. W Spontan Laravel Reverb wspiera czat w czasie rzeczywistym, łącząc backend z aplikacją Flutter.
WebSockets dobieramy do funkcji wymagających bieżącej komunikacji. Pozostałe operacje mogą korzystać z REST API — sposób komunikacji wynika z potrzeb konkretnego ekranu i procesu.
Kiedy aplikacja potrzebuje własnego backendu?
Backend jest potrzebny, gdy dane mają być współdzielone między urządzeniami, użytkownikami lub aplikacją webową i mobilną. To po stronie serwera egzekwuje się role i uprawnienia, przetwarza integracje oraz wykonuje operacje w tle. Komunikacja realtime może uzupełniać taki system, jeśli wymaga tego funkcja produktu.
Własny backend nie jest obowiązkowy dla każdej aplikacji. Narzędzie działające wyłącznie na urządzeniu może go nie potrzebować, a część potrzeb obsłuży gotowa usługa. Decyzję warto oprzeć na modelu danych, regułach dostępu i zakresie integracji.
Rozwój i przejęcie istniejącego API
Przed zmianami sprawdzamy kontrakty API i wersje aplikacji, które z nich korzystają. Przegląd obejmuje autoryzację, bazę danych, kolejki, logi i monitoring oraz sposób wdrażania. Zmiana pola lub znaczenia błędu może wpłynąć na starszą aplikację, której użytkownik jeszcze nie zaktualizował.
Ustalamy testy zgodności, kolejność wdrożenia i sposób wycofania zmiany. Nowe zachowanie wprowadzamy etapami, z obserwacją błędów i czasu odpowiedzi, zamiast zakładać, że wszyscy klienci API przejdą na nową wersję jednocześnie.
