웹 애플리케이션(Web Application) : 정적 페이지들 뿐 아니라 동적 페이지를 포함하면 웹 애플리케이션이 된다. 반대로 웹사이트는 정적 페이지의 집합체를 이야기 한다.
웹 애플리케이션 아키텍처 : 클라이언트-서버 간의 연결에 대한 설명 방법
웹 애플리케이션의 요청흐름
- 브라우저에 https://urclass.codestates.com 를 입력합니다.
- 브라우저는 URL을 입력 받으면 서버의 주소를 찾기 위해 DNS 서버에 요청을 보냅니다.
- IP 주소를 찾으면 해당 주소에 HTTPS 요청을 보냅니다. 이미 방문 기록이 캐시 메모리에 있으면 주소를 캐시 메모리에서 가져옵니다.
- 웹서버에 요청이 도착 합니다.
- 웹서버는 저장소에 요청을 보내 페이지 관련 데이터들을 가져옵니다.
- 정보들은 가져오는 중에 비지니스 로직이 작용합니다.
- 비지니스 로직들은 각 데이터들을 어떻게 다룰지가 정해져 있습니다.
- 로직들을 통해 요청 받은 데이터들이 처리되고 브라우저에 응답합니다.
- 요청들이 브라우저에 응답으로 돌아왔을 때, web page 화면에서 출력됩니다.
웹 애플리케이션의 3단계 계층 구조
- Presentation Layer: 이 계층은 유저와 브라우저 등을 이용해 직접적으로 접촉을 합니다. Web Server가 이 영역에 포함되며, 유저 인터페이스 요소들을 포함합니다.
- Application Layer: Business Layer, Business Logic 혹은 Domain Logic 이라고 불리기도 하는 이 영역은 유저의 요청을 브라우저로부터 받아서 처리를 합니다. Application Server가 이 계층에 포함되며 또한, 데이터 접근을 위한 경로를 규격화 하는 등의 과정이 이 계층에 작성이 됩니다.
- Data access layer: Persistence layer 라고도 불리는 이 계층은 애플리케이선의 데이터 저장소에 접근하여 데이터를 불러 오거나 저장을 담당 합니다. Application Layer 는 이 계층과 밀접한 연관을 가지고 있습니다. 이 단계를 통해 Application Layer 의 로직들은 어느 데이터베이스에 접근해서 데이터를 회수하고 혹은 저장할지를 더 최적화 할 수 있습니다.
- Cross-cutting: 이 요소들은 주로 보안, 통신, 운영 관리등을 위한 요소들입니다. 추후에 Spring 프레임 워크의 AOP 개념을 배우면서 더 자세한 내용을 배우게 됩니다.
- Third-party integrations: 제 3의 API 서비스를 이용하는 것을 의미 합니다. 예를 들면 OAuth 2.0을 이용한 소셜 로그인, PG 사를 이용한 결재기능 등이 여기에 속합니다.
쿠키와 세션
쿠키 : 웹 애플리케이션을 사용하는 유저의 정보를 클라이언트에 보관하고, 다음 접속부터는 유저의 정보를 클라이언트가 서버로 보내서 유저를 서버가 식별하게 합니다. 쿠키에 담긴 내용으로 웹 애플리케이션에 유저가 설정했던 항목들에 대해 저장을 해서 다음에 이어서 같은 방식으로 작동하게 도와줍니다.
세션 : 세션의 경우 서버에 Session-Id 라는 고유 아이디를 할당해서 유저를 식별합니다. 단순하고 유출이 되면 안되는 정보는 서버에서 관리를 하면서 세션 ID와 매칭해서 저장해 관리합니다. 주로 사용되는 방법은, 세션정보는 쿠키에서 관리하고, 실제 매칭되는 값들은 서버 측에서 관리하는 것이 일반적입니다.
SSR & CSR
- SSR : Server Side Rendering의 줄임말입니다. Javascript 가 웹 페이지를 브라우저에서 렌더링하는 대신에, 서버에서 렌더링합니다. 서버에서 웹 페이지를 브라우저로 보내기 전에, 서버에서 완전히 렌더링했기 때문에 Server Side Rendering 이라고 합니다. 웹 페이지의 내용에 데이터베이스의 데이터가 필요한 경우, 서버는 데이터베이스의 데이터를 불러온 다음 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답으로 보냅니다.
- CSR : CSR은 클라이언트에서 Javascript 가 페이지를 렌더링합니다.브라우저는 데이터베이스에 저장된 데이터를 가져와서 웹 페이지에 렌더링을 해야 합니다. 이를 위해 API가 사용됩니다. 웹 페이지를 렌더링하는 데에 필요한 데이터를 API 요청으로 해소합니다. 마지막으로, 브라우저가 다른 경로로 이동하면 어떻게 될까요?
CSR에서는 SSR과 다르게, 서버가 웹 페이지를 다시 보내지 않습니다. 브라우저는 브라우저가 요청한 경로에 따라 페이지를 다시 렌더링합니다. 이때 보이는 웹 페이지의 파일은 맨 처음 서버로부터 전달받은 웹 페이지 파일과 동일한 파일입니다. CSR에서는 서버가 클라이언트에 필요한 데이터만 넘겨주기 때문에 부담이 적습니다.
-> 주요 차이점은 페이지가 렌더링되는 위치입니다. SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링합니다.
Use SSR
- SEO(Search Engine Optimization) 가 우선순위인 경우, 일반적으로 SSR(Server Side Rendering) 을 사용합니다.
- 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우에도, 단일 파일의 용량이 작은 SSR 이 적합합니다.
- 웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용할 수 있습니다.
Use CSR
1. SEO 가 우선순위가 아닌 경우, CSR을 이용할 수 있습니다.
사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공합니다.
2. 웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공할 수 있습니다.
Risks of SSR
- 자원이용이 서버에 집중되기 때문에 애플리케이션 유지비용이 높습니다.
- 일부 서드파티 자바스크립트 라이브러리의 경우 서버사이드 렌더링이 불가능할 수 있습니다.
Risks of CSR
- 느린 렌더링 속도로 사용자 경험이 안 좋아 질 수 있습니다. 모든 렌더링의 부하가 클라이언트 쪽에 집중되기 때문에 사용자에 따라서 경험이 달라질 수 있습니다.
- 위에서 설명했듯 search engine bots 와 상성이 안좋습니다. Javascript가 렌더링해야 하는 정보들은 Google 과 같은 search engine index에 포함이 안될 가능성이 매우 높습니다.
