Moim zdaniem warto, jestem wielkim zwolennikiem jasnego rozdziału na client-side jako SPA i API jako pojedyncze endpointy. Rozwiązanie takie ma wiele zalet i wydaje mi się, że w porównaniu do "tradycyjnych" monolitów to nie ma tu w ogóle żadnych argumentów za monolitem.
Z takich najważniejszych zalet to:
- masz jasny rozdział front/API, można w ogóle zrobić sobie osobne repozytoria i wtedy zespół frontowy i backendowy w ogóle nie wchodzą sobie w paradę. Tak naprawdę w niektorych zmianach druga strona w ogóle nie musi o nich wiedzieć, choć raczej częściej dotyczy to zmian wizualnych na froncie, bo zmiany w API często jednak wymagają pewnych modyfikacji client-side, jakieś zmiany obsługi błędów itp.
- Znacznie latwiej zarządzać wg mnie monitoringiem takich aplikacji, co wg mnie powinno być jednym z priorytetów.
- po za samym core kodu to również testy są zupełnie niezależne
- no i rzecz bardzo istotna, front i API są rozdzielone i frontu kompletnie nie interesuje w jakiej technologii jest API i odwrotnie. API wystawia tylko konkretne endpointy, np. PUT z jakimś requestBody i front musi po prostu strzelić na ten endpoint. Nie ma natomiast kompletnie znaczenia czy API jest w Javie, PHP, node itp. oraz czy front jest w React, Angular itp. Daje też to możliwość migracji technologii w sposób niezależny. Jest to bardzo istotne, bo znacznie szybciej jest zmigrować np. jedną mikroaplikację kliencką z React na Angular niż migrować wszystkie mikroapki SPA od razu + backend jeśli ktoś korzystałby z systemu szablonów serwerowych itp.
- SPA daje możliwość lepszej pracy dla usera, zaczytuje on apkę raz (jak trzeba to można dodać lazy loading modułów) i potem tylko strzela do API. Nie ma ciągłego przeładowywania stron jak w monolitach.
Wiele osób zarzuca apkom SPA problemy z SEO co jest bzdurą, jak jest to istotne to po prostu dodaje się server side rendering i po sprawie. A ponad to google coraz lepiej sobie radzi z wykonywaniem JS i nawet jest w stanie pomalutku czytac sobie SPA bez SSR.
Ponad to w SPA jest znacznie przyjemniejsza obsługa wymiany danych między komponentami frontowymi. Na przykład podciągając rxjs (w Angular jest by default) możesz pracować w stylu reaktywnym co jest po prostu bajką, a w Angular masz by default dostępne reactive forms itp.
No i jeszcze jedna sprawa, mam wrażenie, że często pomijana przez ludzi na tym forum, mając samodzielny front znacznie łatwiej pozyskać z rynku ludzi wyspecjalizowanych typowo we froncie niż tzw. full stacków. I nie ma tu znaczenia czy ktoś pracuje w React, Angular itp. bo przemigrowanie się na inny framework to chwila. Na back-endzie natomiast mamy wtedy specjalistów stricte w języku serwerowym, np. Javie, PHP itp.
I na koniec, również kwestia rzadko tutaj poruszana, a cholernie istotna, to mając niezależne apki znacznie łatwiej jest reagować na awarie. Wszelkie szybkie fixy, restarty instancji, dodawanie pamięci itp. są prostsze jak mamy wiele mniejszych klocków niż jeden monolit.
Także podsumowując to szczerze mówiąc nie widzę żadnych zalet monolitu nad SPA+API. Oczywiście mówimy tu o normalnych aplikacjach, nie o prostych stronkach z kilkoma-kilkonastoma podstronami itp. bo tu owszem można sobie spokojnie brać monolity i gotowce np. WP itp. Moja wypowiedź dotyczy aplikacji.
