포스트

2023-09-15-TIL

Today I Learned

SPA vs SSR

SPA(Single-Page Application)는 HTML 문서를 한 번만 받고, 이후에는 JavaScript가 필요한 데이터를 받아 화면을 바꾸는 방식이다. MDN은 페이지 전체를 새로 받지 않아서 빠르고 매끄러운 반면, 검색 엔진 최적화(SEO)가 어렵고 상태 관리와 내비게이션 구현에 손이 더 간다고 정리한다.

SSR(Server-Side Rendering)은 서버에서 HTML을 만들어 보내는 방식이다. MDN이 드는 장점은 세 가지다.

  • JavaScript가 실행되지 않는 환경에서도 내용은 보인다.
  • 검색 엔진이나 소셜 미디어 크롤러가 JavaScript를 실행하지 않고도 내용을 읽는다.
  • 서버가 필요한 데이터를 한 번에 가져올 수 있다. 클라이언트 렌더링에서는 화면을 그리면서 다음에 필요한 데이터를 알게 되어 요청이 줄줄이 이어지기 쉽다.

둘은 배타적이지 않다. MDN도 서버가 뼈대를 만들고 클라이언트가 나머지 데이터를 채우는 혼합 방식을 언급한다. 링크한 글도 SPA의 장단점을 정리한 뒤 Nuxt.js로 SSR을 도입하는 과정을 다룬다.

  • https://medium.com/aha-official/%EC%95%84%ED%95%98-%ED%94%84%EB%A1%A0%ED%8A%B8-%EA%B0%9C%EB%B0%9C%EA%B8%B0-1-spa%EC%99%80-ssr%EC%9D%98-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EA%B7%B8%EB%A6%AC%EA%B3%A0-nuxt-js-cafdc3ac2053

CORS

브라우저는 동일 출처 정책(same-origin policy)에 따라 스크립트가 다른 출처로 보내는 요청을 제한한다. 출처는 프로토콜, 호스트, 포트의 조합이다. CORS(Cross-Origin Resource Sharing)는 서버가 HTTP 헤더로 “이 출처의 요청은 허용한다”고 알려서 이 제한을 풀어 주는 방식이다(MDN CORS 가이드).

흐름은 요청 종류에 따라 다르다.

  • 단순 요청: 일정 조건을 만족하는 GET, HEAD, POST는 바로 보낸다. 브라우저는 응답의 Access-Control-Allow-Origin을 보고 스크립트에 결과를 넘길지 정한다.
  • 사전 요청(preflight): 그 밖의 요청은 브라우저가 먼저 OPTIONS 요청에 Access-Control-Request-Method, Access-Control-Request-Headers를 담아 보낸다. 서버가 Access-Control-Allow-Methods, Access-Control-Allow-Headers로 허용하면 그때 본 요청을 보낸다.

쿠키 같은 자격 증명을 함께 보내는 요청에서는 Access-Control-Allow-Origin: *를 쓸 수 없고 출처를 명시해야 한다. 그리고 CORS는 브라우저가 지키는 규칙이라서, 서버끼리 호출하거나 curl로 호출할 때는 적용되지 않는다. 백엔드에서 CORS 오류를 고친다는 말은 결국 이 응답 헤더를 올바르게 내려 준다는 뜻이다.

  • https://hannut91.github.io/blogs/infra/cors
이 글은 저작권자의 CC BY 4.0 라이선스를 따릅니다.

댓글

아직 댓글이 없습니다