백엔드 & 프론트엔드

• 다음주 화요일까지 프론트엔드 작업 끝내고 꼭 API 연동작업 들어갈 것
  • 다음주 목요일이 발표라서 수요일부터는 발표자료 준비하고 문서화하는데 시간 들어감. 결국 개발은 화요일까지 가능
  • API 연동이 MSW가 잘되어있으면 서버 API만 갈아치워도 된다고 생각하지만, 막상 연동할 때 서버 이슈가 있거나, 백엔드 예외처리가 안되어 있거나 프론트 예외처리가 안되어 있는 부분 추가적으로 생길 거라서 병목현상이 있을 것이다.
• 개발자도구 네트워크 탭 > 특정 항목 선택 > Timing 을 보면 느리게 보여지는 이유가 프론트엔드인지 백엔드인지 알 수 있음. waiting for server response를 보고 백엔드 개선 작업 요청할 것. 보통 DB query에서 오래 걸리거나 서버에서 복잡한 작업을 하거나 둘 중 하나의 경우가 많음. 수많은 병목 현상을 만날텐데 백엔드에서 오래 걸리는 리스폰스를 프론트엔드에서 최적화하려고 하면 맨땅에 헤딩하듯이 되니까 잘 구분해야 함
  • 이미지 렌더링하는 부분 프론트에서는 loading lazy 속성 넣어서 필요한 부분만 빠르게 로딩
• 동영상이나 사진 업로드할 때 네트워크 끊기는 경우에 대해서도 대비가 필요함. 백엔드에서 트랜잭션을 돌리거나 사진 몇개를 올리거나 할 때 다 안올라가는 경우 생길 수 있어서 백엔드에서 고민이 필요함.
• API 연동할 때 CRUD가 너무 많다고 판단이 들면 가장 먼저 우선순위에서 제외되는 기능은 수정 기능
• 이미지 리사이징 작업은 서버 측에서 처리하는 것이 효율적이다. 일관성이나 클라이언트 성능, 캐싱 처리면에서 서버에서 작업하는 것이 일반적임. 이미지 파일을 올리게 되면 aws s3를 주로 사용하게 되는데 cdn 서비스와 가장 근접하게 맞닿아 있는 곳에서 하는 게 좋다. 보안성이나 유지보수적인 측면도 그렇고 자동적으로 처리하는 캐싱 등은 프론트에서는 할 수 없는 작업임. 이미지 업로드는 백엔드에서 s3에 올리고 주소를 리턴받아서 DB에 저장하는 게 끝인데 그 과정 중에 개선하는 게 관리측면에서 가장 depth도 짧음. 프론트에서 이미지 업로드를 하게되면 서버를 거쳐서 aws에 갔다가 다시 백엔드로 돌아와서 프론트엔드에도 알려주고 DB에도 저장하는 등 복잡해진다.
  • 나중에 Nextjs를 하게되면 내장된 기능으로 뷰 서버를 띄워서 webp 처리까지 해줌. 기회가 되면 꼭 한번 더 프로젝트 해보는걸 추천.
• 이미지 레터박스를 쓰는 경우는 잘 없음. 큰 사진을 잘라서 쓰는 경우가 일반적. 보통은 이미지 잘라서 쓸일도 없도록 서버에서 이미지 비율까지 잘라서 최적화함. 보여주는 박스 공간에 맞춰서 이미지 크기도 딱 맞아 떨어지게 함.
  • 비율이 안맞는 경우는 레터박스를 쓰기보다는 가득 채워서 사용
  • 트다에서는 자세 사진의 경우 누워있으면 가로가 길고 서있으면 세로가 길거라서 비율을 맞추기 어렵다면 레터박스를 쓸 수 있음. 레터박스를 사용한다면 하얀배경 때문에 어디까지가 영역인지 알수 없어서 테두리가 있어야 할 것 같다. 그리고 보여주는 부분이 얼굴이 중요하다 하면 위쪽으로 자르거나 몸이 중요하다 하면 중앙부분으로 자르거나 할 수 있음. 업로드한 이미지의 크기가 정한 기준보다 작을 때는 가로 세로 중 큰 쪽에 맞춰서 리사이징하고 레터박스 쓸 것. 다양한 케이스의 이미지 크기에 맞춰서 분기처리해서 CSS 적용 (레터박스 쓰거나 넘치는 부분 자르거나)

프론트엔드

• 디자인 색감이 전체적으로 약한 느낌. 색깔이 약해서 비활성화처럼 보이는 버튼이 많음. 색깔을 더 진하게 사용해도 좋을 듯.
• 무한스크롤이 적용되는 곳에서 스크롤을 내릴 때 탭이 따라 오는가? 사용 편의를 위해 유지보수 측면에서 생기면 좋을 것 같다
  • 또는, 무한스크롤할 때 뷰포트 내 특정 박스 안에서만 움직이게 해서 헤더와 탭부분이 뷰포트를 벗어나지 않도록 하는 방법도 있을 것 같음 (수민 생각)
• react-query로 infinite scroll 기능이 있으니까 page와 size를 넣으면 무한스크롤 호출이 가능함. 무한스크롤이 필요한 곳에서 라이브러리 대신 사용하는 것도 고민해볼 것
  • react-query를 딥하게 쓸 수 있다는 강점이 있음
  • 어렵다면 무한스크롤 라이브러리를 사용하거나 옵저버 사용해서 개발기한에 따라 구현하고 리팩토링 때 react-query로 바꿔보는 것도 좋음.
• 무한스크롤을 특정한 라이브러리를 선택했다면 면접장에서 선택 이유에 대해 물어볼 때 답할 수 있어야함
  • 개발기한에 맞춰서 구현하려고 할 때 간단하게 빠르게 적용할 수 있고 무한스크롤에만 집중해서 나온 라이브러리여서 선택했다고 하면 평범한 답변
  • npm trends를 보면서 비교하고 선택했다는 점을 어필해야함. 여러 라이브러리를 고려했는데 사용량 측면이나 유지보수 측면(깃허브 들어갔을 때 계속 이슈에 대해 적극처리하고 있는지), 안정성 측면에서 선택했다고 하면 좋은 답변
  • 라이브러리가 현재 어디서 사용되고 있는지 깃허브 계정이랑 레포지토리 이름도 볼 수 있음. 이렇게 많은 사람이 사용하고 있다는 내용이 보충되면 좋을 듯
  • 별개의 이야기로, 라이브러리의 contributor가 되면 강점이 있음. 오픈소스의 생태계 기여한 사람에 대해 공고가 올라올 때 지원해볼 수 있음
• 무한스크롤 자체가 기본적인 내용이라 어필할 점은 안되지만 구현한 코드의 이해도와 활용 방법을 명확히 설명할 수 있다면 어필 포인트가 될 수 있음
• 차트 라이브러리가 여러개이고 기능적으로 제공하는 것도 비슷할텐데 React-charjs-2를 선택한 이유가 좀 더 이로운 점이 있어서 선택한건가?
  • 기본적으로 제공해주는 생김새가 예뻐서 선택했음 (라이브러리 선택이유 보완이 필요할 듯)
• 가로 무한스크롤이 들어가는 부분에서 데스크탑의 경우 마우스 휠로 현재 가로 스크롤 할 수 있도록 했는데, 사용편의상 드래그할 수 있게 넣는 게 좋을 것 같음 (owl-carousel 플러그인 찾아볼 것)
• 라우팅 처리를 할 때 리소스를 판별하는 주요 파라미터 (트레이니 ID 등)는 url 경로에 포함시키는 것이 좋고 정렬 순서나 페이지 번호등은 쿼리스트링으로 처리하는 것이 restful API 디자인 원칙에 부합. seo 측면에서도 url 경로 지정한 것을 우선순위를 높게 잡아줌
  • 현재 라우팅 Url restful하게 잘 작성된 것 같다