새로운 프로젝트 시작~!
240610 ~ 240614

이번에는 강의 좀 듣다가 과제 들어가고, 강의 좀 듣다가 과제 들어가고 하면서 템포를 조절할 예정이다... 순서대로 안 들을 예정!!

React

비동기

동기 vs 비동기

동기 ? 요청과 응답이 순차적으로 일어난다. 이후 다음 작업을 진행
비동기 ? 요청과 응답이 비순차적으로 일어난다.

Promise

? 비동기 작업의 완료 또는 실패를 처리하기 위해 사용되는 개념

상태

대기-pending => 이행-fulfilled
대기-pending => 거부-rejected

순차 처리 vs 병렬 처리

순차 처리? 1 -> 2 -> 3 이후 UI 보내기
병렬 처리? 1,2,3 동시에 처리 이후 UI 보내기
=> 순서가 중요한 경우엔 순차, 그렇지 않은 경우에는 병렬 처리

Promise.all

useEffect에 의존성 배열 없이 마운트 하는 게 리액트의 일반적인 방식인 듯 하다.

Promise.all([
	fetch("url").then((response) =>
    response.json()
    ),
    fetch("url").then((response) =>
    response.json()
    ),
]).then(function ([response1, response2]) {
	//로직
});

async, await 연습

역시 useEffect에 의존성 배열 없이 마운트 하는 게 리액트의 일반적인 방식인 듯 하다.

const fetchPost = async () => {
	const response = await fetch("url");
    const date = await response.json();
    // 로직
}

HTTP

? 클라이언트-서버 모델을 기반으로 동작

Client, Server

클라이언트Client : 요청 하는 곳
서버 Server : 응답 하는 곳

HTTP의 특징

무상태성 : 모든 요청은 독립적이며, 이전 요청의 정보를 기억하지 않는다. (상태 유지 x)
확장성 : 다양한 확장 헤더를 추가하여 기능을 확장할 수 있다.
유연성 : 다양한 데이터 형식 전송 가능 e.g. 텍스트, 이미지, 비디오

비연결성 : 각 HTTP 요청-응답 주기가 완료되면 클라이언트와 서버 간의 연결이 종료한다.

HTTP의 특징 중 무상태와 비연결성에도 불구하고, 클라이언트와 서버가 지속해서 요청할 수 있는 이유?

쿠키

? 브라우저에 저장되는 작은 데이터 조각
? key-value 형태로 저장
? 서버가 특정 api 요청, 서버 응답시 Set-cookie 속성으로 쿠키 정보를 담아줌 (* 쿠키를 브라우저에 자동으로 저장)
? 클라이언트에서 직접 추가/수정/삭제할 수 있다. (= 외부 공격에 취약)

HTTP 메시지 구조

요청 메시지

: 클라이언트가 서버에게 요청할 떄
요청 라인 : 메서드(post, get), url, http 버전
헤더 : 요청의 추가 정보(메타데이터) e.g. 브라우저 정보, 인증 정보(무상태성과 연관)
본문 : 선택적 (post 매서드에서 사용)

응답 메시지

: 서버가 클라이언트에게 응답을 줄 때
상태 라인 : http 버전, 상태 코드(200, 404 등)
헤더 : 응답의 추가 정보(메타데이터) -> 콘텐츠 타입, 데이터 길이 등
본문 : 선택적, 주로 응답 데이터

HTTP 상태 코드

? 서버가 클라이언트의 요청을 처리한 결과
? 세 자리 숫자로 구성되어있으며, 첫 번째 자리에 따라 의미가 다름

4xx : 클라이언트 오류 : "프론트엔드" 잘못 = 내 잘못
5xx : 서버 오류

HTTP 매서드

? 클라이언트가 서버에게 요청의 성격을 알리는데 사용
REST API는 이런 HTTP 매서드(get, post, delete, put)를 사용하여 CRUD 작업 수행

get

? 서버에 데이터를 요청할 때
body 없음
REST API? 데이터를 조회할 때

post

? 서버에 데이터를 제출할 때
body 포함
REST API? 새로운 리소스를 생성할 때

put, patch

? 서버의 데이터를 업데이트할 때
body 포함
REST API? 기존 리소스를 수정할 때

delete

? 서버의 데이터를 삭제할 때
body 없음
REST API? 특정 리소스를 삭제할 때

RESTful

그냥 시맨틱 코드처럼 쓰는 것들. 뭐만 보고도 아 이거겠네~ 싶게 쓰는 것을 말한다. 안타깝게도 중요하다.

API 명세서

? API Specification
애플리케이션 프로그래밍 인터페이스(API)의 구조, 동작 및 상호 작용 방식을 정의한 문서

엔드 포인트

? Endpoints
API가 제공하는 URL 경로

JWT

? 인코딩된 인증 정보

인증, 인가

인증? 로그인 / 등록된 회원인지 확인하는 절차
인가? 인증을 받은 유저(=로그인한 회원)가 권한이 있는지 확인하는 절차

세션

세션을 통한 인증 방식

? 사용자와 서버 간의 연결이 활성화된 상태 (=인증이 유지된 상태)

쿠키-세션을 통한 인증 방식
SID = 세션 아이디

세션을 통한 인가 방식

쿠키-세션을 통한 인가 방식
: 쿠키는 자동으로 서버에...
인가가 되지 않았다면 (2)가 불가...

세션 인증 방식의 한계

확장성 문제
메모리 사용량 증가
상태 유지의 복잡성
보안 문제

=> 이러한 문제를 극복하기 위해서 등장한 것이 바로 JWT (JSON web Token)

JWT의 개념

1. 헤더(Header): 어떤 종류의 토큰인지와 어떤 알고리즘으로 서명되었는지에 대한 정보가 들어있어요.
2. 본문(Payload): 실제로 중요한 데이터가 들어있는 부분입니다. 예를 들어, 사용자 ID, 토큰의 만료 시간 등이 여기에 포함됩니다.
3. 서명(Signature): (백엔드 부분) 이 부분은 토큰이 위조되지 않았는지 확인하는 역할을 합니다. 서버만이 알 수 있는 비밀 키로 서명되어 있습니다. 이 서명 때문에 토큰의 무결성이 보장됩니다.

JWT 토큰 인증 방식

JWT 토큰 인가 방식

스탠다드 강의

[타임어택 회고록]

오늘 타임 어택에서 거하게 말아먹고 쓰는 회고록...
RTK 어렵다고 못 본 척 하다가 타임 어택 말아먹었다... 😇🙃 (안웃김)

RTK 문제점이자 개선점

1. export default / export => import 할 때 {} 실수
2. configStore, reducer에 기재하는 리듀서 이름 실수 => Reducer과 Slice 혼용 (통일할 것)
3. action.payload 값은 함수 내부에서 쓰고, 매개변수로 받아오지 않아도 됨
4. 인풋값은 문자열 => Number, parseInt
5. 맵으로 아이템 뿌려줄 때 버벅거리지 말기

{todolist.map((todo) => (
	<TodoItem key= {todo.id} todo = {todo} />
))}

7. 맵으로 뿌려준 컴포넌트(TodoItem)는 프롭스로 받았으니, 프롭스로 수령하고 return에는 바로바로 {todo.@@} 이렇게 쓰기 가능