[특강] 자바스크립트 SPA(Single Page Application)

1. 웹 트렌드

~1990년대 중반 : 정적 웹 페이지(Static Sites)

사용자가 특정 사이트에 접속(요청)하게 되면 서버에 이미 잘 만들어져서 배포되어 있는 HTML 문서를  서버에서 받아와 보여주는 형식이다. 정적 페이지이기 때문에 페이지 내의 다른 링크를 클릭하게 되면 다시 서버에서 해당 HTML 파일을 받아와 페이지 전체가 업데이트 되어야 하기 때문에 사이트가 뚝뚝 끊기는 느낌이 들고 사용성이 떨어진다.

 

1996년 ifram 태그 도입

문서 내에 또 다른 문서를 담을 수 있는 ifram 태그가 도입이 되어
이 때부터는 페이지 내에서 부분적으로 문서를 받아와 업데이트 할 수 있게 되었다.

 

1998년 XMLHttpRequest

fetch API의 원조 XMLHttpRequest API가 개발되어 HTML 문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 필요한 데이터만 받아 올 수 있게 되었다. 그 데이터를 자바스크립트를 이용해 동적으로 HTML 요소를 생성해 페이지에 업데이트하는 방식이다.

 

2005년 AJAX

XMLHttpReqeust와 같은 방식이 공식적으로 AJAX라는 이름을 갖게 되었다.
구글에서도 Gmail, 구글맵과 같은 웹 어플리케이션을 만들기 시작했다.
이것이 현재 널리 쓰이고 있는 SPA(Single Page Application)이다.

---

2. What is SPA?

SPA를 이해하려면 전통적인 방식인 MPA를 이해해야 한다.

MPA
Multi Page application 즉 여러개의 페이지로 구성된 어플리케이션이다.
(위의 이미지에서 Traditional Page LifeCycle)
MPA는 새로운 페이지를 요청할 때마다 정적 리소스가 다운로드 되고, 그에 맞춰 전체 페이지를 다시 렌더링 한다.
인터넷 주소창에 주소를 입력하거나, 링크를 클릭하는 등 사용자가 어떤 요청을 하면 그에 맞는 html, 이미지 등의 파일들이 전부 다운로드 되고 재 렌더링(화면에 보여주는 것)된다.
MPA는 클라이언트가 서버에게 Initial Request를 하면 HTML을 받는다.
'page reload'를 요청하면(post 방식으로), 다시 HTML을 받는다.

SPA
Single Page application 웹 애플리케이션에 필요한 모든 정적 리소스를 최초 한번에 다운로드한 후
이후에 새로운 페이지 요청이 있을 경우, 페이지 갱신에 필요한 데이터만 전달받아 페이지를 갱신한다.
어떤 링크를 클릭한다고해서 그에 관련된 모든 파일을 다운받는게 아니라 필요한 정보만 받아서 그 정보를 기준으로 업데이트 된다.
SPA는 클라이언트가 서버에게 Initial Request를 하면 HTML을 받는다.
다만, 추가적인 요청은 AJAX를 통해 JSON 데이터를 받아서 업데이트할 뿐이다!

SPA를 클라이언트 사이드 렌더링(CSR : Client Side Rendering) 방식,
MPA를  서버 사이드 렌더링(SSR: Server Side Rendering)방식 이라고 한다.

 

3. CSR / SSR

CSR
Client Side Rendering, 클라이언트 쪽에서 대부분의 일을 하는 것을 말한다. 렌더링이 SSR과 달리 클라이언트에서 일어난다. 즉, 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다.

SSR
Server Side Rendering, 서버 쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식

 

4. Hashed 라우팅

Hashed url path

const url = new URL('https://developer.mozilla.org/en-US/docs/Web/API/URL/href#Examples');

위와 같이 해시(#)가 들어가 있는 경로를 말한다.  해시 앞까지만 호스팅 서버에 (데이터)요청함
url 경로를 #(해시)로 브라우저가 페이지나 웹사이트의 특정 지점을 가리키도록 한다.

장점
- 브라우저는 해시 이후의 경로를 별도의 페이지로 간주하지 않는다. 새로 고침 하면 index.html이 되므로 SPA에 적합하다.
- 프론트엔드에서 해시로 링크를 정의하면 페이지를 다시 로드하지 않아 안전하다.
- 서버 구성은 간단하고 API와 프론트엔드 요청을 구분하기가 쉬워진다.

단점
- 가장 큰 단점은 외관이다. 일부 사용자는 비정상적이라고 생각할 수 있다.
- SEO에 적합하지 않다.

Non-hashed url path
일반 url 경로를 말한다.

 

왜 SPA에서는 Hashed url path가 적용돼야 하는지?

새로고침했을 때 의도하지 않은 에러(404)를 만나지 않도록하기 위함

 

 

참고자료

https://proglish.tistory.com/216

https://velog.io/@thms200/SPA-vs.-MPA

https://www.youtube.com/watch?v=iZ9csAfU5Os 

https://blog.bitsrc.io/using-hashed-vs-nonhashed-url-paths-in-single-page-apps-a66234cefc96