MPA/SPA

MPA (Multi Page Application)

● 여러 페이지로 구성된 웹 어플리케이션

● 새로운 페이지를 요청할 때마다 서버에서 렌더링된 정적 리소스(HTML, CSS, JS)가 다운로드 된다. 페이지를 이동하거나 새로 고침하면 전체 페이지를 렌더링한다.

● SSR 방식으로 렌더링

MPA의 장점

● SEO 과점에서 유리하다.
- MPA는 완성된 형태의 HTML 파일을 서버로부터 전달받는다. 따라서 검색 엔진이 페이지를 크롤링하기 적합하다.
● 첫 로딩이 매우 짧다.
- 서버에서 이미 렌더링해 가져오기 때문에 로딩 속도가 빠르다.
- But 클라이언트가 JS파일을 모두 다운로드하고 적용하기 전까지는 각각의 기능은 동작하지 않는다.

MPA의 단점

● 새로운 페이지를 이동하면 "깜빡"인다. (UX)
- 매 페이지를 요청마다 리로딩(새로고침) 발생. 새로운 페이지를 요청할 때마다 전체 페이지를 다시 렌더링하기 때문이다.
● 페이지 이동시 불필요한 템플릿도 중복해서 로딩 (성능)
●  서버 렌더링에 따른 부하
●  모바일 앱 개발시 추가적인 백엔드 작업 필요. 개발이 복잡해질 수 있음. (생산성)

 

---

 

SPA (Single Page Application)

● 하나의 페이지로 구성된 웹 어플리케이션

● 단 한 번만 리소스(HTML, CSS, JS) 로딩. 후에는 데이터를 받아올 때만 서버와 통신

∴ 첫 요청시 딱 한 페이지만 불러오고 페이지 이동 시 기존 페이지의 내부를 수정해서 보여주는 방식

● 현재 웹개발의 트랜드로 react, vue, 앵귤러와 같은 자바스크립트 프레임워크등이 spa방식을 지님

● CSR 방식으로 렌더링 (모두 SCR 방식으로 사용하지는 않음! 주의)

SPA의 장점

● 자연스러운 사용자 경험 (UX)
- 전체 페이지를 업데이트 할 필요가 없기 때문에 빠르고 "깜빡"거림이 없다.
● 필요한 리소스만 부분적으로 로딩 (성능)
- SPA의 Application은 서버에게 정적 리소스를 한 번만 요청한다. 그리고 받은 데이터는 전부 저장해놓는다.
● 서버의 템플릿 연산을 클라이너트로 분산 (성능)
● 컴포넌트별 새발 용이 (생산성)
● 모바일 앱 개발을 염두에 둔다면 동일한 API를 사용하도록 설계 가능 (생산성)
 

SPA의 단점

● JS 파일을 번들링해서 한 번에 받기 때문에 초기 구동 속도가 느리다 (Webpack의 code splitting로 해결 가능)
● 검색 엔진 최정화(SEO)가 어렵다. (SSR로 해결 가능) 
- Nuxt.js
● 보안 이슈 (프론트엔드 비지니스 로직 최소화)
- SSR에서는 사용자에 대한 정보를 서버측에서 세션으로 관리를 하지만 CSR 방식에서는 클라이언트측의 쿠키말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않다.