단일 페이지 응용 프로그램: 장점과 단점

단일 페이지 응용 프로그램: 장점과 단점

닫았습니다. 이 질문은의견 기반의현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하시겠습니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트하십시오.

6년 전에 문을 닫았어요

이 질문을 개선하다

SPA에 대해 읽은 적이 있는데 그 장점입니다.나는 그들 대부분이 납득할 수 없다고 생각한다.나의 의구심을 불러일으키는 3가지 장점이 있다.

질문:. SPA의 주창자로서 제가 처음 세 가지 진술에 대해 틀렸다는 것을 증명해 주실 수 있습니까?

                              === ADVANTAGES ===

1. SPA는 응답성이 뛰어난 사이트에 매우 적합합니다.

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

단일 페이지 앱은 HTML을 검색하기 위해 서버 라운드 트립 없이 UI의 일부를 다시 그릴 수 있는 기능으로 구분됩니다.이것은 데이터를 처리하는 모델 레이어와 모델에서 읽어내는 뷰 레이어를 가지는 것으로, 데이터의 표시로부터 데이터를 분리하는 것에 의해서 실현됩니다.

SPA 이외의 모델레이어를 보유하면 어떤 문제가 있습니까?클라이언트 측 MVC와 호환되는 아키텍처는 SPA뿐입니까?

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

하하, 그리고 사용자가 당신의 사이트를 방문하는 동안 몇 페이지나 다운로드할 수 있나요?둘, 셋?대신 다른 보안 문제가 발생하여 로그인 페이지, 관리 페이지 등을 다른 페이지로 분리해야 합니다.다음으로 SPA 아키텍처와 경합합니다.

3. 다른 장점이 있습니까?다른 얘기는 듣지 마..

                            === DISADVANTAGES ===

1. 클라이언트는 javascript를 활성화해야 합니다.
2. 사이트에 대한 진입점은 1개뿐입니다.
3. 보안.

추신: 저는 SPA 프로젝트와 SPA 이외의 프로젝트에서 일한 적이 있습니다.그리고 나는 이해를 깊게 할 필요가 있기 때문에 그런 질문을 한다.SPA 서포터를 해칠 의도는 없습니다.SPA에 대해 좀 더 읽어보라고 하지 마세요.저는 그것에 대한 당신의 배려를 듣고 싶습니다.

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

1. SPA는 응답성이 뛰어난 사이트에 매우 적합합니다.

서버 측 렌더링은 URL에서 #HESTHate를 유지하거나 최근 HTML5 푸시 상태를 유지하는 데 사용할 수 없습니다.웹 앱의 정확한 상태는 페이지 URL에 내장되어 있는 웹 앱 URL에 내장되어 있는 경우 다른 브라우저 URL에 추가 해시 태그를 추가할 수 있습니다.동일한 메일(인증 가능한 경우)입니다.이 접근법은 보다 전통적인 쿼리 문자열에 직접 매핑되며, 그 차이는 실행에만 있습니다.HTML5 pushState()를 사용하면, 다음의 URL 에 액세스 할 수 있습니다.#hash첫 번째 요청 시 서버에서 해결한 후 다음 요청 시 Ajax를 통해 로드할 수 있는 완전히 클래식한 URL을 사용합니다.

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

내 웹 사이트에 접속하는 동안 사용자가 다운로드하는 페이지 수?메일 계정을 열 때 몇 개의 메일을 읽는지 알 수 있습니다.나는 단번에 50엔을 읽는다.이제 메일의 구조는 거의 같다.서버측 렌더링 스킴을 사용하는 경우, 서버는 모든 요구(대소문자)에서 렌더링합니다.- 보안에 관한 문제 - 사이트 구조에 따라 완전히 다른 관리자/관리자에 대해 별도의 페이지를 보관해야 합니다.예를 들어, paytm.com을 참조해 주세요.또한 웹사이트 SPA를 작성한다고 해서 모든 사용자의 엔드포인트를 오픈하는 것은 아닙니다.즉, 저는 SPA 웹사이트에서 폼을 사용하여 인증합니다.- 가장 많이 사용되는 SPA 프레임워크에서는 Angul을 사용하고 있습니다.ar JS 개발은 사용자 인증 수준에 따라 웹 사이트에서 전체 html 템플을 로드할 수 있습니다.모든 인증 유형에 대해 html을 프리로드하는 것은 SPA가 아닙니다.

3. 다른 장점이 있나요?다른 얘기는 듣지 마..

• 요즘에는 클라이언트가 Javascript를 사용할 수 있는 브라우저를 가지고 있다고 가정할 수 있습니다.
• 사이트의 진입점은 하나뿐입니다.앞서 말씀드린 바와 같이 원하는 수의 진입점을 가질 수 있지만, 반드시 보유해야 합니다.
• SPA 사용자에게도 적절한 권한이 있는지 확인할 수 있습니다.모든 것을 한꺼번에 주입할 필요는 없습니다.diff html 템플릿 및 javascript 비동기 로드도 SPA의 유효한 부분입니다.

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

1. 렌더링 html은 분명히 약간의 리소스를 필요로 합니다.현재 사이트를 방문하는 모든 사용자가 이 작업을 수행하고 있습니다.또, 메이저 로직의 렌더링 뿐만이 아니라, 서버측도 아닌 클라이언트측도 가능하게 되었습니다.
2. 날짜 시간 문제 - 클라이언트에 UTC 시간은 미리 설정된 형식이며 javascript에 의해 처리되는 시간대는 신경 쓰지 않습니다.이것은 사용자 IP에서 도출된 위치에 따라 시간대를 추측해야 하는 큰 장점입니다.
3. 변수를 설정하면 SPA가 존재함을 알 수 있기 때문에 SPA에서 보다 적절하게 유지됩니다.웹페이지가 아니라 앱을 개발하는 느낌을 준다.이것은 일반적으로 푸드팬다, 플립카트, 아마존과 같은 사이트를 만드는 데 많은 도움이 됩니다. 왜냐하면 클라이언트 측 상태를 사용하지 않으면 비싼 세션을 사용하기 때문입니다.
4. 웹사이트는 확실히 매우 반응적이다 - SPA 이외의 웹사이트에서 계산기를 만들어보는 극단적인 예를 들어보자(이상하다는 것을 알고 있다).

코멘트로부터의 갱신

소켓과 롱폴링에 대해 언급한 사람은 없는 것 같습니다.다른 클라이언트에서 mobile app이라고 로그아웃하면 브라우저도 로그아웃해야 합니다.SPA를 사용하지 않을 경우 리다이렉트가 있을 때마다 소켓 연결을 다시 작성해야 합니다.통지, 프로파일 갱신 등 데이터의 갱신에도 대응할 수 있습니다.

또 다른 관점: 웹 사이트 외에 프로젝트에 네이티브 모바일 앱이 포함되어 있습니까?그렇다면 서버(JSON)에서 해당 네이티브 앱에 원시 데이터를 공급하고 렌더링하기 위해 클라이언트 측 처리를 수행할 가능성이 높습니다.이 어설션에서는 이미 클라이언트 측 렌더링 모델을 사용하고 있습니다.이제 문제는 프로젝트의 웹 사이트 버전에 동일한 모델을 사용하면 안 되는가 하는 것입니다.그건 쉬운 일이야.다음으로 서버 사이드 페이지를 SEO의 이점과 공유 가능/북마킹 가능 URL의 편리성만을 위해 렌더링할 것인지의 문제가 됩니다.

저는 실용주의자이기 때문에 비용이나 이익에 대해 생각해 보겠습니다.

어떤 불이익을 주더라도 해결할 수 있다는 것을 알고 있습니다.그렇기 때문에 저는 어떤 것도 흑백으로 보지 않고 비용과 이익으로 봅니다.

이점

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

단점들

• 퍼포먼스 감시 - 손발이 묶인 상태:지금까지 본 대부분의 브라우저 레벨 퍼포먼스 감시 솔루션은 페이지 로드 시간(첫 바이트까지의 시간, DOM 구축 시간, HTML 네트워크 라운드 트립, 온로드 이벤트 등)에만 초점을 맞추고 있습니다.AJAX를 통한 페이지 포스트 로드 업데이트는 측정되지 않습니다.링크를 클릭하고 타이머를 시작한 다음 AJAX 결과를 렌더링한 후 타이머를 종료하고 피드백을 전송하는 등 코드를 계측할 수 있는 솔루션이 있습니다.예를 들어 New Relic은 이 기능을 지원합니다.SPA를 사용하면 사용 가능한 툴은 몇 가지뿐입니다.
• 보안/침투 테스트 - 손이 묶인 상태:페이지 전체가 SPA 프레임워크에 의해 동적으로 작성되면 자동 보안 스캔으로 링크 검출이 어려워질 수 있습니다.이에 대한 해결책이 있을 수 있지만, 다시 한 번 말하지만, 당신은 스스로를 제한하고 있습니다.
• 번들링:초기 페이지 로드에 웹 사이트 전체에 필요한 모든 코드를 다운로드하면 저대역폭 접속 시 성능이 저하될 수 있습니다.JavaScript 파일과 CSS 파일을 번들하여 보다 자연스러운 청크로 로드하려고 할 수 있지만, 현재는 매핑을 유지하고 의도하지 않은 파일이 실현되지 않은 의존관계에 의해 수집되지 않도록 주의할 필요가 있습니다(그것은 나에게 일어난 일입니다).역시 해결은 가능하지만 비용이 듭니다.
• 빅뱅 리팩터링:예를 들어 어떤 프레임워크에서 다른 프레임워크로 전환하여 위험을 최소화하는 등 아키텍처에 큰 변경을 가하는 것이 바람직합니다.즉, 새로운 것을 사용하기 시작하고, 페이지 단위, 기능 단위 등 어떤 형태로든 이행한 후 오래된 것을 폐기합니다.기존의 여러 페이지 앱에서는 한 페이지를 Angular에서 React로 전환한 후 다음 스프린트에서 다른 페이지를 전환할 수 있습니다.SPA에서는 모든 것이냐, 아니면 아무것도 아니다.변경하려면 어플리케이션 전체를 한꺼번에 변경해야 합니다.
• 내비게이션의 복잡성:툴링은 history.js, Angular 2와 같은 SPA의 네비게이션 컨텍스트를 유지하기 위해 존재하며 대부분은 URL 프레임워크(#) 또는 새로운 이력 API에 의존합니다.모든 페이지가 개별 페이지였다면, 그런 것은 필요 없습니다.
• 코드 파악의 복잡성:우리는 당연히 웹 사이트를 페이지라고 생각한다.다중 페이지 앱은 보통 페이지별로 코드를 분할하므로 유지보수에 도움이 됩니다.

다시 말씀드리지만, 이 모든 문제들은 어떤 대가를 치르더라도 해결할 수 있다는 것을 알고 있습니다.하지만 애초에 피할 수 있었던 문제를 해결하는 데 모든 시간을 소비하게 되는 순간이 온다.그것은 다시 이익과 그것이 당신에게 얼마나 중요한지에 관한 것입니다.

단점들

1. 클라이언트는 javascript를 활성화해야 합니다.네, 이것은 SPA의 명백한 단점입니다.내 경우 사용자가 JavaScript를 사용하도록 설정할 수 있습니다.할 수 없는 경우는 SPA를 할 수 없습니다.이는 를 도입하려고 하는 것과 같습니다.를 사용하지 않는 머신에 NET 앱을 설치합니다.NET Framework가 설치되어 있습니다.

2. 사이트 진입점은 1개뿐입니다.나는 새미를 이용해서 이 문제를 해결한다.JS. 루팅을 올바르게 설정하기 위해 2~3일 동안 작업하면 사람들은 앱에 올바르게 작동하는 딥링크 북마크를 만들 수 있습니다.서버는 하나의 엔드포인트, 즉 "이 앱의 HTML + CSS + JS 제공" 엔드포인트(이 엔드포인트는 미리 컴파일된 응용 프로그램의 다운로드/업데이트 위치로 간주)만 노출하면 됩니다.또한 작성한 클라이언트 측 JavaScript는 응용 프로그램의 실제 엔트리를 처리합니다.

3. 보안이 문제는 SPA만의 문제가 아닙니다.「구식」클라이언트 서버 애플리케이션(HATEOAS 모델)을 사용하고 있는 경우, 시큐러티에 대해서는, 완전하게 같은 방법으로 대처할 필요가 있습니다(HATEOAS 모델에서는, Hypertext 를 사용해 페이지간에 링크 합니다).사용자가 JavaScript가 아닌 요청을 하고 결과가 JSON이나 일부 데이터 형식이 아닌 HTML 형식일 뿐입니다.SPA가 아닌 앱에서는 서버 상의 개별 페이지를 보호해야 하는 반면 SPA 앱에서는 데이터 엔드포인트를 보호해야 합니다(클라이언트가 모든 코드에 액세스하지 않으려면 다운로드 가능한 JavaScript도 다른 영역으로 분할해야 합니다).단순히 새미JS 기반 라우팅 시스템에 연결하기만 하면 브라우저는 사용자 역할의 초기 로드에 따라 클라이언트에 액세스 권한이 있다고 알고 있는 항목만 요구할 수 있습니다.그것은 문제가 되지 않습니다.)

이점

1. SPA(대부분 언급되지 않는)의 주요 아키텍처상의 이점은 앱의 "조용함"이 크게 감소한다는 것입니다.클라이언트(결국 전체)의 대부분의 처리를 적절히 처리하도록 설계하면 서버에 대한 요구 수('사용자 경험을 파괴하는 503 오류 가능성' 읽기)가 대폭 줄어듭니다.실제로 SPA를 사용하면 완전히 오프라인 처리를 할 수 있습니다.상황에 따라서는 매우 큰 처리가 가능합니다.

2. 올바르게 하면 클라이언트 측 렌더링이 확실히 퍼포먼스가 향상되지만 이것이 SPA를 구축하는 가장 설득력 있는 이유는 아닙니다(네트워크 속도는 결국 향상되고 있습니다).SPA에 대해서는 이것만으로 설명하지 마십시오.

3. UI 디자인의 유연성은 제가 발견한 또 다른 큰 장점입니다.API(JavaScript SDK)를 정의하면 정적 자원 파일을 제외하고 서버에 대한 영향 없이 프런트 엔드를 완전히 다시 작성할 수 있었습니다.기존 MVC 앱을 사용해 보세요! :) (이는 API의 라이브 전개와 버전 정합성이 우려되는 경우에 중요합니다.)

결론은 다음과 같습니다.오프라인 처리를 필요로 하는 경우(또는 적어도 때때로 서버가 정지되는 경우에도 클라이언트가 생존할 수 있도록 하고 싶은 경우) 하드웨어 비용을 대폭 절감합니다.또한 JavaScript와 최신 브라우저를 상정할 수 있는 경우에는 SPA가 필요합니다.다른 경우에는 트레이드오프에 가깝습니다.

SPA의 주요 단점 중 하나는 SEO입니다.최근에야 구글과 빙이 크롤링 중에 JavaScript를 실행함으로써 Ajax 기반 페이지의 인덱싱을 시작했지만, 여전히 많은 경우 페이지가 잘못 인덱싱되고 있습니다.

SPA를 개발하는 동안 SEO 문제를 처리해야 합니다.아마도 모든 사이트를 렌탈하고 크롤러가 사용하기 위한 정적 HTML 스냅숏을 작성해야 합니다.이를 위해서는 적절한 인프라스트럭처에 대한 확실한 투자가 필요합니다.

업데이트 19.06.16:

이 답변을 작성한 지 얼마 되지 않아 싱글 페이지 앱(즉, AngularJS 1.x)에 대한 경험이 많아졌기 때문에 공유할 정보가 더 많아졌습니다.

SPA 어플리케이션의 가장 큰 단점은 SEO로, 일종의 "대시보드" 어플리케이션에만 한정되어 있다고 생각합니다.또한 기존 솔루션에 비해 캐싱이 훨씬 더 어려워집니다.예를 들어 ASP에서.NET 캐싱은 매우 간단합니다.OutputCaching을 켜기만 하면 됩니다.HTML 페이지 전체가 URL(또는 기타 파라미터)에 따라 캐시됩니다.단, SPA에서는 (세컨드레벨 캐시, 템플릿캐싱 등의 솔루션을 사용하여) 직접 캐싱을 처리해야 합니다.

SPA가 데이터 기반 어플리케이션에 가장 적합하다는 것을 증명하고 싶습니다.gmail은 물론 데이터에 관한 것이므로 SPA에 적합한 후보입니다.

그러나 대부분의 페이지가 서비스 조건 페이지 등 표시용인 경우 SPA는 완전히 오버킬됩니다.

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

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

이 시나리오는 플래시를 사용하는 것과 약간 비슷합니다.몇 년간의 경험을 통해 로드 팩터로 인해 플래시 전용 사이트의 수가 거의 0에 가깝게 감소했습니다.그러나 페이지 구성 요소로는 아직 사용 중입니다.

서버가 24시간 365일 모드로 최대 용량으로 가동되고 있는 구글, 아마존 등의 기업에게 트래픽 감소는 하드웨어, 에너지, 유지 보수 비용 절감이라는 실질적인 효과를 가져옵니다.CPU 사용률을 서버에서 클라이언트로 이행하면 효과가 있어 SPA가 빛납니다.장점들이 단점을 훨씬 능가한다.따라서 SPA의 유무는 사용 사례에 따라 크게 달라집니다.

SPA의 또 다른 (웹 개발자에게는 그다지 명확하지 않은) 사용 사례를 언급하는 것만으로 저는 현재 임베디드 시스템과 브라우저 기반 아키텍처에 GUI를 구현하는 방법을 찾고 있습니다.기존에는 임베디드 시스템(Java, Qt, wx 등) 또는 자체 상용 프레임워크에서 UI를 사용할 수 있는 가능성은 많지 않았습니다.몇 년 전 Adobe는 플래시를 사용하여 시장에 진입하려고 했지만 그다지 성공적이지 않은 것 같습니다.

오늘날에는 "임베디드 시스템"이 몇 년 전 메인프레임만큼 강력하기 때문에 REST를 통해 제어 장치에 연결된 브라우저 기반 UI가 가능한 솔루션입니다.장점은 UI용 툴 팔레트를 무료로 사용할 수 있다는 것입니다.(예를 들어 Qt는 로열티 수수료로 판매 유닛당 20~30달러 + 개발자당 3000~4000달러 필요)

SPA는 이러한 아키텍처에 대해 데스크톱 애플리케이션 개발자에게 보다 익숙한 개발 접근 방식, 서버 액세스 감소 등 많은 이점을 제공합니다(자동차 업계에서는 UI와 시스템이 혼재하는 경우가 많으며 시스템 부품에 RT OS가 있습니다).

클라이언트는 내장 브라우저뿐이기 때문에 JS 가용성, 서버 측 로깅, 보안 등의 단점은 더 이상 고려되지 않습니다.

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

아직 많이 배워야 하는데 SPA에 대해 배우기 시작하면서부터 SPA가 너무 좋아졌어요.

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

SPA가 아닌 많은 웹 앱에서는 여전히 콘텐츠를 검색하여 Ajax 요청을 만드는 페이지에 추가합니다.SPA는 단순히 Ajax를 사용하여 검색 및 표시하는 콘텐츠가 페이지 전체일 경우 어떻게 해야 합니까?페이지의 일부만 있는 게 아니라요?

시나리오를 제시하겠습니다.2페이지로 구성되어 있습니다.

1. 제품 목록이 있는 페이지
2. 특정 제품의 상세 내용을 볼 수 있는 페이지

리스트 페이지라고 생각해 주세요.그런 다음 제품을 클릭하여 세부 정보를 봅니다.클라이언트 측 앱은 2개의 Ajax 요청을 트리거합니다.

1. 제품 세부 정보와 함께 json 개체를 가져오라는 요청
2. 제품 상세 내용을 삽입할 HTML 템플릿을 얻기 위한 요청

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

그런 다음 목록으로 돌아가서 다른 제품을 엽니다.이번에는 상품 상세 정보를 얻기 위한 Ajax 요청만 있을 것입니다.html 템플릿은 동일하므로 다시 다운로드할 필요가 없습니다.

SPA가 아닌 경우 제품 상세 내역을 열었을 때 요청은 1개뿐이며 이 시나리오에서는 2개를 수행했다고 할 수 있습니다.네. 하지만 전체적인 관점에서 보면 여러 페이지를 이동하면 요청 수가 줄어들 것입니다.또한 html 템플릿이 재사용되기 때문에 클라이언트 측과 서버 간에 전송되는 데이터도 낮아집니다.또한 모든 페이지에 있는 모든 css, 이미지, javascript 파일을 모든 요청에 다운로드 할 필요는 없습니다.

또한 서버 사이드 언어는 Java라고 가정합니다.앞서 말한 2개의 요구를 분석하면 1개의 데이터 다운로드(뷰 파일을 로드하여 뷰 렌더링 엔진을 호출할 필요가 없음)와 기타 다운로드 및 스태틱HTML 템플릿을 분석하면 Java 어플리케이션 서버를 호출하지 않고 직접 취득할 수 있는HTTP 웹 서버를 가질 수 있으므로 계산이 이루어지지 않습니다.

마지막으로 페이스북, GMail, 아마존 등 대기업들이 SPA를 이용하고 있습니다.그들은 놀지 않고, 이 모든 것을 연구하는 최고의 엔지니어가 있다.따라서 이점을 잘 모르겠다면 처음에는 신뢰할 수 있으며 나중에 발견하기를 희망할 수 있습니다.

단, 적절한 SPA 설계 패턴을 사용하는 것이 중요합니다.AngularJS와 같은 프레임워크를 사용할 수 있습니다.적절한 설계 패턴을 사용하지 않고 SPA를 실장하려고 하지 마십시오.결국 문제가 발생할 수 있습니다.

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

• a) 보안:단일 페이지 애플리케이션은 사이트 간 스크립팅(XSS)으로 인해 기존 페이지에 비해 보안성이 떨어집니다.
• b) 메모리 리크:JavaScript의 메모리 누수로 인해 강력한 컴퓨터의 성능이 저하될 수도 있습니다.기존 웹사이트는 페이지 사이를 이동하도록 장려하기 때문에 이전 페이지로 인해 발생한 메모리 누수는 거의 지워지지 않고 남아 있습니다.
• c) 클라이언트는 SPA를 실행하기 위해 JavaScript를 활성화해야 하지만 여러 페이지 어플리케이션에서는 JavaScript를 완전히 회피할 수 있습니다.
• d) SPA가 최적의 크기로 확장되어 대기시간이 길어집니다.예: 연결 속도가 느린 Gmail에서 작업합니다.

위 외에도 네비게이션 데이터 손실, 브라우저에 네비게이션 이력 로그 없음, 셀레늄을 사용한 자동 기능 테스트의 어려움 등 아키텍처상의 제약이 있습니다.

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

서버측에서 보안 및 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) 응용 프로그램에서 응용 프로그램의 상호 운용성이 향상됩니다.이러한 상호 운용성에는 큰 이점이 있지만, 데이터를 「마이닝」(또는 도용)하기 위한 소프트웨어를 작성할 수 있습니다.이 특별한 단점은 데이터 언어를 사용하는 모든 API에서 공통적으로 발생합니다.일반적으로 SPA에는 해당되지 않습니다(실제로 서버에 사전 렌더링된HTML을 요구하는SPA는 이를 회피하지만 모델과 뷰의 분리가 불충분합니다).이 단점에 의해 노출되는 이러한 위험은 요청 제한 및 연결 차단 등 다양한 방법으로 완화될 수 있습니다.

개발 과정에서 SPA를 사용하는 두 가지 뚜렷한 이점을 발견했습니다.그렇다고 해서 기존의 웹 앱에서 다음과 같은 것을 얻을 수 있는 것은 아닙니다.단, 추가 단점을 도입하지 않고 증분적인 이점을 볼 수 있습니다.

• 새로운 콘텐츠를 렌더링하는 것이 항상 새로운 html 페이지에 대한 http 서버 요청은 아니므로 서버 요청 수를 줄일 수 있습니다.그러나 새로운 콘텐츠는 데이터를 가져오기 위해 Ajax 호출이 쉽게 필요할 수 있지만 데이터가 자체 및 마크업보다 점차 가벼워지기 때문에 순이익이 발생할 수 있기 때문에 가능성이 있다고 생각합니다.

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

JS를 요구하는 것(Web 앱에 미친 것이 아님) 외에 SPA에 한정되지 않거나 좋은 습관과 개발 패턴을 통해 완화될 수 있다고 생각합니다.

언급URL : https://stackoverflow.com/questions/21862054/single-page-application-advantages-and-disadvantages