[Final Project] Dev-Log 8일차

Today I did

• 주말에는 oauth를 집중적으로 파서 거의 완성했다. 구글 로그인 같은 경우 지난 프로젝트때 (내가 아닌 다른 프엔 담당자분이) 구현하기도 했고 react-google-login 라이브러리도 있어서 금방 가능할 줄 알았는데 생각보다 뚝딱 만들어지지는 않았다. 지난번에 구현한 대로 따라한다면 구글 측에 요청을 보낸 후에 바로 받아와지는 유저정보를 요청 바디에 담아 보내 바로 사용했지만 오히려 구글측 액세스 토큰을 받아서 서버단에서 토큰 인증완료하고 데이터를 읽어 오는 것이 더 보안유지에 좋은 것 같아서 그대로 구현하게 되었다.

• 카카오 같은 경우에는 react-kakao-login으로 만들어 보려고 했으나 라이브러리를 쓰더라도 모든 구현을 하지는 못하고 결국 js sdk가 개입해야 할 것 같아서 후자로만 만들었다. 공식문서가 처음에는 많이 낯설었는데 코드와 씨름하다 보니 자연스럽게 이해하게 되었다.

• 소셜로그인 같은 경우 프론트와 백이 찢어져서 코딩을 하는 것은 시행착오가 많고 비효율적일 것 같다. 특히 서버단만 먼저 만들기에는 테스팅을 하려면 3rd-party token이 필요하니 postman으로 테스팅하기가 어려워 결국 프론트도 같이 구현하게 되었다. 예상외로 프론트 분들이 정리해 놓은 자료는 많은데 백단까지 친절하게 나오는 리소스는 많지 않아서 삽질을 오래 했다. 시간이 난다면 multer 이용 이미지 업로드나 oauth 쪽은 직접 코드 분석 포스팅을 올리고 싶은 생각이 든다.

• 거의 완성했다고 했지만 카카오 로그인 같은 경우 로그인시에 이메일을 받아오지 못하는 이슈가 아직 있다. 카카오에 어플리케이션 등록을 하고 정보 수집 범위를 설정할 수 있지만 비즈니스 계정이 아닌 경우 이메일 제공을 강제할 수 없어 이메일 제공을 거부해도 우리 서비스에 로그인/회원가입이 되는 상황이다. 기획단계에서 필요 이상으로 개인정보를 수집하지 않고/불필요한 프로필 정보를 줄이고 가입한 이메일로 사용자를 식별하기로 한지라 카카오로 로그인하는 사용자를 db에 저장할 때 애로사항이 생긴다. 이메일이 아닌 username으로 가입을 유도하여 db에 저장할 때 데이터에 통일성을 주는 쪽으로 이야기했으나, 불필요한 변동이라는 의견이 있었다. 오히려 카카오측에서 전달해 주는 사용자 pk를 사용해서 더미 이메일을 만들어 (111111@SalkaMalka.com의 형식) db에 저장하자는 의견이 더 힘을 얻었으나 '존재하지 않는 이메일의 형태만 가진 문자열'을 만든다는 것이 마음에 걸린다. 이렇게 해결하는 게 맞는지?

• api 문서와 데이터베이스의 수정은 계속된다... 이번이 마지막 수정이었으면 좋겠다. 수업 들을 때는 모호했던 restful한 api의 개념이 실제로 만들어 보기 시작하니까 점점 손에 잡히는 느낌이다. 물론 금칙, 규칙의 개념보다 api 디자인의 guiding principle? 정도의 느낌이라 모든 경우의 데이터에 들어맞는 정답은 없는 것 같아서 나 혼자서도 수정에 수정을 거듭했다. 이제 서버 라우팅에도 반영해야 한다.

• sr단계에서 프로젝트에 kick이 될 기능이 미흡해 보인다는 피드백을 받아 각자 프로젝트에 추가할 새 아이디어를 생각해 오고, 그것을 바탕으로 혼자 미니기획을 짰다. 현재는 익명으로 작성된 댓글이 추천수 베스트 3만 다르게 포매팅되어 상단에 보이는 식이었는데, 지식인의 패러다임을 따와 글쓴이가 가장 설득력 있는 댓글을 '답변 채택' 하고 게시글을 닫으면 그 시점의 베댓 글쓴이와 답변 채택된 글쓴이의 점수가 올라가고, 그 점수를 토대로 '베댓왕' (이름 미정)의 영예를 주는 기능이다. 단 하나의 아이디어가 추가될 뿐이라고 생각했는데 생각보다 스텝이 많아서 작성하고 나서 놀랐다. 지금 백은 그렇다 치고 프론트가 작업이 많이 밀려 있는 느낌인데 다 구현하려면 빨리 프엔으로 넘어가서 거들어야 할 것 같다.

Tomorrow I will

• auth, user, main 컨트롤러 db 테스팅
• 가능하면 프론트엔드 작업 시작