Backend / API
Jak zaplanować backend i API dla aplikacji mobilnej?
Backend dla aplikacji mobilnej musi obsługiwać klientów, których nie da się zaktualizować jednym wdrożeniem. Dlatego kontrakt API, uprawnienia i zgodność wersji warto zaplanować razem z funkcjami produktu.
1. Zacznij od danych i odpowiedzialności
Rozpisz, kto tworzy dane, kto może je zmieniać i co jest wspólne dla aplikacji webowej oraz mobilnej. Oddziel stan interfejsu od danych, których źródłem prawdy jest serwer. Zdecyduj, jak aplikacja rozpoznaje konflikt, gdy dwie osoby zmienią ten sam rekord.
Publiczny opis realizacji ZEiT pokazuje sklep, panel administracyjny i aplikację Flutter korzystającą z API Laravel. Taki układ wymaga spójnych reguł po stronie backendu; nie wystarczy powtórzyć walidacji w każdym interfejsie.
2. Ustal kontrakt REST API i obsługę błędów
Zdefiniuj zasoby, operacje, formaty danych, paginację i daty. Opisz pola opcjonalne oraz różnicę między brakiem wartości a pustą listą. Kontrakt powinien być czytelny dla obu zespołów i możliwy do sprawdzenia testem, niezależnie od wybranej formy dokumentacji.
Błąd walidacji, brak logowania, brak uprawnień i niedostępność integracji wymagają różnych reakcji aplikacji. Ustal statusy HTTP, stabilne kody błędów i identyfikator żądania do diagnostyki. Komunikat dla człowieka może się zmienić lub zostać przetłumaczony; klient nie powinien sterować logiką na podstawie jego dokładnego brzmienia.
3. Rozdziel uwierzytelnianie od uprawnień
Token albo sesja pozwala rozpoznać użytkownika, ale nie rozstrzyga, do których danych ma dostęp. Każda operacja na zasobie powinna sprawdzać uprawnienia po stronie serwera. Ukrycie przycisku lub identyfikatora w aplikacji nie jest zabezpieczeniem.
Zaplanuj wygaśnięcie i unieważnienie tokenów, wylogowanie pojedynczego urządzenia oraz reakcję na utratę dostępu do konta. Dobierz mechanizm sesji lub tokenów do klienta. Dodaj ograniczenia liczby żądań i logowanie zdarzeń bezpieczeństwa bez zapisywania haseł oraz pełnych tokenów w logach.
4. Uwzględnij słabą sieć i ponawianie operacji
Telefon może utracić połączenie po zapisaniu danych na serwerze, zanim otrzyma odpowiedź. Sam timeout nie oznacza, że operacja się nie udała. Dla istotnych zapisów zaplanuj identyfikator operacji i bezpieczne ponowienie, aby klient nie tworzył duplikatów.
Przy uploadzie ustal limity wielkości, dozwolone typy, uprawnienia do plików i sposób potwierdzenia zakończenia. Dłuższe przetwarzanie może działać w kolejce, a API zwracać stan zadania. Warto przewidzieć usuwanie nieukończonych plików i obsługę błędu po przerwaniu transmisji.
5. Rozdziel kolejki, push i komunikację realtime
Kolejka pomaga wykonać zadanie poza czasem żądania HTTP, lecz wymaga monitorowania opóźnień, ponowień i nieudanych zadań. Ustal, które operacje można powtarzać, jak wykrywać duplikaty i kiedy potrzebna jest interwencja zamiast kolejnej próby.
Push służy do powiadomienia urządzenia, a WebSockets do bieżącej komunikacji z połączonym klientem. Żaden z tych kanałów nie powinien być jedynym miejscem przechowywania ważnego stanu. Po ponownym połączeniu aplikacja powinna umieć pobrać aktualne dane z API.
W Spontan publicznie opisany stack obejmuje Laravel Reverb, kolejki Redis i aplikację Flutter. To przykład rozdzielenia komunikacji czatu od pozostałych operacji backendu.
6. Zaplanuj cache i awarie integracji
Cache może ograniczyć koszt odczytu, ale najpierw określ dopuszczalną nieaktualność danych i sposób ich unieważniania. Klucze muszą uwzględniać kontekst dostępu; dane jednego użytkownika nie mogą trafić do odpowiedzi dla innego.
Każda integracja zewnętrzna może zwolnić lub przestać odpowiadać. Ustal timeout, zasady ponawiania, obsługę webhooków i stan widoczny dla użytkownika. Gdy część procesu zakończy się sukcesem, a część błędem, potrzebny jest sposób uzgodnienia stanu zamiast zgadywania, czy wszystko należy uruchomić jeszcze raz.
7. Zachowaj zgodność ze starszymi wersjami aplikacji
Nowa wersja w sklepie nie trafia od razu do wszystkich użytkowników. Unikaj usuwania pól i zmiany ich znaczenia bez planu migracji. Numer wersji API porządkuje komunikację, ale sam nie zapewnia kompatybilności. Testuj odpowiedzi także z wersją klienta, która pozostaje w użyciu.
Zaplanuj kolejność wdrożeń, okres współistnienia zachowań i warunki zakończenia wsparcia starego klienta. Obserwuj błędy, czas odpowiedzi i zaległości kolejek. Nie deklaruj bezpiecznego rollbacku, dopóki nie wiadomo, jak nowy zapis danych zachowa się po przywróceniu starszego kodu.
Co powinno powstać przed implementacją?
Na start wystarczy wspólny model danych, lista operacji i uprawnień, przykładowe odpowiedzi, scenariusze błędów oraz plan integracji i wdrożenia. Szczegóły rozwija się wraz z produktem, ale niejasności dotyczące własności danych i zgodności wersji warto rozstrzygnąć wcześniej.
Te decyzje łączą zakres backendu, API i integracji z wymaganiami aplikacji mobilnej Flutter.
Dokumentacja do dalszej pracy
Instrukcje wdrożeniowe dobierz do wersji używanej w swoim projekcie. Poniższe źródła rozwijają opisane zagadnienia.