♾️🛢️W jaki sposób zorganizować pracę backend - frontend🛢️♾️

Cześć, w tym artykule przedstawię z punktu widzenia frontendowca, w jaki sposób można zorganizować połączenie front-endu z backendem. W planach jest stały rozwój artykułu, sugestie - w komentarzach - są mile widziane.

Jedno repozytorium

Często stosowane w małych, izolowanych projektach. Zwykle frontend aplikacji znajduje się wtedy jako wewnętrzny projekt Web w aplikacji backendowej. Frontend wykonuje requesty do wystawionego API, a wszelkie zmiany i poprawki można wprowadzać na bieżąco. Uruchomienie aplikacji backendowej jest proste, nie wymaga konfiguracji wielu systemów.

W kilku projektach spotkałem się z generowaniem kodu na podstawie Open API. Można generować zarówno interfejsy TS, serwisy frontendowe jak i całe fragmenty GUI. 

Problemy pojawiają się wtedy, gdy na przykład backend korzysta z innych serwisów które są trudne w konfiguracji lub płatne, albo jest ich po prostu dużo.

Wiele repozytoriów, skomplikowana struktura backendu

Sprawy komplikują się w przypadku aplikacji która ma rozbudowany backend, składający się na przykład z wielu mikroserwisów rozwijanych przez osobne teamy. Opcje połączenia frontu z backendem są wtedy następujące:

• Żmudne stawianie całego "majdanu" backendowego, czyli wszystkich zależności. Nie lubię tego rozwiązania, szczególnie gdy do uruchomienia konieczne jest kilka aplikacji (i kilka instancji IDE) oraz ciągłe przełączanie się między wieloma branchami różnych programów. Czasem wymaga to też używania kilku różnych VPNów. 
  
• Postawienie serwera serwującego i przyjmującego mocki dla frontu. Spotkałem się zarówno z rozwiązaniem gdy taki serwer był prostą aplikacją w Node.js (na przykład node-mock-server) rozwijaną przez frontendowców, jak i w Javie i wtedy troszczyli się o niego backendowcy. Nie ma dużej różnicy, ponieważ taki projekt jest prosty - przyjmuje requesty i serwuje JSONy. Serwowane pliki mogą być zarówno generowane na podstawie Swaggera, jak i tworzone ręcznie.
  Minusem takiego rozwiązania jest dodatkowa praca przy tworzeniu mocków, plusem natomiast to, że pozwala na pracę gdy nie ma jeszcze danych testowych w bazie. Pracując w ten sposób możesz też łatwo przełączać się między różnymi typami odpowiedzi.
  
• Używanie aplikacji która mockuje dane dla backendu. Backend do którego uderza front, zamiast łączyć się do mikrosystemów, lokalnie łączy się z fejkowym serwerem i serwuje dane. To rozwiązanie moim zdaniem jest gorsze niż mockowanie danych tylko dla frontu, ponieważ wymaga przełączania się między dodatkowymi dwoma aplikacjami backendowymi. Z drugiej strony, aplikacja backendowa może agregować dane mockowane na różne sposoby, np. z Soap.ui.
  
• Mockowanie danych jedynie na froncie aplikacji. Flow wygląda tak - na podstawie Open API generujemy mocki i wrzucamy je w aplikację frontendową. Na podstawie zmiennej środowiskowej ustawiamy czy aplikacja ma wykorzystywać mocki czy wykonywać prawdziwe requesty. Minusem jest to, że nie widzimy do jakiego endpointu wykonywane są requesty lokalnie.
  Moim zdaniem, mało czytelne rozwiązanie, dodające niepotrzebnego kodu.
  
• Wykonywanie requestów do wystawionego serwera testowego. W takiej sytuacji frontend musi zaczekać na wystawienie aplikacji backendowej, ale nie trzeba nic konfigurować.
   

Aplikacje z biegiem czasu ewoluują, od prostego jednego frontendu podłączonego do jednego backendu, do nawet wielu backendów z którymi łączy się wiele frontendów. Rozwiązanie które wybierzemy do komunikacji między frontem a backendem powinno być proste w obsłudze i łatwe w rozwoju dla każdego członka zespołu.