어제는 코로나 확진으로 몸이 너무 안 좋아서 쉬었고 TIL 13일차도 건너뛰었다. 오늘도 아직 컨디션이 좋진 않아서 집중있게 새로운 것을 공부할 상태는 안되었다. 어제 JS SPA특강을 다시 듣고 오늘 들은 특강에서 메모해놓은 것을 정리하려고 한다.
MPA (Multi Page Application)
탭을 이동할 때 클라이언트에서 요청하면 서버로부터 새 html 파일을 새로 받아와서 페이지 전체를 새로 렌더링하는 전통적인 웹페이지 구성 방식(SSR)
SPA는 헤더는 고정되고 일부분만 바뀌는 방식
처음에 index.html을 한번만 받고 그 다음부터는 CRUD로 서버와 티키타카 하면서 client 화면 렌더링(CSR)
SPA Lifecycle은 곧 CSR이지만 SPA가 곧 CSR은 아니라고 한다.. 이건 무슨 말일까?
(이부분은 아직 이해가 부족하여 들은 것과 찾아본 내용을 기반으로 정리했다. 추후 이부분에 대해 이해하게 되면 틀린 부분은 수정할 예정이다.)
SPA에서 routing을 지원하는 방법은 hashed url과 non-hashed url 방식이 있다.
이중 hashed url은 경로를 #(hash)로 구분하는데 브라우저는 hash값이 없는, hash 앞자리에 있는 url에 대해서만 호스팅 서버에 요청을 한다고 함. 해시(#)뒤에 값은 서버에 요청이 안 가고 local로 취급한다고 한다.
두 방식은 각각 장점이 있는데, non-hashed url의 경우 SEO 측면에서 hashed url보다 이점이 있고 hashed url은 #뒷부분을 별도의 페이지로 간주하지 않아 non-hashed에 비해 단일 페이지에 더 이상적이라고 한다.
그럼 왜 SPA에 Hashed Routing이 필요한가? 새로고침 했을 때 브라우저에서 자동으로 url을 기반으로 get요청을 서버에 하게 되는데 이때 발생하는 cannot GET 오류 때문이다. HTTP 상태 코드 200인 상태에서 새로고침하면 304가 뜨는데 이는 페이지 상태가 변경이 된 게 없다는 뜻으로 브라우저가 갖고있는 캐싱된 값을 사용하라고 지시하고 304코드를 던져주는 것이다. hashed 라우팅을 안 쓰면 새로고침 했을 때 이런 버그가 발생할 수 있다.
첫 랜딩 속도가 느림(한번에 모든 파일 다운하는 것을 Code Splitting해서 화면에 안보이는 부분은 lazy loading하는 것으로 해결)
SEO에 취약
검색엔진에는 크롤링 로봇밖에 없음
서버에서 주는 것만 크롤링 로봇이 볼 수 있다. (서버가 주는 index.html만 볼 수 있음) SEO 취약점은 next.js를 쓰면 보완할 수 있다고 함
보안 이슈
특정 사업 아이템의 특정 비즈니스 로직을 기존에는 서버에서 처리하다가 CSR을 하게 되면서 JSON파일 같은 것을 클라이언트에서 다루기 시작하면서 핵심 비즈니스 로직이 해커들에게 노출되기 쉬워졌다. 사용자 정보가 쿠키나 localstorage에 저장됨으로서 해커들에게 노출될 수 있다.
어제는 코로나로 몸상태가 너무 안 좋아서 행정처리하고 특강만 듣고 푹 쉬었고 오늘 그나마 좀 나아져서 git 강의 마저 듣고 특강듣고 했다. 이제 웹퍼블리싱 강의만 들으면 되는데 내일부터 당장 2차 프로젝트여서 당장은 프로젝트 진행에 집중해야할 것 같다.