[TIL-017] JSON-Server / fetch와 axios 차이 / 면접 스터디 3회차

Today목표 : 4/28일 면접 스터디 3회차

---

JSON - Server ✅

아주 간단한 DB와 API 서버를 생성해주는 패키지다. 

사용 목적

: 백엔드와 협업 시에 백엔드의 DB구축과 API Server가 완성될 때 까지 프론트에서 개발에 임시적으로 사용할 mock data를 생성하기 위함 => json-server를 통해서 임시 API를 구축하고, 서버의 data를 mocking(흉내,모의) 할 수 있으며 이것을 통해 선제적으로 FE 개발을 진행할 수 있다.

사용 방법 

1. json-server 설치 => json-server는 보통 4000번 port를 이용한다.

yarn add json-server

yarn json-server --watch db.json --port 4000

2. db.json 파일에서 데이터 수정

{
  "todos": [
    {
      "id": 1,
      "title": "json-server",
      "content": "json-server를 배워봅시다."
    }
  ]
}

3. 브라우저 URI로 접근 

http://localhost:4000/todos/3 => id가 3인 데이터만 나옴

 

 

axios ✅

axios : node.js와 브라우저를 위한 Promise기반 HTTP 클라이언트

사용방법

1. 설치

$ yarn add axios

 

 

옵션 체이닝(?)✅

=> todos의 데이터를 받아오기도 전에 jsx return문이 렌더링될 경우 => 값이 undefined이 된다.  

{/* ? 옵션 체이닝 */}
      {todos?.map((todo) => {
        return (
          <div key={todo.id}>
            {todo.title} : {todo.body}
          </div>
        );
      })}

 

❗이 때, 옵션 체이닝(?)을 사용하는 이유 : ?연산자는 객체 내부의 속성에 접근할 때 해당 속성이 존재하지 않는 경우에도 에러를 발생시키지 않고, null 또는 undefined를 반환하는 방식이다.

 todos?.map()에서 사용된 옵션 체이닝(?.) 연산자는, todos 배열이 null 또는 undefined일 경우, 뒤의 .map() 함수를 실행하지 않고 바로 null을 반환하는 역할을 한다.

=> ?연산자를 사용함으로써 null인데도 데이터값이 나오는 이유는, 초기 렌더링 시점에서는 todos 상태값이 null이기 때문에, Axios 컴포넌트가 처음 렌더링될 때는 JSX가 렌더링되지 않지만 fetchTodos() 함수가 비동기적으로 요청을 보낸 결과값을 todos 상태값으로 전달하면서 state가 변경되어 JSX가 렌더링되어 페이지가 리렌더링되기 때문이다.

 

 

fetch와 axios의 차이 ✅

fetch는 es6부터 도입된 js 내장 라이브러리다. Promise기반 비동기 통신 라이브러리로 별도의 설치나 import가 필요하지않다. 하지만 다음과 같은 이유로 실제 개발에서 잘 사용하지는 않는다.

fetch의 단점

- 미지원 브라우저 존재

- 개발자에게 불친절한 response

- axios에 비해 부족한 기능

- 데이터 통신 시 fetch.then()한 상태에서도 JSON 포맷이 아니기 때문에 response를 한번 더 해주는 과정이 필요해 두번의 .then()이 필요하다. 

- fetch의 경우, catch()가 발생하는 경우는 오직 네트워크 장애 케이스다. 따라서 개발자가 일일히 then() 안에 모든 케이스에 대한 HTTP 에러 처리를 해야한다.

const url = "https://jsonplaceholder.typicode.com/todos";

fetch(url)
  .then((response) => {
    if (!response.ok) {
      throw new Error(
        `This is an HTTP error: The status is ${response.status}`
      );
    }
    return response.json();
  })
  .then(console.log)
  .catch((err) => {
    console.log(err.message);
  });

 

axios를 사용할 경우

- 친절하게 응답 response를 기본적으로 JSON 포맷으로 제공하여 바로 response.data로 접근 가능하다.

const url = "https://jsonplaceholder.typicode.com/todos";

axios.get(url).then((response) => console.log(response.data));

 

- 에러 처리 : axios.get()요청이 반환하는 Promise 객체가 갖고있는 상태코드가 2xx의 번위를 넘어가면 거부(reject)한다.

axios는 에러 객체안에 status와 config 등이 있어 아주 상세하게, 곧바로 catch()를 통해 에러 핸들링이 가능하다.

// 1. axios
    
    const url = "https://jsonplaceholder.typicode.com/todos";
    
    axios
      .get(url)
      .then((response) => console.log(response.data))
      .catch((err) => {
        console.log(err.message);
      });
    
 //   - axios.get()요청이 반환하는 Promise 객체가 갖고있는 상태코드가 2xx의 범위를 넘어가면 거부(reject)를 합니다.
 //   - 따라서, 곧바로 catch() 부분을 통해 **`error handling`**이 가능합니다. 예를들면 이렇게요!
        
        const url = "https://jsonplaceholder.typicode.com/todos";
        
        // axios 요청 로직
        axios
          .get(url)
          .then((response) => console.log(response.data))
        	.catch((err) => {
        
        		// 오류 객체 내의 response가 존재한다 = 서버가 오류 응답을 주었다	
        		if (err.response) {
        			
        	    const { status, config } = err.response;
        	
        			// 없는 페이지
        	    if (status === 404) {
        	      console.log(`${config.url} not found`);
        	    }
        
        			// 서버 오류
        	    if (status === 500) {
        	      console.log("Server error");
        	    }
        	
        		// 요청이 이루어졌으나 서버에서 응답이 없었을 경우
        	  } else if (err.request) {
        	    console.log("Error", err.message);
        		// 그 외 다른 에러
        	  } else {
        	    console.log("Error", err.message);
        	  }
        	});

 

 

 

면접 스터디 3회차 - REST, RESTful의 개념 ✅

오늘은 면접 스터디 3회차 발표 날이었다. 주제는 다음과 같다.

다음은 면접 스터디를 준비하면서 REST와 RESTful의 개념에 대해 정리한 포스팅이다.

REST API란 무엇인가?

 

 

REST, RESTful의 개념 ✅

REST, RESTful을 공부하면서 가장 헷갈렸던 부분은 다음과 같다.

그래서 REST API의 URI는 주소창의 URI와 다른건가? 똑같이 생겼는데..?

그에 대해 얻은 답들을 정리해 보았다.

 

1. 리액트 서버와 URI 관계

리액트 애플리케이션은 주소 표시줄의 URI(Uniform Resource Identifier)를 기반으로 다양한 페이지를 렌더링한다. 일반적으로, 리액트 애플리케이션에서는 URI와 컴포넌트가 일대일 대응되도록 구성된다.

URI는 일반적으로 브라우저에서 입력하는 주소 표시줄의 값을 의미한다. 예를 들어, "http://www.example.com/about"과 같은 URI는 "about" 페이지를 의미한다. 리액트에서는 이러한 URI에 따라 적절한 컴포넌트를 렌더링하여 해당 페이지를 표시한다. 이를 구현하기 위해, 리액트 라우터(React Router) 라이브러리를 사용하는 것이 일반적이다. 리액트 라우터는 URI와 컴포넌트 간의 매핑을 관리하고, URI가 변경될 때마다 적절한 컴포넌트를 렌더링하여 페이지를 업데이트 한다.

 

2. 리액트 서버 URI랑, 백엔드 서버의 REST API URI랑 달라?

리액트 서버의 URI와 REST API의 URI는 서로 다르다.
리액트 애플리케이션은 브라우저에서 실행되는 클라이언트 측 애플리케이션이다. 따라서, 리액트 애플리케이션의 URI는 일반적으로 브라우저의 주소 표시줄에서 확인할 수 있으며, 브라우저에서 클라이언트 측 라우팅을 수행하는 데 사용된다. 반면에, REST API의 URI는 서버 측의 엔드포인트를 식별하는 데 사용된다. REST API는 일반적으로 서버에서 데이터를 읽고 쓰는 데 사용되며, 클라이언트 측 애플리케이션이 서버와 상호 작용하는 데 사용된다.

따라서, 리액트 애플리케이션의 URI와 REST API의 URI는 다른 용도로 사용된다. 리액트 애플리케이션의 URI는 클라이언트 측 라우팅에 사용되고, REST API의 URI는 서버 측 엔드포인트를 식별하는 데 사용된다.

 

3. 그럼 우리 눈에 보이는 브라우저 주창의 URI는 어디에 속하는데?

브라우저의 주소 표시줄에 보이는 URI는 클라이언트 측 URI다. 이 URI는 보통 클라이언트 측 라우팅에 사용된다.
브라우저는 URI를 통해 서버에 요청을 보내고, 서버는 요청을 처리하고 해당하는 데이터를 클라이언트에게 응답한다. 이렇게 응답된 데이터는 브라우저에서 클라이언트 측 JavaScript를 사용하여 렌더링된다. 그리고 이러한 렌더링된 데이터가 브라우저 창에 표시된다.
클라이언트 측 URI는 보통 리액트 애플리케이션에서 라우팅을 수행하는 데 사용된다. 리액트 라우터와 같은 라이브러리를 사용하여, 클라이언트 측 URI가 변경될 때마다 적절한 컴포넌트를 렌더링하여 새로운 뷰를 표시한다. 이렇게 클라이언트 측 URI를 사용하면, 리액트 애플리케이션에서 다양한 페이지를 렌더링할 수 있다.

 

다음 Lv4 과제에서는 API 명세에 대해 구체적으로 작성해야 한다. 이전 협업 프로젝트에서 Swagger로 API 명세를 받아본 기억이 있었는데 이것을 참고하여 REST API를 생성하는 방법에 대해 공부해 봐야 할 것 같다.