10일차 웹 서비스 개발 기초

AJAX

자바스크립트를 이용해 서버와 브라우저가 비동기 방식으로 데이터를 교환할 수 있는 통신 기능. 본래 비동기 요청을 보내는 데 필요한 기술만 AJAX라 불렀으나 브라우저 내에서 비동기 기능을 제공하는 모든 기법을 통칭하게 되었다.

 

 

 

Ajax의 활용 예시

 

• 자동완성

라이브 검색(혹은 자동완성)이라고 불리는 기능은 주로 Ajax를 이용한다. 오늘날 검색사이트와 웹이메일 대부분이 사용하는 기술이다. 이 방법은 검색막대나 홈페이지에서 검색어를 입력하는 동시에 검색 결과가 나타나고 앞의 몇글자만 쳐도 그 해당하는 이메일 주소가 나온다.

 

• 사용자 정보 표시

사용자가 생성한 컨텐츠를 사용하는 웹사이트(트위터나 인스타 등)는 독자들의 웹사이트에 본인의 정보(최근 트윗이나 사진 등)를 노출하는 기능을 제공한다. 이를 위해 자신들의서버에 데이터를 수집한다.

 

instagram

 

회원가입시 중복아이디일 경우, "이미 사용중인 아이디입니다."를 표시하게하는 기능에서도 활용되고있으며,  온라인쇼핑몰에서 장바구니에 원하는 물품을 추가했을 때 페이지 이동이나 전체 페이지에 대한 새로고침 없이도 물품정보만 추가되는 기능을 구현하고자 할 때, 페이스북 메시지, 포털사이트 뉴스탭, 무한 스크롤 또한 이 Ajax를 활용한다.

AJAX의 핵심 기술

AJAX를 구성하는 핵심 기술은 JavaScript와 DOM, 그리고 Fetch입니다.

 

• 전통적인 웹 애플리케이션(커피자판기)

<form>이라는 태그를 이용해 서버에 데이터를 전송하면 서버는 요청에 대한 응답으로 새로운 웹페이지를 제공

    > 즉, 요청이 오면 매번 새로운 웹페이지로 이동

 

커피자판기는 사전에 정해진 순서에 맞게 커피가 나와야한다. 커피가 다 되기 전 다음 주문을 다 받거나 그런게 없다. 커피가 완성 될 때까지 다음 주문자는 기다려야한다.

 

• AJAX(바리스타)

Fatch를 사용하면 현재 페이지에서 작업을 하는 동안 서버와 통신 가능

> 즉, 브라우저는 Fetch가 서버에 요청을 보내고 응답을 받을때까지 모든 동작을 멈추는 것이 아니라, 계속해서 페이지를 사용할 수 있게 하는 비동기적인 방식을 사용

 

자바스크립트에서 DOM을 사용해 조작 가능

>Fatch를 통해 전체가 아닌 필요한 데이터만 가져와 DOM에 적용시켜 새로운 페이지로 이동치않고 기존 페이지에서 필요한 부분만 변경.

 

커피전문점 바리스타들은 주문도받고, 직접음료도제조하는데 손님이 여러명일경우, 주문을 받고 커피를 내려놓은뒤 다시 다음 손님의 주문을 받는다.

 

출저)https://visualize.tistory.com/402

Fetch API

 

Fetch는 자바스크립트를 이용해 HTTP 요청을 보낼 수 있는 Web API입니다. 간단한 Fetch 사용법은 다음과 같습니다.

// Fetch를 사용
fetch('http://52.78.213.9:3000/messages')
	.then (function(response) {
		return response.json();
	})
	.then(function (json) {
		...
});

 

 

 AJAX의 장점

 

• 서버에서 HTML을 완성하여 보내주지 않아도 웹페이지를 만들 수 있습니다. 이전에는 서버에서 HTML을 완성하여 보내주어야 화면에 렌더링을 할 수 있었습니다. 그러나 AJAX를 사용하면 서버에서 완성된 HTML을 보내주지 않아도 필요한 데이터를 비동기적으로 가져와 브라우저에서 화면의 일부만 업데이트 하여 렌더링 할 수 있습니다.
• 유저 중심 어플리케이션 개발
  • AJAX를 사용하면 필요한 일부분만 렌더링하기 때문에 빠르고 더 많은 상호작용이 가능한 어플리케이션을 만들 수 있습니다.
• 더 작은 대역폭
  • 대역폭: 네트워크 통신 한 번에 보낼 수 있는 데이터의 크기.
  • 이전에는 서버로부터 완성된 HTML 파일을 받아와야했기 때문에 한번에 보내야 하는 데이터의 크기가 컸습니다. 그러나 AJAX에서는 필요한 데이터를 텍스트 형태(JSON, XML 등) 보내면 되기 때문에 비교적 데이터의 크기가 작습니다.

 

 AJAX의 단점

• Search Engine Optimization(SEO)에 불리

AJAX 방식의 웹 어플리케이션은 한 번 받은 HTML을 렌더링 한 후, 서버에서 비동기적으로 필요한 데이터를 가져와 그려냅니다. 따라서, 처음 받는 HTML 파일에는 데이터를 채우기 위한 틀만 작성되어 있는 경우가 많습니다.

검색 사이트에서는 전세계 사이트를 돌아다니며 각 사이트의 모든 정보를 긁어와, 사용자에게 검색 결과로 보여줍니다. 그런데 AJAX 방식의 웹 어플리케이션의 HTML 파일은 뼈대만 있고 데이터는 없기 때문에 사이트의 정보를 긁어가기 어렵습니다.

• 뒤로가기 버튼 문제

일반적으로 사용자는 뒤로가기 버튼을 누르면 이전 상태로 돌아갈 거라고 생각하지만, AJAX에서는 이전 상태를 기억하지 않기 때문에 사용자가 의도한 대로 동작하지 않습니다. 따라서 뒤로가기 등의 기능을 구현하기 위해서는 별도로 History API를 사용해야 합니다.

 

 

SSR(Server Side Rendering)

 

서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식이다.

 

 

1. User가 Website 요청을 보냄.
2. Server는 'Ready to Render'. 즉, 즉시 렌더링 가능한 html파일을 만든다.
   (리소스 체크, 컴파일 후 완성된 HTML 컨텐츠로 만든다.)
3. 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링 된다. 그러나 사이트 자체는 조작 불가능하다. (Javascript가 읽히기 전이다.)
4. 클라이언트가 자바스크립트를 다운받는다.
5. 다운 받아지고 있는 사이에 유저는 컨텐츠는 볼 수 있지만 사이트를 조작 할 수는 없다. 이때의 사용자 조작을 기억하고 있는다.
6. 브라우저가 Javascript 프레임워크를 실행한다.
7. JS까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용 가능해진다.

즉. 서버에서 이미 '렌더 가능한' 상태로 클라이언트에 전달되기 때문에, JS가 다운로드 되는 동안 사용자는 무언가를 보고 있을 수 있다.

 

SSR을 사용하자

• 네트워크가 느릴 때 
  (CSR은 한번에 모든 것을 불러오지만 SSR은 각 페이지마다 나눠불러오기 때문)
• SEO(serach engine optimization : 검색 엔진 최적화)가 필요할 때.
• 최초 로딩이 빨라야하는 사이트를 개발 할 때
• 메인 스크립트가 크고 로딩이 매우 느릴 때
• 웹 사이트가 상호작용이 별로 없을 때.

 

 CSR(Client Side Rendering)

 

서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다.

 

1. User가 Website 요청을 보냄.
2. CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트로 보낸다.
3. 클라이언트는 HTML과 JS를 다운로드 받는다.
   (이때 SSR과 달리 유저는 아무것도 볼 수 없다.😡)
4. 생략
5. 다운이 완료된 JS가 실행된다. 데이터를 위한 API가 호출된다.
   (이때 유저들은 placeholder를 보게된다. )
6. 서버가 API로부터의 요청에 응답한다.
7. API로부터 받아온 data를 placeholder 자리에 넣어준다. 이제 페이지는 상호작용이 가능해진다.

CDN : aws의 cloudflare를 생각하면 됨. 엔드 유저의 요청에 '물리적'으로 가까운 서버에서 요청에 응답하는 방식

 

즉, 서버에서 처리 없이 클라이언트로 보내주기 때문에 자바스립트가 모두 다운로드 되고 실행이 끝나기 전까지 사용자는 볼
수 있는게 없다.

 

CSR을 사용하자

• 네트워크가 빠를 때
• 서버의 성능이 좋지 않을 때
• 사용자에게 보여줘야 하는 데이터의 양이 많을 때.
  (로딩창을 띄울 수 있는 장점이 있다.)
• 메인 스크립트가 가벼울 때
• SEO 따윈 관심 없을 때
• 웹 어플리케이션에 사용자와 상호작용할 것들이 많을 때.
• (아예 렌더링 되지 않아서 사용자의 행동을 막는 것이 경험에 오히려 유리함.)

 

 

SSR과 CSR의 차이점

 

1) 웹페이지를 로딩하는 시간

웹 페이지 로딩의 종류는 두 가지로 나눌 수 있다.
하나는 웹 사이트의 가장 첫 페이지를 로딩하는 것.
다른 하나는 나머지를 로딩하는 것

• 첫 페이지 로딩시간.

CSR의 경우 HTML, CSS와 모든 스크립트들을 한 번에 불러온다. 반면 SSR은 필요한 부분의 HTML과 스크립트만 불러오게 된다. 따라서 평균적으로 SSR이 더 빠르다.

• 나머지 로딩 시간

첫 페이지를 로딩한 후, 사이트의 다른 곳으로 이동하는 식의 동작을 가정하자. CSR은 이미 첫 페이지 로딩할 때 나머지 부분을 구성하는 코드를 받아왔기 때문에 빠르다.
반면, SSR은 첫 페이지를 로딩한 과정을 정확하게 다시 실행한다. 그래서 더 느리다.

2) SEO 대응

검색 엔진은 자동화된 로봇인 '크롤러'로 웹 사이트들을 읽는다. CSR은 자바스크립트를 실행시켜 동적으로 컨텐츠가 생성되기 때문에 자바스크립트가 실행 되어야 meatadata가 바뀌었다.
(이전 크롤러들은 자바스크립트를 실행시키지 않았었기에 SEO 최적화가 필수적이었다. 구글이 그 트렌드를 바꾸고 있다고 한다.)

SSR은 애초에 서버 사이드에서 컴파일되어 클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이하다.

3) 서버 자원 사용

SSR이 서버 자원을 더 많이 사용한다. 매번 서버에 요청을 하기 때문이다. 반면 CSR은 클라이언트에 일감(?)을 몰아주기 때문에 서버에 부하가 적다.(당연)

 

출저)https://velog.io/@vagabondms/%EA%B8%B0%EC%88%A0-%EC%8A%A4%ED%84%B0%EB%94%94-SSR%EA%B3%BC-CSR%EC%9D%98-%EC%B0%A8%EC%9D%B4