멘티 질문
소셜 로그인을 현업에서는 어떤 방식으로 처리하나요??
현재까지 모든 데이터 통신은 사내 API를 통한다는 정책이 지정되어 있었다.
조직마다 다를 것 같긴 한데, 보통 인증 관련은 서버에서 토큰 관리를 진행하기 때문에 저 같은 경우에는 모든 API는 회사의 서버 API를 통해 작업했습니다.
어느 정도 규모가 있다면 토큰 관리하는 것에도 이슈가 있을 수 있기 때문에 어떤 서비스를 제공하냐에 따라 다르겠지만 보통은 백엔드 쪽 API가 만들어지면 서버 API를 통하는 게 맞지 않나 싶습니다.
모든 로그인 방법에 대해서는 백엔드 API 만들어주는 곳을 통해서 하고 있습니다. (보안 이슈도 있을 수 있다.)
MVC 패턴 시 Props 드릴링을 효과적으로 관리하고 줄일 수 있는 부분이 있을 수 있을까요?
전역으로 뺄 수 있으면 전역으로 빼고 그렇게 진행할 수 있을까요??
props 드릴링 자체가 MVC 패턴이 아니라도 발생할 수 있기 때문에 props 자체를 쪼갤 수 있는지 확인해야 할 것 같다. 어쩔 수 없는 부분들도 있겠지만 정말 필요한 props 인지 판단할 수 있어야 할 것 같다.
props 드릴링이 공통된 부분에서 어느 정도 발생한다고 생각이 들면 props 드릴링을 줄이려고 store로 뺐다.
그게 아닌 경우에는 사실 애매한 부분이 있긴 해서 코드 리뷰에서 다른 분들과 이야기를 하고 이런 케이스들에 대해서는 store로 관리를 하자고 정책을 잡는 식으로 해결했다.
케이스 별로 정책을 정해보면 좋을 것 같다. (코드 리뷰 진행 시 다른 분들께 한번 고민해 달라고 한다.)
근본적으로 MVC 패턴 자체가 필요하지 않은 상황 같기는 하다.
MVC 패턴으로 인해 props 드릴링이 일어나는 경우라면 사용하지 않는 것도 방법이라고 생각한다.
적절한 사용에 맞는 디자인 패턴을 사용하는 것이 좋은 것 같다. (MVC 패턴은 좋은 패턴이지만.. 상황에 맞는 패턴을 사용하자)
MVC가 기본적인 아키텍처 패턴이지만, MVC 패턴이 맞지 않다면 모든 프로젝트에 동일한 패턴을 적용시킬 필요는 없을 것 같다.
같은 성격인 경우에는 맞추는 것이 좋지만, 성격이 다르다면 다른 패턴을 적용시킬 수 있을 것 같다.
비슷한 성격인데 다른 패턴이 적용되면 작업자 입장에서 혼동이 올 수 있고, 유지 보수 시에 좋지 않은 효율을 발생 시킬 수 있다.
큰 카테고리를 나눠서 디자인 패턴을 정하는 것이 좋을 것 같다.
추가로, MVC 패턴에 대해서 고민을 해보면 좋을 것 같다.
커피챗
회원가입
회원 인증은 카카오로만 하려고 하고 있습니다.
카카오 정보를 토대로 로그인하도록 처리하려고 하고 있습니다.
1차 스프린트 태스크는 잘 진행되고 있나요??
서버에서 데이터가 넘어와야 처리 가능한 부분들이 있다 보니 조금 딜레이가 되고 있는 상황입니다.
1차 스프린트 API 배포(백엔드)
API는 1차 스프린트 관련 기능들을 주말까지 배포하겠다고 했습니다.
현재 대체로 완료는 되었지만, 백엔드 분들끼리 서로 통합하는 과정 진행 중입니다.
API 명세서는 아직 나와있는 게 없나요??
API 명세서는 나와있지만, API를 테스트할 수 있는 방법이 없어서 기다리고 있는 중입니다.
공통 컴포넌트 기획이나 UI 디자인 시안에서 이슈가 나오는 부분은 없나요??
현재까지 나온 건 없고, 디자인도 스프린트 단위로 끊어서 디자인을 보완하고 있습니다.
ex) 1차 스프린트 시작전에 해당 부분을 다듬고, 2차 스프린트 시작전에 해당 부분들을 다듬고 시작할 것 같습니다.
2차 스프린트 시작 기간은 ?? 다음주 (월요일)
프로젝트 초기에는 메인 테스트 및 공통 컴포넌트 만드는데 시작이 많이 소요되기 때문에 문제가 많지는 않을 것 같다. 페이지의 완성도가 높아질수록 페이지 이동 관련하는데도 이슈가 있을 것 같다.
중간중간마다 잘 체크하고 있기 때문에 예상되는 이슈들은 없을 것 같아서 예상되지 않는 문제들이 발생하면 어찌 되었든 처리를 해줘야 하는 부분이다 보니.. 그 부분만 잘 해결하면 될 것 같다.
배포도 딱히 이슈도 없는 건가요??
테스트하면서
fix할 부분이 있다면 fix해서 dev로 머지 할 계획입니다.