-
Notifications
You must be signed in to change notification settings - Fork 0
2주차 멘토링
Ji Yoon Choi edited this page Nov 16, 2022
·
19 revisions
- 100% 탈취된다
- Github Action 등의 방법으로 캐싱 해야함
- 로그인할 때 사용되는 ID 등의 개인정보는 최대한 막되, 백엔드 측에서 마스킹 등을 해서 정보를 은닉하여 내려줘야 한다
- AUTO_INCREMENT 되는 키를 ID로 사용한다면 => 전역 상태로 저장되는 것은 나쁘지 않으나 브루트포스 공격에 당할 위험이 있다
- 일반 사용자가 보기에는 아무 의미없는 숫자라서 프론트엔드 측에서 저장하는 것도 상관없어 보임
- 브루트포스 공격을 막고 싶다면 UUID를 생성하여 사용하는 것을 추천 (AUTO_INCREMENT 아닌 완전 랜덤한 문자열)
- AUTO_INCREMENT를 쓰는 경우 => 게시판에서 게시글이 1부터 올라가는 경우 (Public 하게 공개되기 때문에 노출되어도 상관없는 데이터)
-
약관을 추가하여 너의 닉네임과 이메일을 어디에 사용하겠다 ~ 라고 명시
-
개인정보 약관 관련 질문은 멘토링하면서 처음 받아보았다
- Next.js의 장점?
- 첫 화면을 SSR로 구현하려고 할 때, Next.js를 사용하는 것이 좋을지?
- 사용에 대한 조언? 적용해도 좋을지?
- SSR을 배우기 위해 Next.js 를 배우기엔 시간이 촉박한 것 같다
- 자료조사 까진 OK, 다만 진입장벽이 좀 있음
- 어느 정도 완성된 프로젝트에 Next.js를 도입하는 것이 괜찮은 선택일까? 아니면 처음부터 Next.js를 도입해서 작성하는 것이 나은가?
-
getServerSideProps
에 관해 공부하는 것을 추천 - SSR로 렌더링을 하면 기존에 요청-응답으로 받아오던 데이터가 Serverside props에 전부 들어감
- Next.js 는 Serverside Props를 한번에 받아서 페이지에 전부 넣어 렌더링하는 방식으로 동작하므로, 관련된 이해가 좀 많이 필요하다
- SSR 쪽에서 받아올 데이터와 CSR로 받아올 데이터를 명확히 나누는 것이 중요하다 (모든 데이터를 서버 쪽에 박는 것이 능사는 아니다) => 서버 쪽 처리가 오래 걸리면 어차피 첫 화면 표시까지 오래 걸린다
- 이런 정책을 세우고, Next.js를 공부하는 데 들어가는 시간이 생각보다 많을 것이다 (우리는 이제 한달뿐이다)
-
- Next.js의 이점: 라우팅을 더 쉽게 해준다
4. 현업 CI 과정에서 테스트를 진행할 때, 전체 코드에 대한 테스트의 커버리지 퍼센트를 넘지 않으면 push 가 안되도록 하는 단계가 있나요? 있으면 어떻게 하는지 궁금합니다.
- push를 막는 것을 본 적은 없는데, 있을 수는 있다
- 모든 코드를 테스트할 수 있는 것은 아님 (현실적으로 테스트를 못 하는 코드가 있음 => 이걸 테스트해보겠다고 억지로 짜는 건 더 손해)
- Real 환경에서만 작동되는 코드가 있다면, 개발환경에서 테스트가 아예 안 되듯이
- 따라서 어떠한 커버리지를 넘지 않으면 머지를 안 하는? 옵션은 위의 예시처럼 반례가 존재할 것 같다
-
github action coverage report
참고- 컨벤션 수준으로 맞추는 것과, 커버리지 숫자가 증가 추세에 있다는 것만 보이면 된다
- Github Action Cache
- npm i가 오래 걸릴 것
지금은 액션 명령들이 직렬로 짜여져있어서, 병렬로 분할하는 것을 추천프론트엔드 - 백엔드 별개의 Workflow, 또는 별개의 Job으로 분리하면 병렬로 동작할 것
- runner가 nCloud 하나밖에 없어 병렬 실행이 안 될듯
- 병렬 실행은 runner가 2개 이상이어야 함
- 해결법
- self-hosted를 쓰지 말 것
- 빌드는 깃허브에서 제공하는 runner를 사용
- 빌드 결과물을 깃허브에 임시 저장 (
github actions artifact upload
) - nCloud는 artifact에 저장된 내용물을 갖다 쓰기만 하고, 빌드는 github에서 제공하는 runner를 사용하면 병렬 빌드로 시간을 많이 줄일 수 있다
- nCloud CPU 사양 (개수 등) 설정이 가능 => CPU 개수가 늘어나면 속도가 좋아질 것이다
- CPU 성능 문제로 느린 것일 수도 있다
- CI/CD는 어렵구나!!!
- https://github.com/boostcampwm-2022/web25-SCOPA/issues/25
- 모노레포?
yarn workspace monorepo
- 클라이언트가 서버
share
폴더를 참조할 수 있고, 서버가 클라이언트share
폴더를 참조할 수 있다
- 현재 파일구조로는 아마~ 참조는 할 수 있음
- 단 현재 파일구조에서는 shared 폴더는 어떤 컨벤션을 따를지, 어떤 typescript 버전을 쓸 지 알 수 없는 상황이다 (클라이언트 - 서버 구조가 분리되어 있는 편)
- 루트 경로에 eslint, tsconfig, prettier 등을 배치해서 컨벤션과 타스 버전을 맞춰놓고, 하위 폴더를 클라이언트 / 서버로 분리하는 구조로 해야 할 듯
- 기술적으로 도전할만한 요소가 있을까요?
- 반응형 웹 => PC, 모바일을 하나의 컴포넌트로 처리하기 (이것만으로도 쉽지 않을듯)
- 페이징, 상태관리는 이미 적용해봐야 하는 기술일 듯
- 이정도면 Next.js를 도입해볼 만도 할 것 같고
- 채팅?
-
server sent event
: 서버와 클라이언트간 연결이 계속 열려있고, 서버에서 이벤트가 발생하면 계속 응답을 주고, 클라이언트는 계속 그 응답을 받음- 단방향 으로밖에 통신이 이루어지지 못함
- 서버 쪽에서도 기술 검증이 좀 필요해보임
-
push API
는 어떨까요? => 서버 - 클라이언트간 연결이 계속 열려있진 않고, 구글 서버를 중간 브로커로 두고 브라우저에 이벤트를 쏘는 방식 - 프론트엔드에서 10초에 한 번씩 추가 채팅이 있는지 백엔드에 찔러보는 것도 하나의 방법이며 매우 간단한 방법 중 하나 (마지막으로 읽은 쪽지의 ID 등을 서버에 계속 찔러주는 방식)
- 시간이 남는다면 채팅 정도는 구현해볼 만 할 것 같아요
-
- 이런 기술들도 다 사용할 때가 있다
- 동시 접속 문제 등 하위에 파생되는 문제점과 그걸 해결하는 과정으로도 많이 배울? 수 있음
- 채팅의 변형판 => 쪽지? 댓글?
- 이번 프로젝트에서는 그럴 필요까진 없을듯
- 실제 서비스라 가정하면 분리하는 것이 좋다는 것을 염두에 두고 이야기를 해보는 것이 바람직함
- scale-out
- 두 서버 중 한 쪽이 죽는다고 해서 다른 한 쪽이 죽으면 안 되므로?
- 지금 프로젝트에서 그것까지 구현하는 건 오버스펙이다
- 현실적인 한계
- 서버비가 없음
- 서버사이드 로직을 직접 구현하기에는 레거시가 너무 커짐 + 관리비용이 큼
- Next.js는 검증된 라이브러리, star 수가 많고 전세계적으로 널리 이용됨
- Next.js가 지원하는 SSG 도입하기에 안정적일 경우
- 나 이거 해봤다 보다는 어떤 생각과 어떤 경험을 하는지, 어떤 어려움이 있었고 극복했는지가 더 중요하다
- 위에서 시키는 사람 아무도 없지만 각자 주도적으로 할 일을 찾아 작업하는 태도가 더욱 중요하다
- 맡을 부분을 명확히 나누는 것이 1차 => 컴포넌트 레벨에서는 충돌이 나지 않을 것
- presentational 부분에서는 같이 충돌 제거
- 같이 쓰게 될 데이터나 데이터를 담는 인터페이스 등 => 시니어가 먼저 작업해서 전부 올려둠
- 같이 작업하면 1000% 충돌남, 먼저 작업을 해서 올려놔야 분업 후에도 참고해서 작업함
- 위의 내용은 원론적인 얘기; 그때그때 의사소통이 중요
- 공통으로 사용할 요소들을 각자 만들다가 share로 올리는 등
-
Typescript enum 관련해서 Tree-shaking 관점에서 좋지 않아서 enum 을 사용하지 않는 것을 권장하는 글을 봤습니다.
- 실제로 현업에서도, enum 을 사용하지 않고 있나요?
- 만약 사용하지 않고 있다면, enum 과 같은 열거형 상수를 필요로 할 때 어떤 방식으로 사용을 하시는지 궁금합니다.
-
const enum
을 사용하면 용량을 조금 더 줄일 수 있다 -
예전과 달리 네트워크 성능와 압축 기술이 좋아짐
- HTTP2에서는 용량을 이미 줄이고 있음
-
자바스크립트 코드가 압축 후에도 MB 단위로 나온다면? 그 때는 트리쉐이킹을 체크해야 함
-
lodash
라이브러리에서 이 문제가 좀 발생하기 때문에 이를 위한 웹팩 설정 작업 등을 해야 할 것
-
-
enum
이 찝찝하면const enum
, 이것마저도 찝찝하면 객체 상수로 만들어 사용 -
readonlyArray
는 잘 안 쓰는 방식인데, 써도 나쁠 건 없을듯- 어떤 함수에서 값을 수정해버리면 side-effect가 발생할 수 있는데, 이런 실수를 막는 차원
- 다만 이 함수를 전달할 때
readonly
를 전부 붙여줘야 한다는 단점이 있음 (코딩 효율 저하?) - 그래서 일반적으로는 잘 안 씀
-
기술 도입 또는 리팩토링 시에 자료조사, 예시, 우리 팀에 도입하면 어떤 장점이 있을지 설명, 일부 코드만 리팩토링해서 시연 등 필요
- 왜 썼는지가 더 중요하다는 뜻
- 기술 도입 또는 리팩토링에 부정적인 생각을 갖는 사람들도 설득시킬 수 있을 정도로 설명을 잘 해야한다
- 📃 기획서
- 📂 Backlog
- 📊 ERD, 폴더 구조
- 🗓️ 회의록