Ray`s Tech Lab

상태 코드

: 클라이언트가 보낸 request의 처리 상태를 response에서 알려주는 것. 100번대 코드부터 500번대 코드까지 종류는 다양하며 각 번호대별로 다음과 같은 의미를 지닌다.

• 1XX (Informational) : 요청이 수신되어 처리중
• 2XX (Successful) : 요청이 정상적으로 처리됨
• 3XX (Redirection) : 요청을 완료하려면 추가적인 행동이 필요함
• 4XX (Client Error) : 클라이언트 측의 문제로 서버가 요청을 수행할 수 없음
• 5XX (Server Error) : 서버 측 문제로 요청을 정상적으로 처리할 수 없음

만약, 클라이언트가 인식할 수 없는 상태 코드 즉 잘 모르는 상태 코드를 서버가 반환한다면, 클라이언트는 그걸 상위 상태코드로 해석해서 처리한다. 예를 들어 299번같은 상태코드는 "아 그냥 2XX : Successful로 뭉퉁쳐서 처리해야지~"하는 거다.

2XX - Successful

: 클라이언트의 request를 성공적으로 처리함을 알리는 상태코드.

• 200 OK : 요청 성공을 의미
• 201 Created : 요청을 성공해서 새로운 리소스가 생성됨을 의미. response message의 Location field에 새로 만들어진 리소스의 경로가 적힘
• 202 Accepted : 요청이 접수됐으나 처리가 완료되지 않음을 의미. 예를 들면 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리하는 경우 등..
• 204 No content : 서버가 request를 성공적으로 처리했으나 response message의 body에 넣어보낼 데이터가 없을 때. 예를 들어 save버튼을 눌러도 그 결과로 아무 내용이 없어도 괜찮을 때 등등..이 땐 결과 내용이 없어도 204 메시지만으로 성공여부를 식별 가능

3XX - Redirection

: 요청을 완료하기 위해 client의 추가적인 조치가 필요할 때

※ Redirection?

웹 브라우저는 3XX 응답의 결과에 Location 헤더가 있으면 그 위치로 자동적으로 이동되는데 이를 Redirect라고 한다. 예를 들어 client가 /event를 요청했지만 서버 입장에선 /event를 더 이상 안 쓰고 /new_event를 쓴다고 할 때, 서버는 3XX 응답과 함께 클라이언트를 /new_event로 redirect시킬 수 있다. 클라이언트 입장에선 브라우저가 지가 알아서 URL을 입력하고 엔터를 누른 느낌과 비슷하다. Redirection의 종류는

1. 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동. 예를 들면 /members가 아니라 /users를 쓰기로 한 경우, /members로 들어오면 /users로 리다이렉트시킨다.

• 301 Moved Permanently : 리다이렉트 시 요청 메소드가 GET으로 변함. 따라서 본문이 제거될 수 있음(앵간하면 제거됨)
• 308 Permanent Redirect : 301과 기능은 같으나 리다이렉트 시 기존의 요청 메소드와 본문을 유지함(처음에 POST로 보냈었으면 리다이렉트도 POST로)

2. 일시 리다이렉션 : 일시적인 변경 즉 잠깐 이동시키는 리다이렉션. 예를 들면 주문 완료 후 주문 내역 화면으로 이동하는 리다이렉션 등이 있다. 

• 302 Fount : 리다이렉트 시 요청 메소드가 GET으로 변하고 본문이 제거될 수 있음
• 307 Temporary Redirect : 302와 기능은 같으나 리다이렉트 시 요청 메소드와 본문 유지
• 303 See Other : 302와 기능은 같으나 리다이렉트 시 요청 메소드가 GET으로 변하는걸 확실하게 보장

3. 특수 리다이렉션

• 304 Not modified : 캐시를 목적으로 사용. 클라이언트가 요청한 리소스가 수정되지 않았음을 알려주는 기능. 따라서 클라이언트는 로컬PC에 저장된 캐시를 재사용할 수 있음.

참고로 영구 리다이렉션과 일시 리다이렉션은 육안으로 보기엔 비슷함. 그러나 브라우저 입장에서는 이 차이가 뚜렷하다. /members리소스가 /users로 영구적으로 바뀌었다고 하면 브라우저는 그 변화를 반영한다. 즉 영구 리다이렉션은 브라우저가 그 변화를 반영함그러나 일시 리다이렉션의 경우는 일시적으로 리소스 위치가 바뀐 거니까 브라우저가 그 변화를 반영하지 않는다. 즉 클라이언트 입장에선 일시 리다이렉션의 경우 향후 보내는 요청도 바뀐 URI가 아니라 기존 URI로 보내야 한다. 영구 리다이렉트를 서버가 하는 리다이렉트, 일시 리다이렉트를 클라이언트가 하는 리다이렉트라고도 부른다.

4XX - Client Error

: 클라이언트 측의 request에 잘못된 문법 등으로 서버가 요청을 수행할 수 없는 것. 오류의 원인이 클라이언트 쪽에 있음을 의미한다. 

• 400 Bad Request : 요청 구문, 메시지 등등 오류. 요청 파라미터가 잘못 되거나 API 스펙이 맞지 않는 상황 등..클라이언트는 요청 내용을 다시 검토하고 보내야 한다.
• 401 Unauthorized : 클라이언트가 해당 리소스에 대한 인증이 필요함을 의미. 인증(Authentication)되지 않음을 의미. 따라서 원래 이름은 Unauthentiaction이 맞는 듯..ㅠ
• 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부. 주로 인증은 됐는데 권한이 없는 상황일 때 이런 응답 코드를 받음
• 404 Not Found : 요청 리소스를 찾을 수 없을 때. 요청 리소스가 서버에 없을 때 등등

5XX - Server Error

: 서버 문제로 오류가 발생한 것

• 500 Internal Server Error : 서버 내부 문제로 오류가 발생함을 의미. 애매하면 걍 다 500 오류임
• 503 Service Unavailable : 서버가 일시적 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없을 때

4XX 에러는 클라이언트 쪽 문제니까 다시 시도해도 똑같이 안 되지만, 5XX에러는 서버 측 문제라 다시 하면 될 수도 있다는 차이점이 있다.

의존성 주입(dependency injection) : 어떤 함수나 클래스가 자신들이 내부적으로 사용할 기능을 자신들 내부에서(즉 스스로가) 만들어내지 않고, 외부에서 이 기능들을 만든 뒤 주입시키는 것.

예를 들어, app.jsx에서 유튜브 api를 호출하는 기능을 쓴다고 할 때 이 기능을 app.jsx 내에서 만들 수도 있겠지만, 외부에서 유튜브 api를 호출하는 기능을 만든 다음 app.jsx에게 주입(by props)하여 이를 쓰게 할 수도 있다. 이를 의존성 주입이라 한다. 찾아보니까 객체 지향 프로그래밍(OOP)에서 코드의 재사용성을 목적으로 잘 사용되는 패턴이라고 한다.  (MVC패턴 등에서 view에 해당하는 애들이 비즈니스 로직도 처리할 수 있고 ~~도 할 수 있고~ 그러면 곤란..) 리액트에서는 컴포넌트들의 테스트를 하는 것에도 DI를 쓰는 게 좋다고 한다. 

리액트에선 index.js에서 사용할 함수 등을 불러와 app.jsx에 집어넣고, 그 다음은 이를 쓰는 컴포넌트로 계속해서 전달전달하는 식으로 활용한다. 예를 들면 다음과 같다.

const authService = new AuthService();

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <App authService={authService}/> 
  </React.StrictMode>
);

// authService객체는 login등의 메소드를 사용가능한 객체이다

그러면, App컴포넌트 안에 B컴포넌트 안에 C컴포넌트 안에 D컴포넌트 안에 E컴포넌트가 있다고 해보자. 또한 E컴포넌트는 login과 logout이라는 기능을 써야 한다. 이 때 방금 한 것처럼 index.js에서 login, logout메소드를 쓸 수 있는 객체(authService라고 가정)를 만들어 app.jsx에 넣어주고, app이 이를 계속 전달전달해주는 방식을 쓸 수 있다. 

// index.js

const authService = new AuthService();

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <App authService={authService}/> 
  </React.StrictMode>
);


// app.jsx

function App({authService}){
	return <B authService={authService} />;
}


// B .jsx

function B({authService}){
	return <C authService={authService} />;
}


// C.jsx

function C({authService}){
	return <D authService={authService} />;
}


// D.jsx

function D({authService}){
	return <E authService={authService} />;
}


// E.jsx

function E({authService}){
	return(
    	<>
           <button onClick={authService.login}>로그인</button>
           <button onClick={authService.logout}>로그아웃</button>
        </>
    );
}

이 때 E에서 다른 기능들도 이용해야 한다면? 그래서 index.js에서 다른 객체를 만들어 E에 전달해야 한다면? app.jsx, B.jsx, C.jsx, D.jsx에 하나하나 직접 코딩을 해줘야 한다. 이 작업? 너무 귀찮다.

그래서 여기서 꼼수(?)가 하나 있다. index.js에서 애시당초에 필요한 의존성들을 집어넣은 E라는 컴포넌트를 만들어 이걸 전달하는 것이다. 다음과 같다.

const authService = new AuthService();
const youtube = new Youtube();

const Jofe = props => {
  return(
    <E {...props} authService={authService} youtube={Youtube}/>
  );
};

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <App Jofe={Jofe}/> 
  </React.StrictMode>
);

return <E authService={authService} youtube={youtube} /> 를 해도 되지만 확장성을 위해 저렇게 한 번 감싼 형태의 컴포넌트로 만들어서 전달할 수도 있다. 이렇게 하면 장점은, E에 새로 전달할 객체가 있어도 index.js에서 한 번만 수정하면 된다. 

1. 클라이언트 - 서버 구조

: HTTP는 클라이언트가 request를 보내면 서버가 response를 보내는 구조이다. 즉 클라이언트와 서버가 개념적으로 분리된 형태이며, 클라이언트로부터 request가 안오면 서버는 자신의 힘으로 클라이언트 측으로 HTTP메시지를 보낼 수 없다는 얘기다.(HTTP는 서버가 클라이언트에게 먼저 메시지를 보낼 수 없고 클라이언트의 요청메시지에 대한 응답만 할 수 있다는 이야기임)

2. 무상태 프로토콜(stateless)이다

: HTTP는 서버가 클라이언트의 상태를 보존하지 않는 stateless한 프로토콜이다.

stateful, 즉 상태를 유지한다고 하면 서버는 클라이언트의 이전 상태를 기억한다. 쉽게 말해 내가 친구랑 맥북에 대해 대화하다가 "그거 살까?"라고 했다면 친구는 '그거'가 맥북을 지칭한다는 것을 알고 있다.stateless, 상태를 유지하지 않는다면 서버는 클라이언트의 이전 상태를 기억 못 한다. 내가 친구랑 맥북에 대해 대화하다가도 "그거 살까?"라고 했을 때 친구는 '그거'가 맥북을 말하는 건지 아이폰을 말하는건지 아이패드를 말하는 건지 모른다는 뜻이다. 따라서 이 상태라면 친구에게 "그거 살까?"가 아니라 "맥북 살까?"라는 식으로 대화해야 한다.

즉, stateless는 서버가 이전 상태를 기억하지 못 하기 때문에 매 요청 시마다 필요한 데이터를 몽땅 다 넘겨야 한다! 때문에 얼핏 보면 stateless방식은 전송하는 데이터 양이 더 많으니까 안 좋은 거 아닌가?할 수 있지만 이 방식은 서버 확장성이 높다는 엄청난 장점을 가진다. 생각해보면, stateful방식은 내가 재준이한테 맥북 얘기하다가 다훈이한테 가서 "그거 살까?"라고 하면 다훈이는 그게 뭔데 임마라고 하겠지만, stateless방식은 재준이한테 맥북 얘기하다가 다훈이한테 가서 "맥북 살까?"라고 얘기해도 괜찮다. 즉 stateless방식은 응답 서버를 쉽게 바꿀 수 있는 것이다. 때문에 클라이언트 요청이 폭증해도 서버를 대거 투입할 수 있으며 이론상 무한한 서버 증설이 가능하다. stateful방식은 클라이언트가 서버 A와 통신하기 시작했다면 계속 그 놈과 통신해야 하지만 stateless방식은 아무 서버나 입맛대로 호출해도 된다는 것.

3. 비연결성

: 연결을 유지한다는 것은 이는 클라이언트-서버 간에 딱히 주고받을 것이 없는 순간에도 계속해서 TCP/IP연결을 맺고 있는 걸 말하고 이는 서버의 자원을 소모하는 것을 의미한다. HTTP는 기본적으로 연결을 유지하지 않는다 즉 볼일이 끝나면 TCP/IP연결을 종료한다. 이로 인해 최소한의 서버 자원을 유지할 수 있음이 보장된다. 같은 시간동안 수천 수만 명이 서비스를 사용하다 특정 시간대에 서버에서 처리되고 있는 요청은 매우 적을 것이다(검색 기능이 있다고 할 때 동시에 검색 기능을 누르는 일은 많지 않은 것처럼). 따라서 이 비연결성 특성을 통해 서버 자원을 매우 효율적으로 이용할 수 있게 된다.

 그러나 이런 비연결성의 단점은 자원 요청 시마다 매번 TCP/IP 연결을 맺어야 하는데 이 작업은 3 way handshake가 수반되므로 overhead가 누적될 수밖에 없다는 것. 이 문제점은 HTTP 지속 연결(Persistent Connections)로 해결됐다.

4. 단순하고, 확장 가능하다

모두들 알다시피 리액트에서 setter함수는 비동기적으로 동작한다.

즉 호출되는 순간 state를 업데이트하고 다음 코드를 실행하는 방식이 아니기 때문에 예기치 못한 오류들에 직면할 수도 있다.

const [count, setCount] = useState(0);

const onAdd = () => {
  setCount(count + 1);
  console.log(count);
}

// 카운트가 0일 때 onAdd가 실행되면 콘솔에 찍히는 카운트값은 1이 아니라 0일수도 있다

위 상황에선 내가 분명 setCount를 통해 count값을 1 늘려줬는데, 콘솔로그에 찍는 코드에서 참조되는 count값은 1 늘어난 값이 아니라 옛날에 쓰던 count값이 되는 문제가 생긴다. 즉 가장 최신의 count값을 참조해야 하지만 못 하게 되는 것이다. setter함수가 비동기적으로 동작하기 때문에..(이 문제는 클래스형 컴포넌트에서는 두 번째 인자로 갱신 이후 실행할 콜백을 넘겨줌으로써 해결할 수 있고 함수형 컴포넌트에선 useEffect를 통해 해결가능했다)

또 문제인 것은 setCount가 여러 번, 예를 들어 100번 호출됐다면 100이 늘어나야 하는데 100보다 덜 늘어나는 상황도 생길 수 있다. 각각의 setCount함수들이 참조하는 count값이 가장 최신의 count값이라는 보장이 없기 때문.

const [count, setCount] = useState(0);

const onAdd = () => {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
}

// 카운트가 5 늘어날 것이라 예측 가능 but 5만큼 안 늘어났을 수도 있다..

이 때 콜백을 써줌으로써 이 문제를 해결 가능하다. 좀 더 풀어서 말하면, 바로 이전의(즉 최신의) state를 사용해 새로운 state를 계산하는 콜백을 setter함수에 전달함으로써 이 문제를 해결할 수 있다. 공식 문서를 참고해보니, 콜백을 사용하는 갱신방법(함수적 갱신)의 경우 바로 이전 state를 사용해서 새로운 state를 계산한다고 한다.

const [count, setCount] = useState(0);

const onAdd = () => {
  setCount(count => count + 1);
  setCount(count => count + 1);
  setCount(count => count + 1);
  setCount(count => count + 1);
  setCount(count => count + 1);
}

setCount(count + 1)는 count값을 인자로 전달하므로, 이 때 전달된 값은 나중에 가면 가장 최신의 값이 아닐 수도 있다. 

반면 setCount(count => count + 1)의 경우는 count값이 아니라 실행할 콜백을 인자로 전달하고, 전달된 콜백이 실행되면 그 때서야 그 때의 count값을 참조하므로 이 경우는 가장 최신의 count값을 참조하는 것이다.

Firebase

: Google이 소유하고 있는 모바일, 웹 애플리케이션 개발 플랫폼. 즉 앱을 개발하고 개선할 수 있는 도구들의 모음이다. 인증, 데이터베이스, 푸시메시지 등등을 지원하는 플랫폼으로 이를 활용하면 좀 더 편한 개발이 가능(그런 것들을 하나하나 만들지 않아도 되니까). 백엔드 기능을 클라우드 서비스 형태로 제공하기 때문에 서버리스 어플리케이션 개발을 가능하게 하는 녀석. 

공식문서를 참조하면 연동하는 법을 알 수 있으나 내 입장에선 쉽지 않았다..그래서 firebase로 구글로그인을 연동하는 법에 대해 정리한다.

https://firebase.google.com/docs/auth/web/google-signin?hl=ko&authuser=0 

1. 리액트 프로젝트에 Firebase 설치

yarn add firebase

2. firebase 콘솔에서 프로젝트를 만들고 SDK를 받는다. 

3. firebase 콘솔에서 인증(authentication) 섹션을 열고 로그인 방법 탭에서 구글 로그인을 사용 설정시킴.

4. 리액트 프로젝트에 firebase.js(이름은 뭐 자유ㅎㅎ)를 만들고 다음과 같이 코드 작성

import { initializeApp } from "firebase/app";

const firebaseConfig = {
  apiKey: process.env.REACT_APP_FIREBASE_API_KEY,
  authDomain: process.env.REACT_APP_AUTH_DOMAIN,
  projectId: process.env.REACT_APP_PROJECT_ID,
  storageBucket: process.env.REACT_APP_STORAGE_BUCKET,
  messagingSenderId: process.env.REACT_APP_MESSAGING_SENDER_ID,
  appId: process.env.REACT_APP_APP_ID,
  measurementId: process.env.REACT_APP_MEASUREMENT_ID,
};

// Initialize Firebase
export const firebaseApp = initializeApp(firebaseConfig);

참고로 리액트에서 API key같은 것들을 작성할 땐 보안문제가 있으니 발급받은 거 그대로 쓰지 않는 게 좋다. 프로젝트 폴더에 .env라는 폴더를 만들고, 거기에 REACT_APP_API_KEY = 블라블라 이런 식으로 쓴 다음, 프로젝트에서 사용할 때는 process.env.REACT_APP_API_KEY이렇게 쓰면 됨. 참고로 저렇게 환경변수 이름을 쓸 땐 REACT_APP이란 걸 붙여야 하고, .gitignore에 .env를 작성하도록 한다.

5. auth_service.js라는 파일만들고(역시나 이름은 뭐 자유) 다음과 같이 만들어준다.

import { 
	getAuth, 
	signInWithPopup, 
	GoogleAuthProvider, 
	signOut } from "firebase/auth";
import { firebaseApp } from './firebase'; // 작성한 firebase.js를 불러오는 용도

class AuthService{
	constructor(){
		this.firebaseAuth = getAuth();
		this.googleProvider = new GoogleAuthProvider();
	}

	login(){
		return signInWithPopup(this.firebaseAuth, this.googleProvider);
	}

	logout(){
		signOut(this.firebaseAuth);
	}
}

export default AuthService;

참고로 클래스 형태가 아니라 함수로 만든 다음 그걸 export하는 형태로 만들어도 상관없다.  또한 아까 작성한 firebase.js의 코드를 실행시켜 firebase app을 초기화해야 하기 때문에 6번 줄에서 import하는 모습.

6. index.js에서 작성했던 auth_service.js를 활용해 dependency injection

import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.module.css';
import App from './app';
import AuthService from './service/auth_service';

const authService = new AuthService();

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <App authService={authService}/>
  </React.StrictMode>
);

이를 통해 app.jsx에서는 authservice.login을 통해 만들어둔 로그인 기능을 활용할 수 있다.