웹

SPA

kicksky 2021. 5. 19. 19:04

유저 네비게이션에 서버 요청이 필요하지 않다. 초기 렌더링에 필요한 파일들을 제공할 서버가 필요하긴 하다. 웹 서버는 정적 컨텐츠를 제공하고, 어플리케이션 서버는 새로운 컨텐츠를 생성한다. 

정적 파일

요청된 위치에 리소스가 있을 경우에 성공적으로 응답. static host(깃헙 페이지, 아마존 S3)에 해당. 

동적 파일

이를테면 Express 같은 프레임워크는 요청에 일치하는 응답을 동적으로 만들어낸다. 어플리케이션 서버는 웹 서버의 프록시처럼 작동하는데, 웹 서버는 어플리케이션에 비정적 요청을 넘겨줄 뿐이다. 

"Many static file hosts allow you to set a "fallback" page to serve when there is a request for a page that you haven't generated content for. This allows the site to work without generating the content for every single possible URL, which is especially handy if you have pages that should always be generated on the client side."

 

URL가 해석되는 두 가지 장소. 예전에는 하나 뿐 - 서버 - 이었다. 클라이언트 사이드 라우팅의 경우, 첫 요청은 무조건 서버로 전송된다. 아직 JS 코드가 없기 때문에. 그 이후에 어떤 링크로 이동하고자 하면 URL은 History API에 의해 로컬에서만 변화한다. 서버로는 요청이 가지 않는다. 리액트 라우터는 클라이언트 사이드에서만 라우팅을 관장한다. a 링크를 클릭하면 자바스크립트가 실행되면서 주소창의 URL을 조작하지만 새로고침은 발생하지 않는다. 라우터가 클라이언트 사이드에서 페이지 전환을 수행할 뿐.

그러나 친구에게 링크를 보내고, 그 친구가 창을 열면 404가 뜬다. 아직 JS 파일이 로드되지 않은 채로 서버에 요청을 했기 때문이다. 이 경우에는 서버와 클라이언트 모두에서 제어를 해주어야 한다. 해결책은 Hash HistoryBrowser History 대신 Hash History. http://example.com/#/about #가 붙은 path는 서버로 요청이 가지 않는다. 서버는 그 앞 주소로만 요청이 가고 index page로 응답한다. 

 

예전에 정적 페이지 만들 때, /(index.html)가 아닌 주소로 직접 접근하는 케이스에 대해서 따로 설정을 해주었어야 했는데 이 내용과 관련 있는 듯 하다.

 

저작자표시 비영리 변경금지