단일 페이지 응용 프로그램 : 장단점 [닫기]

SPA에 대해 읽었으며 이점이 있습니다. 나는 대부분 설득력이 없습니다. 내 의심을 불러 일으키는 3 가지 장점이 있습니다.

질문 : SPA를 옹호하는 사람으로서 처음 세 가지 진술에 대해 내가 틀렸다는 것을 증명할 수 있습니까?

                              === ADVANTAGES ===

1. SPA는 반응이 빠른 사이트에 매우 적합합니다.

서버 측 렌더링은 모든 중간 상태에 대해 구현하기 어렵습니다. 작은보기 상태는 URL에 잘 매핑되지 않습니다.

단일 페이지 앱은 HTML을 검색하기 위해 서버 왕복을 요구하지 않고 UI의 일부를 다시 그릴 수있는 기능으로 구별됩니다. 이는 데이터를 처리하는 모델 계층과 모델에서 읽은 뷰 계층을 가짐으로써 데이터 표시에서 데이터를 분리함으로써 달성됩니다.

비 SPA 용 모델 계층을 보유하는 데 어떤 문제가 있습니까? SPA가 클라이언트 측에서 MVC와 호환되는 유일한 아키텍처입니까?

2. SPA를 사용하면 서버에 추가 쿼리를 사용하여 페이지를 다운로드 할 필요가 없습니다.

아, 그리고 사이트를 방문하는 동안 얼마나 많은 페이지를 사용자가 다운로드 할 수 있습니까? 둘, 셋? 대신 다른 보안 문제가 발생하여 로그인 페이지, 관리 페이지 등을 별도의 페이지로 분리해야합니다. 차례로 SPA 아키텍처와 충돌합니다.

3. 다른 장점이 있습니까? 다른 소식은 듣지 마십시오 ..

                            === DISADVANTAGES ===

1. 클라이언트는 자바 스크립트를 활성화해야합니다.
2. 사이트에는 하나의 진입 점이 있습니다.
3. 보안.

추신 : 나는 SPA 및 비 SPA 프로젝트에서 일했습니다. 이해를 깊게해야하기 때문에 그런 질문을합니다. SPA 지지자들에게 해를 끼치려는 의도는 없습니다. SPA에 대해 조금 더 읽어달라고 부탁하지 마십시오. 나는 그것에 대해 당신의 고려 사항을 듣고 싶습니다.

가장 인기있는 SPA 사이트 중 하나 인 GMail을 살펴 보겠습니다.

1. SPA는 반응이 빠른 사이트에 매우 적합합니다.

서버 측 렌더링은 URL에 #hash를 유지하는 것과 같은 간단한 기술이나보다 최근에는 HTML5pushState 와 같은 단순한 기술로는 어렵지 않습니다 . 이 방법을 사용하면 웹 앱의 정확한 상태가 페이지 URL에 포함됩니다. Gmail에서와 마찬가지로 메일을 열 때마다 특수 해시 태그가 URL에 추가됩니다. 다른 브라우저 창에 복사하여 붙여 넣은 경우 정확히 동일한 메일을 열 수 있습니다 (인증 할 수있는 경우). 이 접근 방식은보다 전통적인 쿼리 문자열에 직접 매핑되며 차이점은 단지 실행에 있습니다. HTML5 pushState ()를 #hash사용하면 첫 번째 요청에서 서버에서 확인한 다음 후속 요청에서 ajax를 통해로드 할 수있는 완전히 클래식 한 URL을 제거 하고 사용할 수 있습니다.

2. SPA를 사용하면 서버에 추가 쿼리를 사용하여 페이지를 다운로드 할 필요가 없습니다.

내 웹 사이트를 방문하는 동안 사용자가 다운로드 한 페이지 수 ?? 실제로 메일 계정을 열 때 읽은 메일 수 한 번에> 50을 읽습니다. 이제 메일의 구조는 거의 동일합니다. 서버 측 렌더링 체계를 사용하는 경우 서버는 모든 요청 (일반적인 경우)에이를 렌더링합니다. -보안 문제-사이트의 구조에 전적으로 의존하는 관리자 / 로그인을위한 별도의 페이지를 유지해서는 안됩니다. paytm.com을 가져 가십시오 (예 : 웹 사이트 SPA를 만드는 것). 내 스파 웹 사이트에서 인증 양식을 사용한다는 의미입니다. -아마도 가장 많이 사용되는 SPA 프레임 워크 Angular JS에서 개발자는 웹 사이트에서 전체 HTML 템플을로드 할 수 있으므로 사용자 인증 수준에 따라 수행 할 수 있습니다. 모든 인증 유형에 대해 HTML을 사전로드하는 것은

3. 다른 장점이 있습니까? 다른 소식은 듣지 마십시오 ..

• 요즘에는 클라이언트가 자바 스크립트를 사용할 수있는 브라우저를 가지고 있다고 가정 할 수 있습니다.
• 사이트의 단 하나의 진입 점. 앞에서 언급 한 상태 유지 관리가 가능하므로 원하는 수의 진입 점을 가질 수 있지만 확실하게 진입 점을 확보해야합니다.
• SPA 사용자조차도 자신에게 적절한 권한이있는 내용 만 볼 수 있습니다. 한 번에 모든 것을 주입 할 필요는 없습니다. diff html 템플릿 및 javascript 비동기를로드하는 것도 SPA의 유효한 부분입니다.

내가 생각할 수있는 장점은 다음과 같습니다.

1. html을 렌더링하면 분명히 사이트를 방문하는 모든 사용자 가이 작업을 수행하는 데 약간의 리소스가 필요합니다. 또한 주요 로직 렌더링은 이제 서버 측이 아닌 클라이언트 측에서 수행됩니다.
2. 날짜 시간 문제-클라이언트에게 UTC 시간을 미리 설정 한 형식으로 지정하고 자바 스크립트가 처리하도록 시간대를 신경 쓰지 않아도됩니다. 이것은 사용자 IP에서 파생 된 위치를 기준으로 시간대를 추측 해야하는 위치에 큰 이점입니다.
3. 나에게 상태는 변수를 설정하면 변수가있을 것이므로 SPA에서 더 잘 유지됩니다. 이것은 웹 페이지가 아닌 앱을 개발하는 느낌을줍니다. 이것은 일반적으로 foodpanda, flipkart, amazon과 같은 사이트를 만드는 데 많은 도움이됩니다. 클라이언트 측 상태를 사용하지 않으면 값 비싼 세션을 사용하기 때문입니다.
4. 웹 사이트는 매우 반응이 빠릅니다. SPA가 아닌 웹 사이트에서 계산기를 만들어보십시오 (이상한 것을 알고 있습니다).

댓글 업데이트

소켓과 긴 폴링에 대해 언급 한 사람은 없습니다. 다른 클라이언트에서 모바일 앱이라고 로그 아웃하면 브라우저도 로그 아웃해야합니다. SPA를 사용하지 않는 경우 리디렉션이있을 때마다 소켓 연결을 다시 만들어야합니다. 알림, 프로필 업데이트 등과 같은 데이터의 모든 업데이트에서도 작동합니다.

다른 관점 : 웹 사이트 외에 프로젝트에 기본 모바일 앱이 포함됩니까? 그렇다면 서버 (예 : JSON)에서 해당 원시 앱으로 원시 데이터를 공급하고 클라이언트 측 처리를 수행하여 렌더링 할 것입니까? 따라서이 주장으로 클라이언트 측 렌더링 모델을 이미 수행하고 있습니다. 이제 프로젝트의 웹 사이트 버전에 동일한 모델을 사용해서는 안되는 문제가됩니다. 생각할 필요가없는 종류. 그러면 SEO 이점과 공유 가능 / 책갈피 URL의 편의를 위해서만 서버 측 페이지를 렌더링 할 것인지에 대한 의문이 생깁니다.

나는 실용 주의자이므로 비용과 혜택 측면에서 이것을 보려고 노력할 것입니다.

내가 제공하는 모든 단점에 대해, 나는 그들이 해결할 수 있음을 알고 있습니다. 그렇기 때문에 흑백으로 보지 않고 비용과 이점을 보았습니다.

장점

• 보다 쉬운 상태 추적-쿠키, 양식 제출, 로컬 저장소, 세션 저장소 등을 사용하여 2 페이지로드 사이의 상태를 기억할 필요가 없습니다.
• 모든 페이지 (헤더, 바닥 글, 로고, 저작권 배너 등)에있는 보일러 플레이트 컨텐츠는 일반적인 브라우저 세션 당 한 번만로드됩니다.
• "페이지"전환시 오버 헤드 대기 시간이 없습니다.

단점

• 퍼포먼스 모니터링-손에 묶여 : 대부분의 브라우저 수준의 퍼포먼스 모니터링 솔루션은 첫 바이트 투 타임, DOM 구축 시간, HTML 네트워크 왕복, 온로드 이벤트 등과 같은 페이지 로딩 시간에만 초점을 맞추 었습니다. AJAX를 통한 포스트로드는 측정되지 않습니다. 링크를 클릭하고 타이머를 시작한 다음 AJAX 결과를 렌더링 한 후 타이머를 종료하고 피드백을 보내는 등 명시적인 측정 값을 기록하도록 코드를 계측 할 수있는 솔루션이 있습니다. 예를 들어 New Relic은이 기능을 지원합니다. SPA를 사용하면 몇 가지 도구 만 사용할 수 있습니다.
• 보안 / 침투 테스트-수동 연결 : 자동화 된 보안 검색으로 SPA 프레임 워크에서 전체 페이지를 동적으로 빌드 할 때 링크를 찾기가 어려울 수 있습니다. 이것에 대한 해결책이있을 수 있지만 다시 한 번 자신을 제한했습니다.
• 번들링 : 초기 페이지로드시 전체 웹 사이트에 필요한 모든 코드를 다운로드 할 때 상황이 발생하기 쉬우 며, 이는 저 대역폭 연결에서 끔찍하게 수행 될 수 있습니다. JavaScript와 CSS 파일을 번들로 묶어 갈수록 더 자연스러운 청크를로드하려고 할 수 있지만 이제는 매핑을 유지하고 의도하지 않은 파일이 실현되지 않은 종속성을 통해 가져올 수 있는지 감시해야합니다. 다시, 해결할 수 있지만 비용이 듭니다.
• 빅뱅 리팩토링 : 위험을 최소화하기 위해 한 프레임 워크에서 다른 프레임 워크로 전환하는 등 아키텍처를 크게 변경하려면 점진적으로 변경하는 것이 좋습니다. 즉, 새로운 기능을 사용하기 시작하고 페이지 별, 기능별 등의 방식으로 마이그레이션 한 다음 이전 버전을 삭제하십시오. 기존의 다중 페이지 앱을 사용하면 한 페이지를 Angular에서 React로 전환 한 다음 다음 스프린트에서 다른 페이지를 전환 할 수 있습니다. SPA를 사용하면 전혀 또는 아무것도 아닙니다. 변경하려면 전체 응용 프로그램을 한 번에 변경해야합니다.
• 탐색의 복잡성 : history.js, Angular 2와 같은 SPA에서 탐색 컨텍스트를 유지하는 데 도움이되는 툴링이 존재하며 대부분 URL 프레임 워크 (#) 또는 최신 히스토리 API에 의존합니다. 모든 페이지가 별도의 페이지 인 경우 해당 페이지가 필요하지 않습니다.
• 코드 파악의 복잡성 : 웹 사이트는 자연스럽게 페이지라고 생각합니다. 다중 페이지 앱은 일반적으로 코드별로 페이지를 분할하므로 유지 관리가 용이합니다.

다시 한번, 나는 이러한 문제들 모두가 어느 정도의 비용으로 해결할 수 있음을 알고 있습니다. 그러나 처음에는 피할 수 있었던 문제를 해결하기 위해 모든 시간을 소비하는 시점이 있습니다. 그것은 혜택과 그들이 당신에게 얼마나 중요한지에 관한 것입니다.

단점

1. 클라이언트는 자바 스크립트를 활성화해야합니다. 예, 이것은 SPA의 명백한 단점입니다. 필자의 경우 사용자가 JavaScript를 사용하도록 설정할 수 있음을 알고 있습니다. 당신이 할 수 없다면, 당신은 SPA, 기간을 할 수 없습니다. 이는 .NET Framework가 설치되지 않은 컴퓨터에 .NET 앱을 배포하는 것과 같습니다.

2. 사이트에 하나의 진입 점 만 있습니다. SammyJS를 사용 하여이 문제를 해결했습니다. 2 ~ 3 일 동안 작업을 올바르게 설정하면 사람들이 앱에 딥 링크 북마크를 만들어 올바르게 작동 할 수 있습니다. 서버는 하나의 엔드 포인트 ( "이 앱의 HTML + CSS + JS 제공"엔드 포인트 (미리 컴파일 된 응용 프로그램의 다운로드 / 업데이트 위치라고 생각)) 만 노출하면되고 클라이언트 측 JavaScript는 응용 프로그램의 실제 항목을 처리하십시오.

3. 보안.이 문제는 SPA에만 국한된 것이 아니라 "오래된"클라이언트-서버 응용 프로그램 (하이퍼 텍스트를 사용하여 페이지 간 링크의 HATEOAS 모델)을 사용하는 경우와 동일한 방식으로 보안을 처리해야합니다. 사용자가 자바 스크립트가 아닌 요청을하고 결과가 JSON 또는 일부 데이터 형식이 아닌 HTML로되어 있다는 것입니다. SPA 이외의 앱에서는 서버의 개별 페이지를 보호해야하지만 SPA 앱의 경우 데이터 엔드 포인트를 보호해야합니다. (그리고 클라이언트가 모든 코드에 액세스하지 못하게하려면 다운로드 가능한 JavaScript를 별도의 영역으로 분리해야합니다. 브라우저를 요청하기 위해 SammyJS 기반 라우팅 시스템에 연결하기 만하면됩니다. 사용자 역할의 초기로드를 기반으로 클라이언트가 액세스해야한다는 것을 알고있는 것,

장점

1. 많은 경우 SPA (아주 언급되지는 않음)의 주요 아키텍처 이점은 앱의 "채팅 성"이 크게 줄어든다는 것입니다. 클라이언트 (대부분의 요점)에서 대부분의 처리를 처리하도록 올바르게 설계하면 서버에 대한 요청 수 ( "사용자 경험을 손상시키는 503 오류 가능성")가 크게 줄어 듭니다. 실제로 SPA를 사용하면 완전히 오프라인 처리를 수행 할 수 있으며 일부 상황에서는 엄청납니다 .

2. 클라이언트 측 렌더링을 올바르게 수행하면 성능이 확실히 향상되지만 이것이 SPA를 구축하는 가장 강력한 이유는 아닙니다. (결국 네트워크 속도가 향상되고 있습니다.) SPA만으로는이 사례를 만들지 마십시오.

3. UI 디자인의 유연성은 내가 찾은 또 다른 주요 이점 일 것입니다. JavaScript를 SDK로 사용하여 API를 정의한 후에 는 일부 정적 리소스 파일을 제외하고 서버에 전혀 영향을주지 않으면 서 프런트 엔드를 완전히 다시 작성할 수있었습니다 . 전통적인 MVC 앱으로 해보십시오! :) (이것은 걱정할 API의 라이브 배포 및 버전 일관성이있는 경우 유용합니다.)

결론 : 오프라인 처리가 필요하거나 (적어도 클라이언트가 가끔 서버 중단으로 살아남기를 원할 때) 하드웨어 비용을 크게 줄이고 JavaScript 및 최신 브라우저를 사용하려면 SPA가 필요합니다. 다른 경우에는 트레이드 오프에 가깝습니다.

SPA의 한 가지 주요 단점-SEO. 최근에 Google과 Bing은 크롤링 중에 JavaScript를 실행하여 Ajax 기반 페이지의 색인을 생성하기 시작했지만 여전히 많은 경우 페이지가 잘못 색인됩니다.

SPA를 개발하는 동안 모든 사이트를 사후 렌더링하고 크롤러가 사용할 정적 html 스냅 샷을 만들어 SEO 문제를 처리해야합니다. 이를 위해서는 적절한 인프라에 대한 견고한 투자가 필요합니다.

업데이트 19.06.16 :

이 답변을 얼마 전에 작성했기 때문에 Single Page Apps (즉, AngularJS 1.x)에 대한 경험이 훨씬 많아 지므로 더 많은 정보를 공유 할 수 있습니다.

제 생각에 SPA 응용 프로그램의 주요 단점은 SEO이며, "대시 보드"응용 프로그램의 종류로만 제한됩니다. 또한 기존 솔루션에 비해 캐싱이 훨씬 어려워집니다. 예를 들어 ASP.NET에서 캐싱은 매우 쉽습니다. OutputCaching을 켜면 충분합니다. 전체 HTML 페이지는 URL (또는 다른 매개 변수)에 따라 캐시됩니다. 그러나 SPA에서는 2 차 캐시, 템플릿 캐싱 등과 같은 일부 솔루션을 사용하여 캐싱을 직접 처리해야합니다.

SPA가 데이터 중심 애플리케이션에 가장 적합한 사례를 만들고 싶습니다. Gmail은 물론 데이터에 관한 것이므로 SPA의 좋은 후보입니다.

그러나 서비스 약관 페이지와 같이 귀하의 페이지가 대부분 표시 용인 경우 SPA는 과도하게 사용됩니다.

스위트 스팟은 특정 페이지에 따라 SPA와 정적 / MVC 스타일 페이지가 혼합 된 사이트가 있다고 생각합니다.

예를 들어, 내가 구축중인 한 사이트에서 사용자는 표준 MVC 색인 페이지를 방문합니다. 그러나 실제 응용 프로그램으로 이동하면 SPA가 호출됩니다. 이것의 또 다른 장점은 SPA의로드 시간이 홈페이지가 아니라 앱 페이지에 있다는 것입니다. 홈페이지에있는로드 시간은 처음 사이트 사용자에게 방해가 될 수 있습니다.

이 시나리오는 Flash를 사용하는 것과 약간 비슷합니다. 몇 년간의 경험을 쌓은 후로드 요소로 인해 Flash 사이트 만 제로에 가깝게 떨어졌습니다. 그러나 페이지 구성 요소로서 여전히 사용 중입니다.

서버가 24/7 모드에서 최대 용량으로 실행되는 google, amazon 등과 같은 회사의 경우 트래픽을 줄이면 하드웨어, 에너지, 유지 관리 비용이 줄어 듭니다. 서버에서 클라이언트로 CPU 사용량이 바뀌면 SPA가 빛을 발합니다. 장점 과체중 단점. 따라서 SPA의 유무는 사용 사례에 따라 크게 달라집니다.

SPA에 대한 (웹 개발자의 경우) 유스 케이스를 언급하는 것만으로도 임베디드 시스템에서 GUI를 구현하는 방법을 찾고 있습니다. 브라우저 기반 아키텍처가 매력적입니다. 전통적으로 임베디드 시스템의 UI, Java, Qt, wx 등의 상용 프레임 워크는 많지 않았습니다. 몇 년 전 Adobe는 플래시를 사용하여 시장에 진입하려했지만 성공하지 못한 것 같습니다.

요즘 "임베디드 시스템"은 몇 년 전 메인 프레임만큼 강력하기 때문에 REST를 통해 제어 장치에 연결된 브라우저 기반 UI가 가능한 솔루션입니다. 이점은 무료 UI 도구 팔레트입니다. (예 : Qt는 로열티 수수료로 판매 단위당 20-30 $ + 개발자 당 3000-4000 $ 필요)

이러한 아키텍처의 경우 SPA는 많은 이점을 제공합니다. 예를 들어 데스크탑 응용 프로그램 개발자를위한보다 친숙한 개발 접근 방식, 서버 액세스 감소 (종종 자동차 산업에서 UI 및 시스템 머들은 개별 하드웨어이며 시스템 부분에는 RT OS가 있음).

유일한 클라이언트는 내장 브라우저이므로 JS- 가용성, 서버 측 로깅, 보안과 같은 언급 된 단점은 더 이상 계산되지 않습니다.

2. SPA를 사용하면 서버에 추가 쿼리를 사용하여 페이지를 다운로드 할 필요가 없습니다.

나는 아직도 많은 것을 배워야하지만 SPA에 대해 배우기 시작한 이래로 그들을 좋아합니다.

이 특정한 점은 큰 차이를 만들 수 있습니다.

SPA가 아닌 많은 웹 앱에서 여전히 Ajax 요청을하는 페이지에서 컨텐츠를 검색하고 추가 할 것입니다. SPA를 넘어서 다음과 같이 생각합니다. ajax를 사용하여 검색 및 표시 할 컨텐츠가 전체 페이지이면 어떨까요? 페이지의 작은 부분 만이 아니라?

시나리오를 소개하겠습니다. 두 페이지가 있다고 가정하십시오.

1. 제품 목록이있는 페이지
2. 특정 제품의 세부 정보를 볼 수있는 페이지

목록 페이지에 있다고 가정하십시오. 그런 다음 제품을 클릭하여 세부 정보를 봅니다. 클라이언트 측 앱은 2 개의 ajax 요청을 트리거합니다.

1. 제품 세부 정보가 포함 된 json 객체를 가져 오기위한 요청
2. 제품 세부 정보가 삽입 될 HTML 템플릿 요청

그런 다음 클라이언트 측 앱이 데이터를 html 템플릿에 삽입하여 표시합니다.

그런 다음 목록으로 돌아가서 (이 요청은 수행되지 않습니다!) 다른 제품을 엽니 다. 이번에는 제품 세부 정보를 얻기위한 아약스 요청 만 있습니다. html 템플릿은 동일하므로 다시 다운로드 할 필요가 없습니다.

SPA가 아닌 경우 제품 세부 정보를 열 때 한 번만 요청하면이 시나리오에서는 2를 수행했다고 말할 수 있습니다. 예. 그러나 여러 페이지를 탐색 할 때 전체적인 관점에서 이점을 얻을 수 있으므로 요청 수가 줄어 듭니다. 그리고 HTML 템플릿이 재사용되기 때문에 클라이언트 측과 서버 사이에 전송되는 데이터도 낮아질 것입니다. 또한 모든 요청에 ​​모든 페이지에 존재하는 모든 CSS, 이미지, 자바 스크립트 파일을 다운로드 할 필요는 없습니다.

또한 서버 측 언어가 Java라고 가정 해 봅시다. 내가 언급 한 두 가지 요청을 분석하면 1 다운로드 데이터 (보기 파일을로드하고보기 렌더링 엔진을 호출 할 필요가 없음)와 다른 다운로드 및 정적 html 템플릿을 사용하여 검색 할 수있는 HTTP 웹 서버를 가질 수 있습니다 Java 응용 프로그램 서버를 호출하지 않고도 직접 계산할 수 있습니다!

마지막으로 대기업은 SPA, Facebook, GMail, Amazon을 사용합니다. 그들은 놀지 않고,이 모든 것을 연구하는 최고의 엔지니어를 보유하고 있습니다. 따라서 당신이 장점을 보지 못하면 당신은 처음에 그것들을 믿을 수 있고 길에서 그것을 발견하기를 희망합니다.

그러나 좋은 SPA 디자인 패턴을 사용하는 것이 중요합니다. AngularJS와 같은 프레임 워크를 사용할 수 있습니다. 좋은 디자인 패턴을 사용하지 않고 SPA를 구현하려고하면 결국 혼란 스러울 수 있습니다.

단점 : 기술적으로 SPA의 설계 및 초기 개발은 복잡하며 피할 수 있습니다. 이 SPA를 사용하지 않는 다른 이유는 다음과 같습니다.

• a) 보안 : 단일 페이지 응용 프로그램은 사이트 간 스크립팅 (XSS)으로 인해 기존 페이지와 비교하여 덜 안전합니다.
• b) 메모리 누출 : JavaScript에서 메모리가 누출되면 강력한 컴퓨터 속도가 느려질 수 있습니다. 전통적인 웹 사이트는 페이지 간 탐색을 권장하므로 이전 페이지로 인한 메모리 누수가 거의 깨끗해져 잔여 물이 줄어 듭니다.
• c) 클라이언트가 SPA를 실행하려면 JavaScript를 활성화해야하지만 여러 페이지 응용 프로그램에서는 JavaScript를 완전히 피할 수 있습니다.
• d) SPA가 최적의 크기로 커져 대기 시간이 길어집니다. 예 : 연결 속도가 느린 Gmail 작업

이외에도 다른 아키텍처 제한 사항은 탐색 데이터 손실, 브라우저에 탐색 기록 로그 없음 및 셀레늄 자동 기능 테스트의 어려움입니다.

이 링크는 단일 페이지 응용 프로그램의 장단점을 설명합니다.

내 개발에서 SPA 사용에 대한 두 가지 뚜렷한 이점을 발견했습니다. 그것은 전통적인 웹 앱에서 다음과 같은 것을 달성 할 수 없다는 것을 말하는 것이 아닙니다. 추가적인 단점을 나타내지 않고 점진적인 이점을 볼 수 있습니다.

• 새로운 콘텐츠를 렌더링하는 것이 새로운 HTML 페이지에 대한 http 서버 요청이 아니더라도 항상 서버 요청이 적을 수 있습니다. 그러나 새로운 컨텐츠는 데이터를 가져 오기 위해 Ajax 호출을 쉽게 요구할 수 있기 때문에 잠재력이 있다고 말하지만 그 데이터는 자체 이익보다 점진적으로 더 가벼워 질 수 있습니다.

• "상태"를 유지하는 능력. 가장 간단한 용어로, 앱에 진입 할 때 변수를 설정하면 사용자 경험 전반에 걸쳐 다른 구성 요소가이를 전달하거나 로컬 스토리지 패턴으로 설정하지 않고도 사용할 수 있습니다. 그러나이 기능을 지능적으로 관리하는 것이 최상위 범위를 정리하는 데 중요합니다.

JS (웹 응용 프로그램을 요구하는 것은 미친 일이 아닙니다)를 요구하는 것 외에 다른 지적 단점은 SPA에만 국한되지 않거나 좋은 습관과 개발 패턴을 통해 완화 될 수 있다고 생각합니다.

서버 측에서 보안 및 API 안정성을 처리하는 방법을 먼저 정의하지 않고 SPA 사용을 고려하지 마십시오. 그러면 SPA를 사용하는 것의 진정한 이점 중 일부를 보게됩니다. 특히 보안을 위해 OAUTH 2.0을 구현하는 RESTful 서버를 사용하는 경우 개발 및 유지 관리 비용을 절감 할 수있는 두 가지 근본적인 분리 문제가 발생합니다.

1. 이렇게하면 세션 (및 보안)이 SPA로 이동하고 모든 오버 헤드로부터 서버가 완화됩니다.
2. 귀하의 API는 안정적이고 쉽게 확장 가능합니다.

이전에 힌트를 얻었지만 명시 적으로 만들지 않았습니다. Android 및 Apple 응용 프로그램을 배포하는 것이 목표라면 브라우저 (Android 또는 Apple)에서 화면을 호스팅하기 위해 기본 호출로 래핑 된 JavaScript SPA를 작성하면 Apple 코드 기반과 Android 코드 기반을 모두 유지할 필요가 없습니다.

나는 이것이 오래된 질문이라는 것을 알고 있지만 단일 페이지 응용 프로그램의 또 다른 단점을 추가하고 싶습니다.

HTML과 같은 서식 언어가 아닌 데이터 언어 (예 : XML 또는 JSON)로 결과를 반환하는 API를 빌드하면 B2B (Business-to-Business) 응용 프로그램과 같은 응용 프로그램 상호 운용성이 향상됩니다. 이러한 상호 운용성에는 큰 이점이 있지만 사람들이 소프트웨어를 작성하여 데이터를 "채굴"(또는 훔칠) 수 있습니다. 이 특별한 단점은 일반적으로 SPA가 아닌 데이터 언어를 사용하는 모든 API에 공통적입니다 (실제로 서버에 사전 렌더링 된 HTML을 요청하는 SPA는이를 피하지만 모델 / 뷰 분리가 좋지 않음). 이러한 단점에 의해 노출되는 이러한 위험은 요청 제한 및 연결 차단 등과 같은 다양한 수단으로 완화 할 수 있습니다.