🔍 Web Application Architecture

👀 Client-Server Architecture

쇼핑몰 앱을 예를 들면, 상품 정보를 서버로부터 받아와야 하기 때문에 인터넷 연결이 없다면 쇼핑몰 앱이 작동되지 않는다.

단, 상품 정보가 전부 앱 안에 담긴 경우, 앱과 연결된 서버가 존재하지 않는다면, 신상품 정보를 받아오기 위해서 끈임없이 앱을 업데이트 해야한다.
따라서, 실시간으로 고객들에게 상품정보를 전달하기가 매우 어려우며 은행 서버와의 연결이 필요한 '결제'라는 행동을 할 수 없다.

이렇게 리소스(상품정보)가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키덱처, 또는 client-server 아키텍처라고 부른다.

• 리소스를 사용하는 앱: client
• 리소스를 제공(serve)하는 곳: server

client와 server는 요청과 응답을 주고받는 관계이다.(Client 선 요청 -> Server 후 응답)

일반적으로 서버는 리소스를 전달해주는 역할만 담당하며, 리소스는 데이터베이스에 저장되어 있다.

기존 2티어 아키덱처에 데이터베이스가 추가된 형태를 3티어 아키텍처라고 부른다.

Frontend vs Backend

웹 개발자 직군(프론트/백)은 아키텍처에서 어떤 분야를 다루는 지에 따라 구분되며,

프론트엔드 개발자는 client처럼 사용자가 직접 눈으로 볼 수 있고, 상호작용을 할 수 있는 앱을 개발하며, 백엔드 개발자는 눈에 보이지 않는 server를 다루는 개발자로, DB등의 시스템 설계까지 맡는 경우가 많다.

✔ client & server 종류

◾ Client : 웹사이트(웹 앱), 스마트폰.태블릿 용 앱, 데스크탑 앱

◾ Server : 웹 서버, 파일 서버, 메일 서버, 데이터베이스 서버

👀 Client-Server 통신 & API

✔ Client-Server 통신

client와 server 간의 통신은 client의 요청과 server의 응답으로 구성되며, 요청이 있어야만 응답이 온다. 따라서, server 마응대로 client에 리소스를 전달하지 않는다.

Client와 server는 서로 HTTP라는 프로토콜을 이용하여 대화를 나누며, 이때 주고 받는 메시지를 HTTP 메시지라고 부른다.

⭐ 프로토콜?

통신 규약, 즉 약속으로, 실제 사례를 들어보자면 카페에서 커피를 주문할 때 쓰이는 다양한 방법들이 모두 하나하나 프로토콜이다.

• 카운터로 찾아가기
• 앱을 이용한 주문
• 키오스크를 이용한 주문

제대로된 통신을 위해서는 프로토콜(규약)을 지켜야 하는데, 가게에서 외계어로 상품을 주문할 수는 없으며, 우편을 보낼 때에 수신자에 대한 정보 표기가 없거나 우표가 없다면 우편 전송이 불가하다.
즉, 우편 전송을 위해 반드시 지켜야하는 규약이 있으며 각자의 프로토콜마다 지켜야하는 규약이 존재한다.

✔ 주요 프로토콜

✔ API

Client가 server에 요청을 할 때, 정확한 주문 방법을 따라 요청해야 하는데, 이때 서버는 마치 식당에서 메뉴판을 제공하듯, 리소스를 잘 활용할 수 있도록 client에게 API(Application Programming interface)를 제공한다.

일반적으로 인터넷에 있는 데이터를 요청할 때에는 HTTP 프로토콜을 사용하며, 주소를 통해 접근할 수 있다.

HTTP API 디자인에는 Best Practice가 존재하며, 아래는 사용자 관리 API이다.

URL 디자인은 비교적 단순하나 메서드라는 개념이 등장한다. 따라서, HTTP 요청에는 메서드가 존재하며 리소스를 그저 달라고 요청하는 것 뿐만 아니라, 추가나 삭제를 요청할 수 있다.

아래와 같이 CURD 각각의 행동과 일치하는 HTTP 메서드의 종류가 존재한다.

HTTP 메서드는 리소스를 이용해 CRUD 행동에 맞게 적절하게 사용되어야 한다.

Reference: 코드스테이츠