-
Notifications
You must be signed in to change notification settings - Fork 4
[1주차 피어 세션: 20조 & 21조 🌿]
- 21조: res.cookie로 담아서 보냄
- 페이지 이동 시 사라진다
- Nginx로 배포하는 법 공부해보세요
- 지금까지 미션을 하면서 BE 개발을 하고 FE 개발을 하는 방식이 괜찮았다
- 리액트 잘 몰라서..
- 타인의 코드를 리팩토링하기
- deploy.yml이 dev 브런치에 push되면 스크립트 실행. 이 파일은 숨겨놓았는지?
→ 서버에 올라가 있어서 따로 셸스크립트는 따로 업로드 하지 않았다.
-
힘들었던 것들 중 하나가, pw 접속이 아니라 개인 private key 인증 기반으로 접속하는 것을 적용하려고 했는데 서버에서 public key를 가지고 있고 클라이언트에서 private key를 가지고 있어야 하는데 그 때 다른 조원들이 접속할 때 내 private key를 뿌려 줌. 그런데 그 후에 사용자가 바뀐 것 같다며 잘 작동하지 않음. 어디 접속하느냐에 따라 private key를 나누는 방식으로 해결함.
→ 호눅스님: ㅜㅜ 그것도 아닙니다......공개키를 여러개 추가하면 됩니다. 일단 돌아가면 되니까 잘 하셨어요^^
각 private key(열쇠)에 대한 public key(자물쇠)를 등록하면 된다.
자신의 private key를 뿌리는 건 한 사람의 사원증으로 돌려 쓰는 것과 비슷함
- 원본 그림(?) 보여주심
- 시행착오를 걸쳐서 정착됨
- 네
- 이슈가 100만 개 있다고 해보자
- 페이지로 나누어서 페이지로 가지고 오게 된다
- 그 후에 처리를 하다 보면 문제가 생길 수 있어서 백에서 하는 게 맞는 것 같다.
- http 요청 개수를 줄이는 게 맞지 않을까?
- 해람님: 졸업작품으로 이미지 200개를 가지고 오게 했는데 그것만으로 브라우저가 1초 멈췄다..
- 이슈 등록 시 이미지를 올리는데, 기획서에 보면 이미지를 서버에 업로드→그 주소를 가져와서 마크다운 형식에 맞춰 본문에 삽입 으로 되어 있다. 어떻게 하는 게 좋을까?
- 파일 업로드 할 서버가 필요할 것 같다
- https://apidocs.imgur.com/ 를 써 보는 건 어떨까 (hackmd가 하는 방식처럼) → 비상업적인 용도로는 무료이다!
-
클라이언트가 프론트를 보려고 하면 그 때 어느 서버에서 가져올지 → 로드 밸런서 a가 나누어줌
-
로드 밸런서 b는 백 서버를 보고 있다가 요청이 들어오면 나눠주는 방식으로
-
해람님 그림
-
상신님 그림
-
로드 밸런서가 프록시 서버처럼 역할하면 이런 구조는 힘들 것 같다.
- BE
- 깃헙 로그인 기능
- FE
- CRA 관련 이슈 (CRA를 사용하지 않고 웹팩 설정하는 방법이 나와있지 않았다)
- 자주 쓸 component 등은 따로 파일로 분리해서 import하여 사용
- 인증 정보가 없으면 root url에서 /login으로 이동
- 렌더링을 할 때 인증이 되어 있으면 그 안의 컴포넌트들을 렌더링, 인증이 되어 있지 않으면 로그인 페이지를 렌더링
- BE
-
대부분의 api 구현 (sequelize 사용)
-
더미 데이터 삽입, seeders 사용 (외래키로 인해서 실행 순서를 잘 맞춰 주어야 한다), bulkInsert, bulkDelete
→ db 초기화 시 유용하다
-
테스트: mocha 사용
- api들을 이용해서 테스트 진행
-
- FE
- 다음주부터 구현 시작할 예정
Q. 한 게 많은데 협업은 어떻게 했는지?
- 쉽게 구현할 수 있는 부분은 나눠서 함. 대신 후에 리팩토링을 서로 해 줬습니다
Q. Service 계층을 나눌 계획은 없는지?
- 구조에 대해서 좀 더 고민한 후에 결정할 것 같습니다
Q. open / close 한 사람을 표시할 필요가 있나요?
- 저희가 좀 착각한 것 같습니다...ㅎㅎ