Załóżmy, że mam interfejs, który jest w większości jednostronicową aplikacją napisaną za pomocą kątownika, pomruku i altany. Przypuśćmy, że mam backend, który jest w większości po prostu interfejsem API REST umieszczonym na ORM, który przechowuje / pobiera obiekty z bazy danych, używając takich funkcji, jak chrząknięcie, ekspresowe i sekwencjonowanie.
Aplikacja kątowa wykonuje wszystkie wizualne rzeczy, które widzi użytkownik, ale robi to, będąc graficznym interfejsem użytkownika w stosunku do usług świadczonych przez back-end.
Pożądane byłoby podzielenie ich na dwie różne bazy kodowe, aby umożliwić niezależny rozwój, wersjonowanie, ciągłą integrację, usprawnianie itp.
Moje pytanie brzmi: jakie są dostępne metody robienia tego w czysty sposób? Czy są zalecane najlepsze praktyki dotyczące javascript z pełnym stosem?
Opcja nr 1 wydaje się być monolitem, tzn. „Nie rozdzielaj ich”. Zaletą jest to, że łańcuch kompilacji jest prosty i wszystko jest w jednym miejscu - ale wydaje się, że istnieje wiele wad; trudniejsza do samodzielnej wersji, zepsuty przód oznacza nierozkładalny tył i tak dalej.
Opcja nr 2 wydaje się quasi-monolitem, w którym łańcuch kompilacji frontonu powoduje zapisanie kilku plików na zapleczu. distKatalog na front-end będzie odnosić się do jakiegoś katalogu na back-end, więc zasadniczo, gdy przednie minifies końcowe, uglifies, etc, to kończy się publikowania na back-end, czyli wszystko.
Opcja nr 3 wydaje się być całkowicie oddzielna: front-end i back-end uruchamiają własne serwery na różnych portach i są to w pełni osobne projekty. Wadą wydaje się, że muszą być skonfigurowane tak, aby wiedzieć o swoich portach; back-end musi zezwalać na CORS z frontonu, a front-end musi wiedzieć, gdzie powinny się znajdować wszystkie te punkty końcowe.
Opcją # 4 może być użycie czegoś w rodzaju dokowania-komponowania, aby połączyć całość.
Jestem pewien, że istnieją inne opcje. Jaka jest zalecana najlepsza praktyka?