강의를 듣고 개인 프로젝트를 하다가 궁금한게 생겨서 질문드립니다.

좋은 질문이네요 :)

>저는 FE에서 데이터를 가공해서 server로 딱 필요한 요청과 데이터만 보내는게 맞다고 생각을했는데 서버에서 이런것들을 쉽게 핸들링할수가 있고 이렇게 logic을 운영하는게 맞는지 궁금합니다.

API 설계는 기본적으로는 이렇게 설계를 많이 해요. 이렇게 하면 클라이언트 입장에서 "자유도"가 높아지지요. 하나의 버튼 클릭으로 하나의 리소스만 수정하도록 요청할 수도 있고 여러 요청을 동시에 날려서 한번에 많은 요청을 처리할 수도 있죠.

하지만 자유도가 높을뿐 효율면에서는 매우 안좋아요. 확인해보신대로 shopify는 여러개를 수정 & 삭제하지만 하나의 요청으로 처리가 되죠. 이게 훨씬 효율적이죠.

그래서 API 설계를 할 때 클라이언트가 어떻게 만들어질지, 즉 어떻게 요청을 보낼지 잘 알아야 합니다. Shopify에서처럼 여러개의 리소스를 동시에 수정 삭제 할 수 있다면 하나의 요청으로 처리할 수 있는 API를 개발해주는게 좋아요. 클라이언트는 한번의 요청만 날리고 추측하신대로 백엔드가 디비에 여러 요청을 날리게 되는거죠.

이 경우에는 해당 안되겠지만 상황에 따라서는 디비도 이거에 맞게 최적화시킬 수 있겠죠. 예를 들면 상품들이 하나의 스키마에 있다 그러면 디비 요청도 한번에 끝나죠. 물론 이 경우 다른 여러 이유 때문에 한번에 저장하면 안되겠지만요. 

그리고 이 강의에서 비슷한 내용을 언급했었는데요. 몽고디비 스키마를 설계할 때 무엇을 얼만큼 내장하느냐를 다뤘었는데요. 결국 클라이언트에서 어떻게 요청이 들어오느냐에 그리고 어디에 부하가 발생하느냐에 따라 스키마 설계가 달라지죠.

다만 REST API를 설계하면 사실 조금 아쉬운면이 있어요. 이걸 POST?PUT? DELETE 무엇을 해야하는가? 하나의 상품을 수정하는거니깐 products 엔드포인트가 아니지 않나? 등 애매한 부분들이 있어요.  아마 그냥 POST나, PUT으로 좀 다른 endpoint를 만들거라고 생각해요. REST 규격이 잘 안지켜지게 되죠. 이 강의에서 다룰 내용은 아니었지만 전 이런 이유 때문에도 REST 대신 GraphQL을 사용합니다. 물론 GraphQL을 해야하는 더 좋은 이유는 많지만요 ㅎㅎ

관계형 디비 -> 몽고디비

REST -> GraphQL

GraphQL 강의를 빨리 출시하고 싶은데 요즘 시간을 너무 못내고 있네요 ㅠㅠ GraphQL 잘 이해하고 쓰면 정말 좋습니다! 궁금하시면 Apollo Server 검색해보시고 실험해보셔도 좋을 것 같아요 :)