프로젝트를 진행하면서 한 기록 - mi-hye/fe-newsstand-react GitHub Wiki

메모

  • 리액트 훅은 비동기 적으로 실행된다.

  • state 값은 불변성을 유지하기 위해 직접 참조해서 값을 변경 할 수 없다.

  • tailwind에서 사용자가 정의한 커스텀 색상이 기본 색상보다 우선시 된다

  • 커스텀 색상에서는 아래에 선언한게 먼저 적용 된다(캐스캐이딩 됨)

  • 리액트는 이벤트 위임을 그냥 해줌 그래서 버튼 24개가 map으로 반복돼서 구독하는 이벤트를 등록한다? 그냥 버튼에 등록 시키면 됨!!

git flow

개발 시 미메, 디벨롭 2개 브랜치 만들고 그 이하에 피쳐단위로 개발 fe-무슨기능 이런식으로 많이 함 피쳐 단위 개발이 끝나면 매일 디벨롭 브랜치에 병합(오류가 있으면 통합 안시킴) 미드포인트가 되면 디벨롭 브랜치 메인(mime) 브랜치에 병합

CORS 에러

양쪽 다 배포해야한다

네, 클라이언트를 Vercel에 배포하면 CORS 문제가 해결될 가능성이 큽니다. 클라이언트를 Vercel에 배포하면 서버와 클라이언트가 동일한 도메인(혹은 서브도메인)에서 실행되기 때문에 CORS 문제가 발생하지 않습니다.

왜 클라이언트를 함께 배포하면 CORS 문제가 해결될까요?
같은 출처(Same-Origin) 정책

CORS 문제는 서로 다른 출처(Origin) 간의 요청을 허용하지 않는 브라우저 보안 정책으로 인해 발생합니다.
출처는 도메인, 프로토콜, 포트를 포함한 URL을 의미합니다. 예를 들어:
서버: https://newsstand-react-server.vercel.app
클라이언트(로컬): http://localhost:3000
서로 다른 출처에서 요청을 보내기 때문에 브라우저는 이를 차단하게 됩니다.

Vercel에 클라이언트 배포 시 같은 출처로 간주

클라이언트를 Vercel에 배포하면 클라이언트와 서버가 같은 도메인 또는 서브도메인 하에 존재하게 됩니다. 예를 들어:
서버: https://newsstand-react-server.vercel.app
클라이언트: https://newsstand-react-client.vercel.app
같은 도메인 또는 서브도메인에서 요청을 보내기 때문에 브라우저는 이를 같은 출처로 간주하고 요청을 허용합니다.

PUT, POST 차이

  • POST를 사용할 때: 리소스를 새로 생성하고, 서버가 리소스의 위치를 결정하도록 하거나, 서버에서 어떤 작업(예: 데이터 처리, 전송 등)을 수행하도록 트리거하고 싶을 때.
  • PUT을 사용할 때: 리소스를 업데이트하거나, 리소스의 특정 위치를 지정해서 생성하고 싶을 때.
  • 즉, 새로 추가하는건 post / 수정하는건 put

RestFul api 사용 시 주의점!!

  • 클라이언트에선 body에 값이 있을 경우, 헤더에 데이터 타입을 명시해줘야함
  • 서버에서는 리퀘스트의 바디를 읽을 수 있도록 미들웨어를 설정해줘야 함
클라
fetch(`${SERVER}/subscribe`, {
		method: "POST",
		headers: {
			"Content-Type": "application/json",
		},
		body: JSON.stringify(targetNews),
	});

서버
app.use(express.json()); //요청 본문 파싱을 위한 미들웨어 설정

몽고DB

  • MongoDB는 스키마리스(Schema-less) 데이터베이스
  • 컬렉션(Collection)은 MongoDB에서 데이터를 저장하는 컨테이너 역할. 일반적으로 컬렉션은 SQL 데이터베이스의 테이블(Table)에 해당.
  • DB를 추가한 뒤, 배포 후 CORS 문제가 다시 발생 -> 서버에서 확인해보니 DB문제로 추정 -> Vercel과 MongoDB Atlas의 네트워크 설정 문제
Vercel은 서버리스 환경을 사용하여 요청이 발생할 때마다 서버 인스턴스를 생성합니다. 이때 인스턴스에 할당되는 IP 주소는 동적이기 때문에, 특정 IP 주소를 지정하여 MongoDB Atlas에 허용할 수 없습니다. IP 주소가 매 요청마다 변경될 수 있기 때문에, 특정 IP 주소를 설정하는 것이 어렵습니다.

어쩔 수 없이 MongoDB Atlas에서 모든 IP 주소의 접근을 허용

서버리스

  • 서버리스에서 리소스 관리는 연결풀링
연결 풀링의 개념
연결 풀링(Connection Pooling)은 데이터베이스와 같은 리소스에 대한 연결을 재사용하여 성능을 최적화하는 기술입니다. 
연결 풀링은 미리 정의된 수의 연결을 **"풀(pool)"**이라는 공간에 유지해 두고, 필요할 때마다 이 풀에서 연결을 가져다 쓰고, 작업이 끝나면 다시 풀에 반환하는 방식입니다. 풀에 저장된 연결이 부족할 경우, 새로운 연결을 생성하여 풀에 추가하거나, 기존 연결이 반환되기를 기다릴 수 있습니다.

연결 풀링의 작동 방식
연결 풀 생성: 애플리케이션이 시작될 때, 데이터베이스나 리소스에 대한 연결이 미리 설정되어 "풀"에 저장됩니다. 이 풀은 일정한 수의 연결을 유지하며, 필요에 따라 동적으로 연결을 더 추가하거나 제거할 수 있습니다.

연결 요청: 클라이언트(예: 웹 요청)가 들어올 때마다 애플리케이션은 풀에서 기존의 사용 가능한 연결을 가져와 사용합니다. 이 연결은 클라이언트 요청을 처리하는 동안 사용됩니다.

연결 반환: 요청이 완료되면, 사용한 연결은 닫히지 않고 풀로 반환되어 다음 요청에서 재사용할 수 있습니다.

연결 수 관리: 연결 풀은 최소와 최대 연결 수를 관리합니다. 필요에 따라 새로운 연결을 생성하거나, 사용하지 않는 연결을 제거하여 자원을 효율적으로 관리합니다.