31일차

JiHun·2023년 5월 23일
TIL

부트캠프

목록 보기
28/56

Web Application Architecture

Client-Server Architecture

2 Tier Architecture

상품 정보 같은 리소스가 존재하는 곳과 리소스를 사용하는 앱을 분리시킨 것을 2티어 아키텍처, 또는 클라이언트-서버 아키텍처라고 부른다. 리소스를 사용하는 앱을 "클라이언트", 리소스를 제공하는 곳은 서버라고 부른다.

클라이언트가 서버에 요청을 하면 서버가 응답을 클라이언트에게 리소스를 전달한다.

3 Tier Architecture

서버는 리소스를 전달해 주는 역할만 하고 리소스는 데이터베이스에 따로 저장한다. 창고와 같은 역할을 하는 것이 데이터베이스. 2 티어 아키텍처에서 데이터베이스가 추가된 형태를 3티어 아키텍처라고 한다. 서버가 데이터베이스에 요청을 보내고, 회신 받은 응답을 활용해서 클라이언트에 응답한다.

클라이언트와 서버의 종류

클라이언트는 보통 플랫폼에 따라 구분된다. 브라우저를 통해 주로 이용하는 Web 웹 플랫폼에서의 클라이언트는 웹사이트 또는 웹앱이라구 부른다.

iOS나 안드로이드와 같은 스마트폰/태블릿 플랫폼, 그리도 윈도우와 같은 데스크탑 플랫폼에서 이용하는 앱 역시 클라이언트가 될 수 있다.

서버는 무엇을 하느냐에 따라 종류가 달라진다. 파일 서버는 파일을 제공하는 앱, 웹 서버는 웹사이트에서 필요로 하는 정보들을 제공하는 앱, 메일 서버는 메일을 주고받을 수 있도록 도와주는 앱.
데이터베이스도 데이터 제공자로서 일하므로 일종의 서버라고 볼 수 있다.

클라이언트-서버 통신과 API

일단 통신은 클라이언트의 요청이 있어야 서버가 요청에 대한 응답을 해준다. 요청이 없는데 클라이언트에게 서버 마음대로 리소스를 전달하지 않는다.

프로토콜(Protocol)

프로토콜은 통신 규약이다. 요청을 하기 위해서는 규칙을 지켜서 보내야 한다.
여러가지 프로토콜이 있을 수 있다. 같은 일을 하지만 여러가지 통신 규약을 쓸 수 있다.
각 프로토콜에는 지켜야 하는 규약이 있다.

웹 애플리케이션 프로토콜: HTTP

웹 애플리케이션 아키텍처에서는 클라이언트와 서버가 서로 HTTP라는 프로토콜을 이용해서 서로 통신을 한다.

API(Application Programming Interface)

클라이언트가 원하는 요청을 하기 위해서는 서버가 뭘 제공하는지부터 알아야 한다.
식당에 들어가면 메뉴판을 주듯 서버도 클라이언트에게 메뉴판을 제공해야 한다.
서버는 클라이언트에게 리소스를 잘 활용할 수 있도록 인터페이스(Interface)를 제공해야한다.
이것을 API라고 한다.

보통 인터넷에 있는 데이터를 요청할 때에는 HTTP라는 프로토콜을 사용하며, 주소(URL, URI)를 통해 접근할 수 있게 된다.

HTTP API

HTTP 요청 메서드에는 5가지 정도가 있다.
조회, 추가 갱신, 삭제 이 4가지에 맞는 메서드들이 있다.

  • 조회 -> GET
  • 추가 -> POST
  • 갱신 -> PUT(PATCH)
  • 삭제 -> DELETE

브라우저 작동원리(보이지 않는 곳)

브라우저의 주소창에 입력한 URL은 서버가 제공되는 환경에 존재하는 파일의 위치를 나타낸다.
수많은 폴더 중에 필요한 것만 찾기 위해서는 주소가 필요하다.
예를 들어, 백과사전에서 필요한 정보를 찾기 위해서는 색인(Index)로 찾는 것이 편리할 것이다.
그런 것처럼 주소창에서는 필요한 정보를 찾기위해 서버의 폴더에 진입하여 리소스를 요청할 수 있다.

URL과 URI

URL(Uniform Resource Locator)

네트워크 상에서 웹 페이지, 이미지, 동영상 등의 파일이 위차한 정보를 나타낸다. URL은 scheme, hosts, url-path로 구분된다.

  • scheme은 통신 방식(프로토콜)을 결정한다. 일반적인 웹 브라우저에서는 http(s)를 사용한다.
  • hosts는 웹 서버의 이름이나 도메인, IP를 사용하며 주소를 나타낸다.
  • url-path
file://127.0.0.1/Users/uesrname/Desktop/
https://www.google.co.kr/search?q=http

scheme => file://, https://
hosts => 127.0.0.1
url-path => /Users/username/Desktop/, /search

URI(Uinform Resource Identifier)

일반적인 URL의 기본요소인 scheme, hosts, url-path에 더해 query, fragment를 포함한다. query는 웹 서버에 보내는 추가적인 질문이다.

IP와 PORT

IP

다른 PC에 접속하기 위해서는 PC를 가리키는 주소를 알아야 한다. 네트워크에 연결된 특정 PCdmㅣ 주소를 나타내는 체계를 IP address(Internet Protocol address, IP주소)라고 한다.
127.0.0.1은 자신 컴퓨터를 가리키는 localhost IP 주소다. dot으로 구분된 4 부분은 IP 주소라고 한다. 인터넷에 연결된 모든 PC는 IP 주소체계를 따라 4 부분으로 나눠져 있다. 이것은 IPv4라고한다.

PORT

127.0.0.1:3000에서 :3000 부분이 포트 부분이다. IP주소가 가리키는 PC에 접속할 수 있는 통로(채널)를 의미한다.

도메인과 DNS

도메인

IP 주소를 대신하여 사용하는 주소. 도메인 이름과 IP 주소를 매칭해서 사용한다. 한눈에 파악하기 힘든 IP 주소를 보다 간단하게 나타낼 수 있다.

DNS

네트워크 상에 존재하는 모든 PC는 IP주소가 있다. 모든 IP 주소가 도메인 이 이름을 가지는 것은 아니다. 도메인 이름은 일정 기간 동안 대여하여 사용한다. 대여한 도메인 이름과 IP 주소를 매칭해서 사용한다.

브라우저의 작동원리(보이는 곳)

AJAX

Asynchronous JavaScript And XMLHttpRequest의 약자로 JavaScript, DOM, Fetch, XMLHttpRequest, HTML 등의 다양한 기술을 사용하는 웹 개발 기법.

가장 큰 특징은 웹 페이지에 필요한 부분에 필요한 데이터만 비동기적으로 받아와 화면에 그려낼 수 있다.
검색창에 추천 검색어를 예로 들 수 있다. 한 글자 입력할 때마다 서버랑 통신해서 추천 검색어를 계속 업데이트해준다. 여기에 AJAX가 사용된다.

AJAX의 핵심 기술

AJAX의 핵심 기술은 JavaScript, DOM, Fetch다.

옛날 웹 애플리케이션에서는 <form> 태그를 이용해 서버에 데이터를 전송하면, 서버는 요청에 대한 응답으로 새로운 웹 페이지를 제공해 줘야 했다.
Fetch를 사용하면 페이지를 이동하지 않아도 서버로부터 필요한 데이터를 받아올 수 있다. 브라우저는 Fetch가 서버에 요청을 보내고 응답을 받을 때까지 모든 동작을 멈추는 것이 아니라 계속해서 페이지를 사용할 수 있게 하는 비동기적인 방식을 사용한다.

또한 JavaScript에서 DOM을 사용해 조작할 수 있기 때문에, Fetch를 통해 전체 페이지가 아닌 필요 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동하지 않고 기존 페이지에서 필요한 부분만 변경할 수 있다.

장점

  • 서버에서 HTML을 완성하여 보내주지 않아도 웹 페이지를 만들 수 있다.
    • 이전에는 완성된 HTML을 받아서 렌더링했지만 AJAX를 사용해서 필요한 데이터를 비동기적으로 가져와 브러우저에서 화면의 일부만 렌더링할 수 있다.
  • 표준화된 방법
    • 이전에는 브라우저마다 다른 방식으로 AJAX를 사용했지만, XHR이 표준화되면서 브라우저에 상광없이 AJAX를 사용할 수 있다.
  • 더 작은 대역폭
    • 이전에는 서버로부터 완성된 HTML 파일을 받아와야 했기 때문에 데이터 크기가 컸다. 하지만, AJAX를 쓰면 데이터를 텍스트 형태(JSON, XML 등)로 보내기 때문에 비교적 데이터 크기가 작다.

단점

SSR과 CSR

SSR(Server Side Rendering)

서버에서 렌더링하여 완성된 HTML 파일을 브라우저에 보낸다.
웹 페이지의 내용에 데이터베이스의 데이터가 필요한 경우, 서버는 데이터베이스의 데이터를 불러온 다음, 웹 페이지를 완전히 렌더링 된 페이지로 변환한 후에 브라우저에 응답으로 보낸다.
웹페이지를 살펴보던 사용자가, 브라우저의 다른 경로로 이동하면 브라우저가 다른 경로로 이동할 때마다 서버는 같은 작업을 다시 수행한다.

장점

클라이언트에서 요청한 페이지의 HTML을 다운로드하기 때문에 CSR보다 초기 진입 시 로딩이 빠르다. CSR은 빌드된 static 파일들을 전부 로딩하느라 오래 걸린다.
SSR은 그 화면에 필요한 리소스만 로드해서 CSR보다는 빠르다.

단점

서버에서 렌더링을 하고 중복된 내용도 다시 렌더링한다. 트래픽 걱정을 해야 한다.
트래픽이 높기 때문에 인프라 리소스를 많이 잡아먹는다.(CSR보다 유지비가 비싸다)

CSR(Client Side Rendering)

브라우저의 요청을 서버로 보내면 서버는 웹 페이지를 렌더링하는 대신, 웹 페이지의 골격이 될 단일 페이지를 클라이언트에게 보낸다.

초기에 빈 HTML과 모든 로직이 담겨있는 JavaScript를 다운로드 한다. 그 후 빈 HTML에 JavaScript 다운로드를 한다.

장점

원하는 내용만 업데이트를 할 수 있기 때문에 중복되는 부분은 다시 불러서 만든 필요가 없다.
서버에 올릴 필요가 없어서 저비용으로 인프라를 구축할 수 있다.

단점

골격 HTML 파일하나에 추가하는 방식이다보니 검색엔진에 노출 작업이 까다롭다.
첫 로드 시 모든 로직이 담겨있는 JavaScript들을 다운로드하다보니 첫 진입시 로딩 속도가 길다는 단점이 있다. 그래서 빌드 최적화를 하는 데 시간을 많이 투자해야 한다. 빌드한 파일들의 용량을 어떻게든 최소화를 해야하고, 항상 다 불러오는 것은 비효율적이라서 다이나믹 import라는 것을 사용하여 SSR과 유사하게 필요한 리소스만 로드할 수 있도록 작업을 미리 해두어야 한다.

profile
JiHun
안녕하세요. 프론트엔드 개발자 송지훈입니다.
이전 포스트

30일차

다음 포스트

32일차

0개의 댓글