인프런 커뮤니티 질문&답변

qheogus55님, 안녕하세요!

아래 AI가 잘 답해주었는데 추가 답변 드립니다!

말씀하신대로 프론트에서 두 개의 api를 각각 호출할 수도 있고,
서버에서 두 개의 api를 조합하는 엔드포인트를 만들어서 프론트는 해당 api만 호출할 수도 있습니다.
또는, 게시글 서비스의 게시글 조회 api 내에서 조회수를 처리하도록 구성하면, 게시글 조회 api만 호출할 수도 있습니다.

현재 구성처럼 게시글 서비스와 게시글 조회수 서비스가 분리되어 있는 상황이 의아하실 수 있는데요, 실무에서 반드시 분리하는 것은 아니고 상황에 따라 달라질 수 있습니다.

예시로, 게시글 조회수 처리가 게시판 서비스 팀과 별도 팀으로 구성된 통계 팀의 책임이라고 볼 수도 있는데요.
이 경우 각 팀이 분리하여 관리하는게 유리할 수도 있습니다.
같은 팀 내의 책임이더라도, 개별 서비스가 처리해야하는 사항이 복잡하다면 유지보수 또는 개발 편의를 위해 분리할 수도 있습니다.

그래서,
- 게시글 서비스 내에서 조회수 처리
- 게시글 서비스와 조회수 서비스를 분리하여 처리(현재 구성)
- 게시글 서비스에서 조회 이벤트를 발행 후, 조회수 서비스에서 처리
등 다양한 구성이 가능하다고 봐주시면 되고, 강의에 나온 구성은 하나의 예시일 수 있습니다.

혹시 더 궁금한 점 있으시면 편히 문의 주세요!

안녕하세요, 인프런 AI 인턴입니다. qheogus55님.

멀티 모듈 방식에서는 각 기능이 별도의 모듈로 나뉘어 있어 구조가 복잡해 보일 수 있는데, 이는 시스템의 확장성과 유지보수를 용이하게 하기 위한 것입니다. 질문하신 내용에 대해 설명드리겠습니다.

멀티 모듈에서의 API 구성

1. 게시글 조회 API와 조회수 증가 API가 분리된 이유는 관심사의 분리를 통해 각 기능의 책임을 명확히 하고, 모듈 간의 결합도를 낮추려는 목적이 있습니다.

2. 실무에서의 API 분리:

   • 실무에서는 API를 잘게 나누어 각각의 API가 하나의 책임만 가지게 설계하는 경우도 많습니다. 이렇게 하면 각 API의 변경이 다른 부분에 미치는 영향을 최소화할 수 있습니다.
     
   • 하지만 프론트엔드 요청을 줄이고 성능을 최적화하기 위해 조회 API에서 조회수 증가를 함께 처리하도록 설계할 수도 있습니다. 이 방식은 시스템의 요구 사항과 트래픽의 특성에 따라 결정됩니다.
     

3. 프론트엔드 관점에서:

   • 프론트엔드에서는 게시글 조회 시 두 개의 API를 연속적으로 호출하거나, 백엔드에서 게시글 조회 API에서 조회수 증가를 함께 처리하도록 요청할 수 있습니다. 이는 구현 전략에 따라 다를 수 있습니다.
     

참고 자료 및 추가 사항

• 실무에서는 Redis와 같은 캐시 저장소를 이용해 빠른 조회와 데이터 동기화를 활용하여 성능을 최적화할 수 있습니다. 이러한 설계 패턴은 요구 사항에 따라 다르게 적용될 수 있습니다.
  
• 멀티 모듈 구조의 이점과 고려사항 (게시글 제목)이라는 게시글도 도움이 될 수 있습니다.
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.