[엘리스 SW 트랙] 2차 프로젝트 : 백엔드 오피스아워 코멘트 14주차 - 2

• 북마크 추가/삭제 API를 /users/:id/bookmarks로 잡았는데, 수정이 필요할까요? 데이터 스키마에서 User가 본인이 북마크한 리스트를 가지고 있으려고 bookmark라는 key를 넣어주고 API path를 이렇게 짰습니다. 
  
  • 좀 더 RESTful 한 방식을 고려한다면, 리소스 주체를 feed로 잡는 게 좋을 것 같습니다. 서버에서 api 경로를 나눌 수 있겠죠? feed, user 등등 이렇게 나뉠텐데.. 그렇다면 bookmark를 추가한다고 했을 때, feed 쪽으로 들어가는게 좀더 유용하지 않을까 싶습니다.
  • bookmark를 추가했을 때 모든 정보를 저장하지 않고 feedId만 DB에 저장할것 같은데, 그럴거면 feed쪽 api를 타고 접근하는게 좀 더 좋아보입니다. 그리고 자원의 경로를 봤을때 좀더 명확할 것 같아 보입니다 :)
• 지금 현재로서는 user가 bookmark 정보들을 가지고 있는데.. 이걸 feed 쪽 path로 접근 하는게 맞을까요?
  • 사실 뭐로 하든 괜찮습니다. 다만 고민을 하셔야할 께, feed쪽으로 api 설계하면 이후에  북마크와 관련된 정보를 수월하게 조회할 수 있다는 것이죠.
  • User 쪽에서 bookmark 정보를 저장해도 되는데요. 이렇게 한다고 했을 때, 이후에 어떤 상황으로 인해 사용자 전용 DB가 분리되고 북마크에 대한 정보만 호출을 해야하는데...  분리가 되지 않았다면 User 쪽 API 호출을 해야하겠죠? 
  • path를 feed 하위로 설정해놓고 bookmark 스키마를 따로 빼놓는 다면 이후에 분리가 되어도 불필요하게 사용자 정보를 접근하지 않아도 되겠죠.
  • "조회 쿼리가 어떤게 많이 일어날까?"를 한번 고민해 보시고, 스키마를 따로 뺄지 아니면 이대로 갈지 고민해보시기 바랍니다 :)
• 1차 프로젝트에서는 PATCH를 수정/등록에 모두 사용한 팀원이 있고, 상황에 따라 PUT,PATCH를 사용한 팀원이 있습니다. PATCH는 일반적으로 부분수정이 일어나는 곳에 사용하는 것으로 알고 있어서, 부분 수정이 일어나는 곳은 PATCH, 전체 수정이 일어나는 곳은 PUT을 사용하려고 하는데.. 혹시 더 좋은 방법이 있을까요? 아니면 둘 중 한가지만 사용해도 무방한지 물어보고 싶습니다. 현업에서도 의미상으로 두 가지를 섞어쓰는지도 궁금합니다.
  • 현업에서는 둘 다 사용 합니다. 이게 수정 API가 어떻게 동작하느냐에 따라서 PUT을 쓸지, PATCH를 쓸지 나눌 수 있습니다.
  • 유저 정보를 수정한다고 했을때를 가정해 봅시다. 만약 닉네임 정보만 수정한다고 했을 때, 백엔드 쪽 API에서 닉네임 정보만 받을건지, 아니면 변경되지 않은 정보들까지 모두 받을 건지에 따라서 달라집니다. 수정하려고 하는 정보만 받아서 수정하는 API 일 경우엔 PATCH를 쓰고, 전체 모든 정보를 전달 받아서 수정하는 API일 경우엔 PUT을 사용합니다. 
  • 아직 API가 어떻게 동작할지 작성하지 않았기 때문에 헷갈리실 것 같은데, 아마 API 상세가 나오면 자연스럽게 정의될 것 같네요 :)
• PUT으로 수정될 전체 데이터를 보내는 동작에 대한 장/단점이 있을까요?
  • 무지성으로 데이터를 보내도 된다는 장점이 있죠. API의 복잡도가 낮아집니다.  단점이라면.., 네트워크 비용이 많이 발생한다는 것이 있을 수 있겠군요. 하지만 수정하는 API가 실제로도 그렇게 많이 발생하지 않기 때문에 흠.. 현업에서는 무시하고 그냥 전체 데이터를 보내는 경우도 종종 있습니다.
  • 수정하는 API가 삭제를 하는 로직을 짤 수 도 있고, 추가하는 로직을 짤 수도 있습니다. 어떤 API는 특정 row 값이 추가되는 경우도 있습니다. 이럴 경우엔 기존 데이터를 삭제처리하고 전달 받은 데이터를 새로 밀어 넣는 방식으로 짜면 엄청 수월합니다. 이럴 때 수정된 전체 데이터를 보내면 아주 편하겠죠.
  • 저는 API의 복잡도를 낮추는 걸 선호합니다. 어차피 실제로도 수정이 많이 일어나지 않기때문에.. PUT을 사용하는걸 선호합니다. 지금 작성하신 API로는 PATCH로 해도 유의미할 것 같네요. 만약에 별도 스키마를 빼서 이미지를 따로 저장해둔다면.. PUT을 쓸지 PATCH를 쓸지 고민해봐야 할 것 같기도 합니다.
• 모티브를 Instagram으로 잡고 데이터 목록들을 불러오려고 합니다. 확인해보니 각 데이터 목록마다 로딩되는 속도가 달라지는데, 각각의 데이터들을 따로 fetch해서 불러오는 식인지.. 아니면 다른 방법이 있는지 궁금합니다.
  • 아마 Instagram에서는 한번에 데이터들을 불러올겁니다. 다만, 각 목록들마다 로딩이 다르게 보이는건 아마 캐싱을 해둔 데이터들이 있기 때문에 그렇게 보이는 걸 겁니다. 그럼 캐싱은 어떻게 해둔걸까요? Instagram의 경우는 아마 개인화 추천 모듈이 적용되어 있을거에요. 추천 모듈이 있기 때문에 미리 캐싱해두고 보여주는거죠. 우리 프로젝트에서는 개인화 추천 모듈을 개발하는 게 목적이 아니기 때문에 여기까지 고민할 필요는 없습니다ㅎㅎ
• 회원 탈퇴 관련
  • 회원을 탈퇴하면 서비스상 삭제 되는 것 처럼 보이는데, 이건 논리적으로 삭제된 것 입니다. 보통은 soft delete를 진행합니다. 삭제 요청이 들어온 경우 schema에 deletedAt 같은 row를 추가해놓고, 바로 삭제 처리는 진행하지 않습니다. 바로 삭제가 되면 이후에 문제가 발생할 수 있기 때문에 soft delete로 변경해주세요
• 게시물 이미지를 collection으로 만든다면 효율적으로 관리할 수 있다고 말씀하셨던 것 같습니다. 궁금한 점이 게시물 이미지를 변경할 때 기존 방법대로 한다면 게시물 collection의 이미지 배열에서만 탐색, 수정하던 것을 이미지 collection으로 따로 분리한다면 수정하고자 하는 게시물의 이미지 외의 모든 이미지 collection을 순회하여 해당 이미지를 수정해야 할 것 같습니다. 단순히 순회 될 데이터의 양으로 비교한다면 게시글의 이미지 배열과 모든 이미지collection로 비교할 수 있을 텐 데, collection으로 분리하는 편이 더 많은 순회가 일어날 것 같은데 저희가 놓친부분이 무엇일까요?
  • 이미지 collection을 만들어두면 단 한번의 query 문으로 조회할 수 있습니다. 이미지 collection에 index를 미리 설정해주면 단 한번에 조회할 수 있습니다. 생성할 때 mongo DB도 코드 한줄 추가하면 알아서 index 추가를 해줍니다. 아주 손쉽죠 ㅎㅎ
• mongoDB에서 index 기능을 제공해준다면.. 왜 Redis 같은 DB를 따로 사용하나요?
  • Redis는 inMemoryDB라고 합니다. 데이터를 빠르게 저장하고 조회하도록 만들어진 keyValue DB라서 많은 양의 데이터를 저장할 수 없어요. 그리고 메모리 영역에서 동작하는 DB이기 때문에 비용이 높긴 하지만, 속도가 압도적으로 빠릅니다. 데이터를 빠르게 조회해야할 경우 사용합니다. 예를 들면 1억명의 아미가 방탄소년단 라이브 동영상에 동시에 좋아요를 눌렀다고 했을때.. 몽고DB는 터집니다. 그런데 Redis는 안터져요. 그만큼의 I/O를 처리할 수 있는 강점이 있습니다. (대신 아주아주 비싸요)
  • 그래서 Redis는 언제 쓰이냐, 빠르게 데이터를 조회하고 저장해야하는데, 저장할 데이터가 많이 없을때! 사용합니다. 좋아요, 조회수, refresh token 저장 같은 것들에 사용 되겠죠.
  • 또.. redis는 휘발성 데이터라 꺼진다면 다 날아갑니다. 그래서 redis는 날아가도 괜찮은 것들만 저장해야해요. 그래서 좋아요, 조회수 같은 것들은 처음에 redis에 저장했다가 특정 시간 되면 배치 작업으로 mongoDB 같은 곳에 데이터를 이관합니다.
• Kakao OAuth 관련
  • 카카오 oauth API를 처리할 떄 하나의 GET 요청 내부에서 또 다른 서버로 API 요청을 여러개 보내는 것은 문제가 없습니다. 만약 GET 요청이 아니라 POST 요청을 사용가능하다면 POST를 쓰는게 더 좋을 것 같네요
  • 쿠키를 사용한 로그아웃 기능을 구현할 때, 클라이언트에서 로그아웃 이벤트 시 쿠키 삭제 하는 방법과 서버에 요청해서 쿠키를 삭제 시키고 응답을 받는 방법이 있습니다. 후자의 경우는 사용자의 행동에 대한 로깅 (언제 로그인하고, 언제 로그아웃되었는지)이 필요할 때 사용하는 방법입니다.

 

 

#엘리스트랙 #엘리스트랙후기 #리액트네이티브강좌 #온라인코딩부트캠프 #온라인코딩학원 #프론트엔드학원 #개발자국비지원 #개발자부트캠프 #국비지원부트캠프 #프론트엔드국비지원 #React #Styledcomponent #React Router Dom #Redux #Typescript #Javascript