✅ 체크리스트

이번주에 우리 팀이 되고 싶은 모습을 상상하며 체크리스트를 추가해봐도 좋습니다.

멘토가 보기에 우리 팀은 어떤지 의견을 구해보세요.

• [ ] 계획한 목표의 80% 이상 구현하고 있다.
• [x] 작성한 코드나 구현 과정을 근거 있게 설명할 수 있다.
• [ ] 의사 결정 사항과 문제 해결 과정을 누구나 볼 수 있게 정리하고 있다.
  • 모든 의사 결정을 문서로 남길 수 있도록 하기
• [x] 서버 연동이나 배포를 시도하고 있거나, 이미 배포 되었다.

✔️ 결론 및 To Do

멘토링 이후에는 결론과 To Do를 작성하고 실천해보세요.

멘토에게도 공유하여, 의도와 다르게 정리되지는 않았는지 검토를 받아볼수도 있습니다.

✔️ 멘토링 전 작성한 질문

1. GET /post/1 을 통해 상세 페이지 API 호출을 하는 경우 참여자 목록을 보여 주는 경우도 있고 아닌 경우도 있는데 participantList를 함께 보내 주는 것이 맞을지?
   • 기존에는 participantList를 따로 요청하는 API가 있었음, 현재는 합친 상태
   • 네트워크 요청을 최대한 줄이는 것이 좋을까요?

⇒ 영도: 프론트의 미덕 = 서버가 어떻게 던져주든 간에 알아서 잘 조합해서 이쁘게 만들어주면 그만이다~ 저는 FE가 최대한 맞춰주는 쪽. 특정 필요한 데이터만 쿼리로 날릴 수 있는 graphql도 생각이 났다.

⇒ 한날: 쿼리를 날리고 한 번 더 날려야 완성되는 n+1 문제 발생 가능. 서버가 편하게 내려주고 클라이언트가 맞춰서 보내주는 게 물론 서버 입장에서 좋지만, 데이터들은 계층적(게시물→유저정보→댓글정보…)인 반면 URL은 비선형적. 그래서 graphql이 좋다. FE에서 UI 구성에 너무 병목이 된다면 BE가 맞춰주는 것도 좋고… 엔지니어링 관점이라면 (그리고 보통은) 클라이언트에서 가이드 해주는 것이 좋음. (결국 사용자 경험이 중요하므로)

1-2. 프론트엔드/백엔드에서 로직 누가 가져갈 거냐 어떻게 결정?

• 기술 리더, CTO, 시니어 없어서 주니어들끼리 모였을 때 결정 내리는 것 어려울 수 있음.