Czy to normalne, że całkowicie odsprzęga backend i frontendowe aplikacje internetowe i pozwala im komunikować się z (JSON) REST API?

Tworzę nową biznesową aplikację internetową i chcę osiągnąć:

• Korzystaj z najlepszych technologii z odpowiednich dziedzin. Chcę niezawodnego frameworka zaplecza z solidnym ORM. I chcę najbardziej zaawansowanego frameworka SPA (aplikacja jednostronicowa) z wykorzystaniem najnowocześniejszych funkcji HTML i JavaScript dla aplikacji frontendowej
• Ujawnij jednostki zaplecza i usługi biznesowe do użytku z różnych rodzajów aplikacji - np. Aplikacji internetowych, urządzeń mobilnych (Android) i ewentualnie innych typów (urządzenia inteligentne itp.)

Tak więc - aby spełnić oba wymagania, jestem skłonny całkowicie oddzielić moją aplikację w aplikacjach backend i frontend oraz zorganizować komunikację między nimi za pomocą REST API (JSON). Czy to rozsądne podejście?

Takie rozdzielenie nie jest oczywistym rozwiązaniem projektowym, ponieważ wiele technologii aplikacji internetowych ma zintegrowane warstwy widoku, w których aplikacja po stronie serwera mniej więcej kontroluje generowanie widoku i częściowo obsługuje odpowiedzi z widoku (np. SpringMVC z warstwą widoku, PHP Yii z widokiem warstwa Java JSF / Facelets całkowicie zapisuje stan swoich komponentów na serwerze). Tak więc - istnieje wiele technologii, które proponują silniejsze sprzężenie i obiecują szybszy czas rozwoju i bardziej standardową ścieżkę. Więc - muszę być ostrożny, kiedy zaczynam korzystać z technologii w sposób, który nie jest powszechnie stosowany.

Jak rozumiem, wówczas całkowicie oddzielny frontend SPA zwykle wynika z konieczności korzystania z API stron trzecich. Ale czy taki dźwięk odsprzęgający, gdy backend i frontend są opracowywane przez jedną firmę?

Mój wybór technologii to obecnie Java / Spring backend i Angular2 / Web Components / Polymer for frontend - jeśli wolno mi to powiedzieć. Ale to nie ma znaczenia dla tego pytania, ponieważ pytanie dotyczy ogólnego projektu, a nie wyboru konkretnych technologii?

Czy to normalne, że całkowicie odsprzęga backend i frontendowe aplikacje internetowe i pozwala im komunikować się z (JSON) REST API?

Tak, to normalne. Ale jest to normalne tylko wtedy, gdy potrzebujesz tego rodzaju separacji i nie wymuszasz tego ustawienia w swojej ogólnej aplikacji.

SPA wiąże się z kilkoma związanymi z tym problemami. Oto kilka, które pojawiają się teraz w mojej głowie:

• to głównie JavaScript. Jeden błąd w sekcji aplikacji może uniemożliwić działanie innych sekcji aplikacji z powodu tego błędu Javascript. Ze stronami obsługiwanymi z serwera (SpringMVC, PHP itp.) Ponownie ładujesz nową sekcję;
• CORS . Niekoniecznie obowiązkowy, ale często zaplecze ma inną nazwę domeny niż interfejs. Więc teraz masz do czynienia z problemami bezpieczeństwa przeglądarki;
• SEO . Potrzebujesz to? Czy Twoja strona jest publiczna? Google potrafi zrozumieć Javascript i starać się znaleźć sens w Twojej witrynie, ale w zasadzie dajesz kontrolę botowi i masz nadzieję na najlepsze. Odzyskanie kontroli może oznaczać konieczność polegania na innych narzędziach, takich jak PhantomJS .
• oddzielna aplikacja front-end oznacza oddzielne projekty, rurociągi wdrożeniowe, dodatkowe narzędzia itp .;
• bezpieczeństwo jest trudniejsze, gdy cały kod znajduje się na kliencie;

Oczywiście są też zalety SPA:

• całkowicie wchodzisz w interakcje z użytkownikiem i ładujesz dane tylko z serwera. Tak więc lepsza reakcja i wygoda użytkownika;
• w zależności od aplikacji niektóre przetwarzanie wykonywane na kliencie oznacza, że ​​oszczędzasz serwerowi tych obliczeń.
• mieć większą elastyczność w ewolucji zaplecza i frontonu (możesz to zrobić osobno);
• jeśli twój back-end jest zasadniczo interfejsem API, możesz mieć przed sobą innych klientów, takich jak natywne aplikacje na Androida / iPhone'a;
• separacja może ułatwić programistom front-end tworzenie CSS / HTML bez konieczności uruchamiania aplikacji serwerowej na ich komputerze.

Chodzi o to, że oba podejścia mają zalety i wady (SPA vs. strony serwera). Poświęć trochę czasu na zbadanie obu opcji, a następnie wybierz w zależności od swojej sytuacji.

Odpowiedź na twoje pytanie jest prosta. Tak. To, co proponujesz, to rozsądne podejście. Ale myślę, że chcesz zapytać, czy jest to lepsze podejście i niestety nikt z nas nie może odpowiedzieć na to za ciebie. Związane z tym czynniki obejmują zbyt wiele aspektów, że bez ujawnienia wszystkiego zarówno na temat organizacji, jak i wymagań dotyczących produktu, nie można wyciągnąć prawdziwych wniosków. Myślę, że i tak już wiesz, co robić.

Normalne z zastrzeżeniami.

frameworki javascript są ograniczone pod względem możliwości. Jeśli tworzysz surowe api do użytku przez wiele aplikacji, zwykle wymagają one przetwarzania po stronie serwera surowych wywołań api w celu wyświetlenia modeli, które działają z tą konkretną aplikacją.

Dlatego „normalną” architekturą może być:

database
business logic services (dll)
api exposing business logic
server side website exposing viewmodels and functionality via json rest endpoints
client side javascript implementing ui

Teraz, jeśli masz tylko jedną aplikację internetową, możesz wyciąć warstwę api odsłaniającą logikę biznesową i po prostu poprosić kod WWW po stronie serwera o bezpośrednie wywołanie logiki biznesowej.

Ponieważ podzieliłeś logikę biznesową na własną bibliotekę, nadal jest ona oddzielona od logiki interfejsu użytkownika i zawsze możesz później dodać warstwę usługi.

Podobnie, ponieważ usługa interfejsu API jest wywoływana przez kod po stronie serwera, komunikacja HTTP nie jest ograniczona. (chociaż jest to teraz dość uniwersalne)

Dodatkowo posiadanie wywołania javascript do tego samego hosta, z którego jest obsługiwany, oznacza, że ​​nie musisz krzątać się po corsach