게시글 정보와 게시글 조회수 동시에 필요한 API 조회 질문

스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - 게시판

조회수 구현

해결된 질문

작성

현재처럼 서비스 구조가 거의 테이블 단위로 DB와 API 서비스가 분리될 때,
이런 구조에서 화면에서 리스트 형태로 두 도메인 데이터를 함께 조회해야 하는 경우가 있을 것 같습니다.

예를 들자면 게시글과 게시글 조회 수를 함께 보여주는 리스트 API가 필요한 상황에서,

단건 조회라면 프론트에서 별도로 API를 호출해도 괜찮을 것 같은데,
페이징 처리나 리스트 형태로 여러 데이터를 묶어서 조회해야 할 때,
실무에서는 보통

한 서비스에서 다른 서비스를 RestClient(Feign 등) 로 호출해서 데이터를 합치는 방식으로 처리하는지,
- 아니면, 같은 도메인 서비스로 묶어버린다던지
아니면 프론트엔드에서 각각의 API를 호출한 뒤 병합하는 방식으로 처리하는지

궁금합니다.
실제 현업에서는 이런 경우 어떤 접근 방식을 주로 사용하나요?

java mysql spring-boot kafka redis

답변 2

쿠케

지식공유자

leebs0521님, 안녕하세요!

결론부터 말씀드리면, 두 방식(+부가적인 방식들도) 모두 사용합니다.

프론트엔드에서 각 API를 별도로 호출한다고 하더라도, 크게 문제되지 않을 수도 있겠습니다.

하지만 API를 개별적으로 클라이언트에서 호출 및 조합한다면, 각 API별 실패에 대해서 정책 정리가 필요할 수도 있고, 여러번 서버 네트워크에 호출해야 하므로 전체적으로 화면을 그려내는 비용이 증가할 수 있습니다.

또, API 팀과 프론트엔드 팀이 별도로 분리되어 있으면, 사실 API 팀의 입장만 고려할 수도 없습니다. 결국 분리된 API를 조합하려면 클라이언트의 개발 복잡도는 분명 올라가게 되고, 부가적인 소통이 필요할 수도 있습니다.

다른 문제로는, 클라이언트가 웹 프론트엔드뿐만 아니라 앱(and/ios), 다른 연동 서버 등 다양할 수도 있다는 것인데요.

이러한 경우에 클라이언트는 각자의 구현 방식이 모두 다를 수 있고 일관되지 않는다면, 문제 시에 원인 추적이 더욱 어려워질 수도 있습니다.

물론, 항상 클라이언트를 위한 API를 제공해주는 것도 어렵긴 합니다.

클라이언트의 요구사항을 위한 모델과 API에서 바라보고 있는 도메인은 절대 일치가 될 수 없기도 하고,

클라이언트 요구사항을 항상 인지하고 대응해 주는 것도 쉽지 않기 때문입니다.

이 경우에는 클라이언트에서 각각 호출한 뒤 병합하는 방식으로 처리하게 되네요.

적어도, API에서 클라이언트 요구사항을 어렵지 않게 맞춰줄 수 있는 상황이라면,

또는, 클라이언트 복잡도가 너무 커진다면(예를 들어, 게시글 영역 하나 그리는데, 게시글/조회수/좋아요수 일일이 별도로 호출하는 것도 복잡하고 이상합니다)

API에서 클라이언트 요구사항 맞춰서 제공할 수도 있는 것 같네요.

BFF를 구성하거나 서버에서 데이터 조합하는 레이어를 둘 수도 있는 것이고요.

말씀하신대로 같은 도메인으로 묶어낼 수도 있습니다.(클라이언트 요구사항과 무관하게 묶어도 괜찮은 도메인이라면)

팀의 규모나 사정, 구성원들이 익숙한 개발 방식은 모두 다를 수 있다보니, 꼭 정답이 있기보단 서로 조율하는 과정은 필요한 것 같습니다!

인프런 AI 인턴

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

질문해주신 내용은 분리된 서비스에서 데이터 통합을 어떻게 할 것인지에 대한 고민인 것 같습니다. 여러 데이터 소스를 하나의 API로 제공해야 하는 경우에는 여러 가지 방법이 있습니다. 이 중에서 일반적으로 실무에서 많이 사용하는 접근 방법을 소개드리겠습니다.

실무에서의 접근 방식

백엔드 서비스에서 데이터 병합:
- RestClient(Feign 등) 사용: 한 서비스가 다른 서비스를 호출하여 필요한 데이터를 병합합니다. 이 방식은 서비스 간 결합도가 높아질 수 있지만, 서버 측에서 데이터 병합이 이루어져 클라이언트 단의 로직이 간단해집니다.
- BFF(Backend for Frontend) 패턴: 클라이언트에 제공되는 모든 데이터를 모으는 별도의 백엔드 서비스 계층을 구성합니다. BFF는 클라이언트 요구에 맞춰 여러 서비스를 호출하고 데이터를 통합해 클라이언트에 제공합니다.
프론트엔드에서 데이터 병합:
- 클라이언트 통합: 클라이언트(프론트엔드)에서 여러 API를 개별적으로 호출한 후 그 결과를 통합합니다. 이 방법은 클라이언트 로직이 복잡해질 수 있지만 서버 측의 부담을 덜 수 있다는 장점이 있습니다.
- 프론트엔드 프레임워크가 발전하면서 비동기 처리와 상태 관리가 용이해져 이러한 방식을 잘 활용할 수 있습니다.
데이터레이어에서의 통합:
- 데이터 레이크/추상화 계층: 데이터를 함께 쿼리할 수 있는 별도의 데이터레이어나 추상화 계층을 두는 방법입니다. 여러 데이터 소스에서 직접 데이터를 조회하고 병합하는 방법으로, 성능 최적화가 가능합니다.

참고 사항

데이터 일관성: 데이터 통합 시 실시간 데이터를 요구하는 경우와 그렇지 않은 경우를 구분하여 최적화 전략을 세울 수 있습니다.
시스템 복잡도: 위의 방식 중 선택할 때 시스템의 복잡도를 고려해야 합니다. 각 방안의 트레이드오프를 잘 분석해 결정하는 것이 중요합니다.

해당 주제와 관련하여 유사한 질문 및 답변은 아래 링크를 참고하시면 좋습니다:
- 멀티 모듈 구조에서의 API 호출 및 데이터 일관성 관리 (게시글 제목)

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

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