백엔드와 프론트 엔드 웹 애플리케이션을 완전히 분리하여 (JSON) REST API와 통신 할 수 있도록하는 것이 정상적인 설계입니까?

새로운 비즈니스 웹 응용 프로그램을 만들고 있는데 다음을 달성하고 싶습니다.

• 각 영역에서 최고의 기술을 사용하십시오. 견고한 ORM을 갖춘 안정적인 백엔드 프레임 워크를 원합니다. 그리고 프론트 엔드 애플리케이션에 최신 HTML 및 자바 스크립트 기능을 사용하는 최신 SPA (단일 페이지 애플리케이션) 프레임 워크를 원합니다.
• 웹 애플리케이션, 모바일 (Android) 및 기타 유형 (스마트 장치 등)과 같은 다양한 유형의 애플리케이션에서 사용하기위한 백엔드 엔티티 및 비즈니스 서비스 노출

따라서 두 가지 요구 사항을 모두 충족시키기 위해 백엔드 및 프론트 엔드 애플리케이션에서 애플리케이션 을 완전히 분리하고 REST API (JSON)를 사용하여 애플리케이션 간 통신을 구성하는 경향이 있습니다. 이 소리가 접근합니까?

많은 웹 애플리케이션 기술에는 서버 측 애플리케이션이 뷰 생성을 제어하고 뷰의 응답을 부분적으로 처리하는 뷰 레이어가 통합되어 있기 때문에 이러한 분리는 명백한 설계 솔루션이 아닙니다 (예 : 뷰 레이어가있는 SpringMVC, 뷰가있는 PHP Yii) Java JSF / Facelet은 구성 요소의 상태를 서버에 완전히 저장합니다). 따라서 더 강력한 커플 링을 제안하고 더 빠른 개발 시간과 더 표준적인 경로 여행을 약속하는 많은 기술이 있습니다. 따라서 널리 사용되지 않는 방식으로 기술을 사용할 때주의해야합니다.

내가 이해 한 것처럼 완전히 분리 된 SPA 프론트 엔드는 일반적으로 타사 API를 사용해야 할 필요성에서 발생합니다. 그러나 한 회사에서 백엔드와 프론트 엔드를 모두 개발할 때 이러한 분리형 사운드 디자인입니까?

내가 선택한 기술은 현재 Java / Spring 백엔드와 프론트 엔드 용 Angular2 / Web Components / Polymer입니다. 그러나이 질문은 구체적인 기술의 선택이 아니라 일반적인 디자인에 관한 것이기 때문에이 질문과 관련이 없습니까?

백엔드와 프론트 엔드 웹 애플리케이션을 완전히 분리하여 (JSON) REST API와 통신 할 수 있도록하는 것이 정상적인 설계입니까?

예, 정상입니다. 그러나 이런 종류의 분리가 필요하고 전체 응용 프로그램에이 설정을 강요하지 않는 경우에만 정상입니다.

SPA에는 이와 관련된 몇 가지 문제가 있습니다. 여기 내 마음에 떠오르는 몇 가지가 있습니다.

• 주로 JavaScript입니다. 애플리케이션의 섹션에 하나의 오류가 있으면 해당 Javascript 오류로 인해 애플리케이션의 다른 섹션이 작동하지 않을 수 있습니다. 서버에서 제공 한 페이지 (SpringMVC, PHP 등)를 사용하면 새로운 섹션을 다시로드 할 수 있습니다.
• CORS . 반드시 필수는 아니지만 종종 백엔드는 프런트 엔드와 다른 도메인 이름에 있습니다. 이제 브라우저 보안 문제를 해결해야합니다.
• SEO . 이것이 필요합니까? 사이트가 공개되어 있습니까? Google은 자바 스크립트를 이해하고 사이트에서 이해하려고 노력하지만 기본적으로 봇을 제어하고 최선을 다하겠습니다. 제어권을 되 찾는 것은 PhantomJS 와 같은 다른 도구에 의존해야 할 수도 있습니다 .
• 별도의 프론트 엔드 애플리케이션이란 별도의 프로젝트, 배포 파이프 라인, 추가 툴링 등을 의미합니다.
• 모든 코드가 클라이언트에있는 경우 보안이 더 어려워집니다.

물론 SPA의 장점도 있습니다.

• 프런트 엔드에서 사용자와 완전히 상호 작용하고 서버에서 필요한 경우에만 데이터를로드합니다. 응답 성과 사용자 경험이 향상되었습니다.
• 응용 프로그램에 따라 클라이언트에서 수행되는 일부 처리는 해당 계산의 서버를 절약한다는 것을 의미합니다.
• 백엔드와 프론트 엔드를 발전시키는 데 더 나은 유연성을 제공합니다 (별도 가능).
• 백엔드가 본질적으로 API 인 경우 기본 Android / iPhone 애플리케이션과 같은 다른 클라이언트를 사용할 수 있습니다.
• 이로 인해 프런트 엔드 개발자가 컴퓨터에서 서버 응용 프로그램을 실행할 필요없이 CSS / HTML을보다 쉽게 ​​수행 할 수 있습니다.

따라서 두 가지 접근 방식 (SPA 대 서버 페이지)에는 장단점이 있습니다. 두 가지 옵션을 조사하는 데 시간을 보낸 다음 상황에 따라 선택하십시오.

귀하의 질문에 대한 답변은 간단합니다. 예. 당신이 제안하는 것은 건전한 접근법입니다. 그러나 당신이 묻고 싶은 것은 그것이 더 나은 접근 방법 인지 아닌지 , 불행히도 우리 중 누구도 당신을 위해 대답 할 수 없습니다. 관련된 요소는 조직과 제품 요구 사항에 대한 모든 정보를 공개하지 않으면 실질적인 결론을 내릴 수없는 여러 측면에 걸쳐 있습니다. 어쨌든 무엇을 해야할지 이미 알고 있다고 생각합니다.

경고와 함께 정상입니다.

프론트 엔드 자바 스크립트 프레임 워크는 수행 할 수있는 작업이 제한되어 있습니다. 여러 애플리케이션에서 사용할 원시 API를 작성하는 경우 일반적으로 해당 특정 애플리케이션에서 작동하는보기 모델에 대한 원시 API 호출의 일부 서버 측 처리가 필요합니다.

따라서 '정상적인'아키텍처는 다음과 같습니다.

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

이제 하나의 웹 애플리케이션 만 있다면 'api 노출 비즈니스 로직'계층을 잘라 내고 서버 측 웹 코드가 비즈니스 로직을 직접 호출하도록 할 수 있습니다.

비즈니스 로직을 자체 라이브러리로 분리 했으므로 여전히 ui 로직에서 분리되어 나중에 서비스 계층을 추가 할 수 있습니다.

마찬가지로 api 서비스는 서버 측 코드로 호출되므로 http 통신에 제한이 없습니다. (이것은 현재 거의 보편적이지만)

또한 자바 스크립트가 제공되는 호스트와 동일한 호스트를 호출하면 cors와 함께 놀 필요가 없습니다.