강의를 들으며 정리했습니다.혹시 틀린내용이 있다면 댓글로 알려주세요!

react,next 00. 강의소개 - 프로젝트 구조와 프론트,백엔드구조

React로 NodeBird SNS만들기

프론트

유저가 보는 화면을 꾸려준다.

• React,Next

• Redux

• Redux-saga

• Styled Components

백엔드

게시글 작성, 동영상 작성 및 댓글작성 기타등등.

• Express

• MySQL

• ORM(시퀄라이즈)

• 패스포트

• muter(S3)

• Socket.IO

• 이미지 압축(람다)

왜 프론트와 백엔드를 분리하나?

노마드코더에서 유튜브클론 강의를 들을때 express와 템플릿엔진을 써서 한 폴더의 프로젝트에서 작업을했던 기억이있다.
하지만 리액트까지 학습을진행했을때 client폴더와 server폴더로 프론트와 백엔드를 분리시키기 시작했다.

• 스케일링 이슈
  • 프론트 서버와 백엔드 서버가 분리되어있다면, 프론트서버 요청이 많은경우 프론트서버만 증설, 백엔드 서버의 요청이 많은경우 백엔드서버만 증설하면된다. 하지만 모놀리틱 구성이라면? 프론트서버와 백엔드 서버의 요청을 하나의 서버에서 처리하기때문에 선택지가 없다.
• 요청(req)이 많을경우 불필요한 메모리나 컴퓨터 자원소모를 절감할 수 있다.
  
  • Ex) 화면을 그려주는 요청이 많아졌다. 이 경우 프론트서버만 늘리면 될것을 프론트와 백엔드가 통합되있으면 백엔드도 같이 늘어나서 자원의 소모가 극심해진다.

단점

프론트와 백엔드 서버가 두개로 나뉨에 따라 발생하는 문제들

• 서버간의 통신에서 발생하는 문제(http 및 https)

• CORS 이슈 및 여러 보안적인 측면에서 문제가 발생한다.

왜 Next를 사용하나?

리액트에서도 할 수 있지만, 직접 구현을 해줘야한다는 단점이 있다.

• 서버사이드렌더링 지원

  • 렌더링 작업이 완료되기 전에 사용자가 사이트 컨텐츠를 이용 가능
  • 검색엔진최적화(SEO) 가능
    
    

• 코드 스플리팅 지원

  • 전체 500개 페이지중에서 필요한 페이지만 불러오는 기술

React vs Next !?

자세한 답변

• SEO가 필요하다면 Next!

• 그렇지 않다면 React!

자세한 설명은 생략합니다.
이 글은 편의를 위한 글 입니다.
> 초보 몽키님의 블로그에 아주 상세하게 적혀있습니다.

개인 프로젝트하며 혼자 깃허브를 다룰때 사용하는 방식

git push

순서대로 진행합니다.

1. Git init

   • 루트디렉토리에 .gitignore 파일 생성

   • 파일안에 node_moduls 작성 및 github에 올리고싶지않은 폴더명 작성

2. git remote add origin “https://github.com/wjdwndtlr/travel”

   • ” “를 지우고 방금 만든 깃허브 레포지토리 주소를 복붙해준다.

3. git add .

4. git commit -m “initial commit”

5. git push origin master

   • origin은 서버를 뜻한다.

   • 여기서 서버는 깃허브홈페이지를 말한다.

     • 정확하게는 깃헙에 있는 코드의 원격 저장소 위치이다.

협동으로 git 작업할때 사용하는 방식

옛날방식입니다 - 23-8-27

작업전->후->브런치삭제 순서로 진행됩니다.

작업하기전

무조건 루트디렉토리에서 한다!

1. git pull origin master
2. git branch feature/”브런치명”
3. git checkout feature/”브런치명”

작업진행 후

무조건 루트디렉토리에서 한다!

1. git add .
2. git commit -m “”
3. git checkout master
4. git pull origin master
5. git checkout feature/”브런치 명”
6. git rebase master
7. git push origin feature/”브런치 명”
8. 웹으로 가서 pull request!

로컬에서 브런치삭제

git checkout master
git branch -D feature/"브런치 명"

rebase에대한 개인적인 정리..

사람1과 사람2가 현업을 한다.
둘다 똑같이 master에서 분기를 나눴고 브런치 1,2로 나뉘었다.

사람1이 먼저 작업을끝내 깃 푸쉬를 하여 깃허브에 Pull Request를 형성하였다. Merge후 동기화를 먼저 진행시켰다.

이후 사람2가 작업을 끝내 깃 푸쉬,Pull Request를 형성하였다.

사람2의 코드도 담당자의 코드리뷰 또는 Merge Pull Reqes 승인이 났다.
사람2는 Merge 이후 동기화 및 branch 삭제를 진행하지만, 사람2는 에러가발생한다.(깃허브 화면에 회색버튼이 나타난다고함..)

• 이때 필요한게 rebase이다.
  

• 똑같은 master에서 분기를했지만, 사람1이 먼저 자신의 로컬코드와 원본 저장소의 코드를 동기화 시켰기때문에, 사람2의 로컬코드와 원본 저장소(master)의 코드가 달라져서 에러가 발생하는것이다.