[Meet up with Mentor] 22.11.16

🙋‍♂️[BE] 예외 처리는 어디서 해야할까요?

• 예외처리는 보통 Repository layer말고 Service layer에서 함.
• 공통화 할 수 있는 방향 찾아보기
• Annotation 붙이는 방법 추천

🙋‍♂️[BE] Catch 하지 못한 에러를 전역에서 잡았을 때, 서버를 종료할지, 로깅만 하고 일단 넘길지

• 서버를 실행할 때 환경변수를 가져와서 세팅하고, 이 때 에러가 발생하면 코드를 고친 후 다시 Running을 하는 것이지, 이 외에는 서버를 종료하는 케이스는 거의 못본 듯.
• 추가적으로 말하자면, 서버 로그는 계속 쌓이기 마련이고 로그도 결국 용량을 차지하기 때문에, 로그가 쌓여서 디스크 용량 부족으로 서버가 종료되는 경우는 있을 수 있다. 이걸 방지하기 위해 로그 백업 정책 등도 고려해볼 수 있다. (NGINX LOG 로테이션)

🙋‍♂️[BE] 백엔드에서 고민해볼 사항들

• 확장성있는 서버를 만들기 위해서 어떻게 해야할까?
• 트래픽이 몰릴 때 어떻게 스케일 아웃을 해야할까? 설계를 고민해보자.
  • 지금 구조에서는 어떻게 할 수 있을까?
• 스케일 아웃이 안되는 서버의 예시는 서버에서 직접 상태를 저장하는 경우가 있다. 여러 서버 인스턴스를 생성한다고 했을 때, 한 인스턴스에서 상태를 가지고 있다면, 다른 인스턴스에도 이 상태를 공유할 방법이 필요하다 (Redis, 공유하는 DB). → Stateless

🙋🏻‍♀️[FE] URL에 대하여

• Asnity의 커뮤니티/채널과 비슷하게, 디스코드는 서버/채널, 슬랙은 워크스페이스/채널이 있는데, 클라이언트의 라우터 구조가 다음과 같다.

  디스코드
  /channels/:serverId/:channelId
  
  슬랙
  /client/:workspaceId/:channelId

  • 우리의 경우 당연히 /communities/:communityId/channels/:channelId의 구조를 생각하고 있었는데, 두 개의 채팅 서비스 모두 저런 구조를 따르니까 뭔가 이유가 있는건가 싶었다. →
  1. 사용자 입장에선 사실 URL의 의미를 모르고 사용해도 무방하다.
  2. 사실 URL의 길이에도 제한이 있다. 예시로 상품 목록에서 상품 미리보기 페이지로 넘어갈 때, 상품 정보가 URL Param에 들어가서 길어지는 경우 문제가 생길 수도 있다.
  3. 추가적으로, 페이지 요청을 GET이 아닌 POST로 할 수도 있다는 점을 알아두자.

🙋🏻‍♀️[FE] React 디렉토리 구조

• 많이 사용되는 구조는 Group by types으로 불린다.

  /src
  	/components
  		/Button
  		/TextButton
  		/Gnb
  		/Lnb
  		...
  	/apis
  	/hooks
  	/page
  	/types
  	/utils

• 우리가 시도해보려고 하는 방법은 Group by features로 불린다.

  common/
    Avatar.js
    Avatar.css
    APIUtils.js
    APIUtils.test.js
  feed/
    index.js
    Feed.js
    Feed.css
    FeedStory.js
    FeedStory.test.js
    FeedAPI.js
  profile/
    index.js
    Profile.js
    ProfileHeader.js
    ProfileHeader.css
    ProfileAPI.js

• 현업에선 아마 Group by types 구조를 더 많이 사용할 것이다.

• Group by features는 중복되는 컴포넌트나 api들을 분리하는 작업을 부지런히 해야할 것 같다.

• 어쨌거나 구조를 갈아엎는건 코스트가 매우 높기 때문에 신중히 결정해야 한다.

• 토이 프로젝트 레벨이 아닌 실무 레벨로 넘어가면 컴포넌트 단위로 중복되지 않고 딱딱 맞아 떨어지는 api 응답이 오는 경우는 많지 않다. 같은 상탠데 다른 변수명으로 온다거나, 뒤죽박죽 섞여 오는 경우가 더 많다. 그래서 Group by features구조를 선택하더라도, 해당 구조의 장점을 다 활용하긴 힘들 수도 있다. (Group by features에선 feature단위로 component, api, hooks 등을 분리하기 때문)

• 테스트는 누구나 작성하기 싫어하지만, 뭔가 강제성을 부여하고 싶다면 시각적으로 Coverage를 보여주는 도구를 사용해도 된다. GitHub Action에 CI 이후 Test Coverage가 얼마나 증가했는지 보여주는 도구가 있다.

  • github action pr converage정도로 검색해보자.

🙋🏻‍♀️[FE] 라이브러리를 사용할까, 직접 구현할까

• 생각보다 라이브러리 엄청 많이 쓰지는 않는다. 작은 기능은 직접 구현해서 사용하는 경우도 많다. 사용자 적고, Update한지 몇 년 지난 불안정한 라이브러리 사용할 바에 직접 만들어서 유지보수한다.

🙋🏻‍♀️[FE] GPU 가속

• Reflow를 유발하는 CSS 속성들이 있고, 그렇지 않은 속성들이 있다. 대표적으로 width, height, margin, padding, top, left등이 Reflow를 유발한다.
• transform등을 사용하면 GPU에게 계산을 넘길 수 있어서(JS는 CPU가 실행한다.), 버벅임이 줄어들어 사용자에게 좀 더 좋은 경험을 제공해주 수 있다.

🙋🏻‍♀️[FE] 프론트에서 고민해볼 사항들

• 새로운 기술을 여러가지 적용해보기 보다는, 한정된 라이브러리를 사용하면서 코드 퀄리티를 높이는 노력을 해보자.
• Eslint Rule 등으로 일관된 컨벤션을 지키는 등.
• 의외로 실무에서 Typescript의 Strict옵션을 잘 활용하지 않는다. 라이브러리를 여러개 붙이다보면 타입 파일이 없는 경우가 많아서(JS only library) 오류 나는 경우가 많다.

🙋🏻‍♀️[FE] Push API

• 알림 요청등은 Push API를 사용한다. 사실 사파리에선 아직 지원을 제대로 안한다. 앱을 사용하는 가장 큰 이유가 푸시 알림을 지원하기 때문인데(쇼핑몰 어차피 안에서 인앱 브라우저로 띄워주는데 왜 앱으로 만들까? → 푸시알림 때문에…) 이게 브라우저에서도 지원되면 굳이 앱을 사용할 필요가 있나?

  • Discord는 멘션이 오면 개수에 따라 Favicon이 바뀐다. Push API 쓰는걸수도?

• 앱은 네이티브한 환경이므로 성능이 좋음

• 웹은 VM 위에서 동작하는 구조라 성능이 좀 안좋다.

• 모바일 웹은 File storage와 같은 store를 아직 지원하지 않는다.

• 푸시알림이나 storage관련해서 모바일 웹이 지원할 때에는 굳이 앱이 필요 없을 수도.

🙋🏽‍♂️[공통]

• 백엔드는 TDD를 추천합니다. 테스트 코드를 먼저 작성해보고 그에 맞는 코드를 짜는 경험이 있다면 좋을 듯
• 프론트는 TDD 잘 안하는 듯.
  • UI 테스트는 힘들다. 자주 바뀌기 때문. 자칫하면 테스트 코드 관리 비용이 더 나간다.
  • 핵심 비즈니스 로직들은 당연히 테스트 해야한다.