클라이언트 — 서버(2티어 아키텍쳐)
두 개의 주요 구성 요소인 클라이언트와 서버로 구성된다. 이 아키텍쳐에서
클라이언트는 사용자 인터페이스 UI 를 담당하고,
서버는 데이터 처리 및 비즈니스 로직을 처리한다.
(비즈니스 로직 이란 예를 들어 은행 앱에서 계좌 개설, 입출금에서 계좌 개설 시 유효성 검사, 잔액 확인,
입출금 처리, 이체처리 등 사용자의 요청에 따라 앱이 적절한 조치릴 취하고 데이터를 처리하는 것)
리소스를 사용하는 앱 → 클라이언트(웹 사이트, 웹 앱…)
리소스를 제공하는 곳 → 서버(데이터베이스, 파일 서버, 메일 서버…)
클라이언트—서버 통신과 API
서버는 클라이언트에서 요청하지 않는 이상 아무런 정보를 전달하지 않는다.
클라이언트가 서버에 요청을 할때 아무런 규약없이 정보를 주고 받는다면 호환성, 보안성등의 문제가 발생한다.
이러한 문제를 해결하기 위해 데이터 교환 방식을 정의하는 규칙 체계를 프로토콜이라고 한다.
이때 클라이언트와 서버와의 통신에서 클라이언트가 올바르게 서버에게 요청을 할 수 있도록 인터페이스를 API라고 한다. (REST API, JSON API, GraphQL등)
URL → secheme, hosts, url-path
URI → secheme, hosts, url-path + query, fragment
URL보다 URI가 좀 더 상위 개념이다.
https://search.naver.com/search.naver?where=nexearch&sm=top_hty&fbm=0&ie=utf8&query=코드스테이츠
위 링크를 정리해보면
| scheme(프로토콜) | https:// (https프로토콜 사용) |
|---|---|
| hosts(도메인) | http://search.naver.com (네이버 검색 호스트) |
| port(포트번호) | 따로 지정하지 않았으니 (443) |
| url-path(루트 디렉토리부터의 경로) | /search,naver |
| query(웹 서버에 질문할 내용) | where=nexearch&sm=top_hty&fbm=0&ie=utf8&query= |
IP는 특정 pc의 주소 체계, port는 그 주소체계로 들어갈때의 정해진 통로이다.
프로토콜, 도메인, IP, PORT를 비유로 설명해보자면
우편을 보내고자 한다.
이때 우편에 정해진 방식 (프로토콜) 으로 우편을 작성하고 도로명 주소 (도메인) 와 상세 주소 몇 동 몇 호 (포트) 까지 적어서 보낸다.(이때 IP 는 우편의 목적지의 실제 좌표나 지리적인 정보이다)
HTTP(프로토콜)
HTTP는 이전 상태에 대한 정보를 저장하지 않는다는 것이 특징이다.
우리가 음식점에서 음식을 시킬 때 매 주문마다 매번 새로운 주문을 해야 한다.
전에 주문했던 내용을 저장하지 않는 다는 것이다. 이러한 점 때문에 서버 자원의 절약과 확장성을 높여준다.
HTTP의 메서드에는 GET, POST, PUT, DELETE등 이 있다.
HTTP 요청
헤더 → 인증 정보, 요청 본문의 데이터 타입…
본문 → 요청 데이터, JSON데이터 요청
HTTP 응답
상태 코드 : 200, 404, 500
헤더 → 응답에 대한 추가 정보, 데이터 타입….
본문 → 본문 요청 처리 결과
SSR(Server Side Rendering)
말 그대로 서버에서 렌더링해서 보여준다.
동적 기능보다 정적 기능을 우선시 하고 그렇기 때문에 파일의 용량이 작다.
웹 페이지의 상호작용이 적고, 첫화면의 렌더링이 빨라야 할 경우 SSR추천
(전통적인 블로그 플랫폼)
CSR(Client Side Rendering)
말 그대로 클라이언트에서 렌더링해서 보여준다.
정적 기능 보다 동적 기능을 우선시 하고 그렇기 때문에 파일의 용량이 크다.
웹 페이지의 상호작용이 많고 사용자 경험을 중요시 하면 CSR추천
(싱글 페이지 어플리케이션)
