동료 개발자랑 의견 충돌이 있어서 글 남겨봅니다.

Question

백엔드 개발자로 일하고 있습니다. 동료 개발자랑 의견 충돌이 있어서 글 남겨봅니다.상황 게시글 리스트를 채널과 프로필, 메인 페이지에서 보여줘야 하는데 API 하나를 공통으로 사용하고 있습니다.그래서 어떤 필드는 채널 페이지에서만 사용하고, 어떤 필드는 프로필 페이지에서만 사용합니다.문제프론트엔드 개발자 입장에서는 해당 페이지를 위해 필요 없는 필드를 보고 헷갈려 할 수 있다고 생각합니다.동료 개발자는 생산성을 위해서 하나의 API에 분기를 나누는게 더 좋고, 프론트엔드 개발자가 헷갈려 하는 부분은 명확한 API 명세를 통해서 해결 가능하다고 말합니다.제 생각은 분기는 백엔드 내에서 나누고 API는 페이지 별로 나누는게 더 좋다는 생각입니다.생산성을 따져도 프론트엔드 개발자와의 불필요한 커뮤니케이션을 애초에 줄일 수 있고 나중에 유지보수 측면에서도 좋다고 생각합니다.다른 분들 의견은 어떠신지 궁금합니다.

개못남 · Answer

BFF 서버에서 각 화면에 맞게 응답을 내려주는게 명확 할 것 같아요.

HJOW · Answer

이것도 사람들에 따라서 많이 갈릴 거 같은데요제 생각에는일단 이 상황이 벌어진 것 자체가두 페이지에서 동일 API 를 공통으로 사용 --> 두 페이지의 업무가 상당 부분 유사하다 (단, 동일한 건 아니다)이거 때문 아니겠어요?node.js 라서 표현이 좀 이상할 거긴 합니다만일단 API 자체는 둘로 나누되공통부분은 함수로 분리해서, 두 API가 그 함수를 호출하도록 하는 것이 이상적일 것 같구요물론 말이야 쉽지 실제로 적용할 땐 다른 문제가 발견될 수도 있습니다.

냉돈 · Answer

명확하긴 할거같은데 앱 사이즈가 커졌을땐비슷한 api가 있는등여러통로로 유사한 데이터가 복잡하게 정리될거같은.. 그런 느낌도 듭니다.저는 사수가 없어서 뭐가 맞는진 모르겠네요

동도인 · Answer

백엔드 입장에서 둘이 비슷한 코드 혹은 별 차이가 없다면 api 갯수를 늘리는 것 보다는 특정 필드로 분기를 치는게 편합니다.다음과 같이요{"gubun" : 1 ,}다만 Request 요청 혹은 Response 에서 둘의 차이가 명확하다면 저라면 분기 보다는 API 를 분리하는게 저는 맞다고 생각합니다.둘이 1:1 로 개발하는 상황이면 둘만의 대화로 처리가 가능하겠지만 여러명의 개발자와 함께 하는 상황이면 "모호" 한 개념 보다는 명확한 개념이 좋습니다.추가 : 그럼에도 분기치고 싶다! API 명세를 확실하게 문서화 해서 전달해주세요

장독깨기 · Answer

같은 게시글을 보여주는데, 보여주는 위치에 따라 항목이 다르다는 얘긴가요?그럼, API 를 나눌게 아니라, 클라이언트에서 보여주는 항목을 조절하는게 낫겠구요,아니면, 게시글 자체가 다르고, 보여주는 내용도 아예 다르다면,API 를 구분하는 것이 낫겠습니다.

seoyhaein · Answer

안녕하세요.여기서는 글을 쓰신 분께서 API 라고 했으니, API 라고 하겠습니다.API 가 가지는 목적에 따라 분명하게 나눠야 하는게 일단 표준적인 접근입니다. 세부적으로는 (목적=기능) 하나의 기능은 하나 API 로 나누어 놓아야, 향후 단위 테스트 나 통합 테스트에 번잡함이 없어지고 또한 오류 테스트나, 향후 다른 사람이 해당 코드를 볼때 혼선을 줄일 수 있습니다.만약, boilerplate 가 많이 있다고 하더라도, 이러한 부분들 또한 먼저는 기능별로 분리하는게 좋습니다. 향후, 이러한 부분들은 추가적으로 boilerplate 를 통합하거나 줄일 수 있는 패턴들을 쓰면 되는 것입니다.차라리 이러한 중복적인 코드가(차선책) 오히려 통합했을때의 단점보다 상대적으로 더 효율적일 수 있습니다.

감독님테스트가하고싶어요 · Answer

해당 API의 수명이 향후 몇년정도로 길고 변경이 거의 없으며, 분기가 더 늘어날거같지 않다면 공통으로 1개로 처리해도 무방합니다.그러나 개인적으로는 이미 분기가 3개로 갈려있고, 더 늘어나기 쉬우며, 변경이 비교적 자주 일어날 게시글이라는 도메인 특성을 고려해볼때, API를 별도로 구분짓는게 좋겠네요.

webmajm · Answer

각 페이지에서 사용하는 필드를 조회하는데 들어가는 비용(쿼리 성능)이 동일하다 = 동일 쿼리 사용response 트래픽에도 의미있는 차이가 없다 = 분기 안함성능이나 비용적인 부분도 같이 고려하면 좋겠네요~

dong bang · Answer

도메인은 같고 (백앤드에서 말하는)서비스가 다르기 때문에 (프론트에서 말하는)아래 그림처럼 처리 하는게 맞고프론트 개발자 말이 맞습니다.여담으로 클라이언트에서 호출 할수 있는 최대 api 갯수 제한이 있습니다.(동시에) 최대한 보수적으로 api 호출 해야 합니다.

개발잡부 · Answer

Controller와 Response는 페이지별로 나누되, 그 과정에서 사용해야하는 Service로직이 쿼리문은 하나로 통일하는게 백도 편하고 프론트도 편한방법아닐까 합니다

호두까면주름생김 · Answer

공통화 할 수 있으면 공통화하는게 좋음. 기준 없이 API 개수를 늘리면 앞으로의 확장 방향도 API 개수를 늘리는 형태로 갈거고, 유지보수 한계에 부딪힘. 지금이야 API 가 3개~4개니까 햇갈림 방지용으로 개수를 늘리는 형태겠지만, 메인 페이지에 호출해야 할 API 가 40개고, 다른 페이지들에 필요한 추가 API 개발 건수가 한달에 2건씩만 있어도 수정되어야할 지 모르는 API 개수가, 늘려놓은 만큼 발생함. 굳이 겪어보고 싶으면 개수를 늘려보셈. 이게 유지보수 이슈가 얼마나 큰지 이해를 잘 못하는 사람들이 꽤 있음. 경험해봐야함.

genonfire · Answer

개발은 항상 사용하는 쪽에서 편하고 효율적으로 하는 게 맞습니다.즉 개발하는 사람이 힘들고 쓰는 쪽이 편하게, 개발자 한 명이 좀 더 고생하면 쓰는 모두가 편해지는게 진리죠.API 를 쓰는 건 프론트엔드 개발자이므로 프론트엔드가 편하게 맞춰줘야죠. 게다가 쓸데 없는 필드들 다이어트 하면 트랜잭션 사이즈도 주는 장점이 있죠.또한 귀찮은 일을 편하게 만드는 것도 개발자의 스킬이죠. 비슷한 API 인데 필드만 다르다? 시리얼라이저 상속해서 field 만 바꿔준 후 랜딩 포인트만 추가해 주면 되는 간단한 일인데요.

세브라이드 · Answer

미리 API 다 쪼개놓으면 BFF 만들땐 편하겠네요.

apidevelop222 · Answer

착하시네요 백앤드가 백앤드 효율을 생각해야지 프론트가 헷갈린다고 본인팀 개발 효율성을 포기하다니.. ㅋㅋㅋ그리고 api을 화면에 맞춰서 일일이 전부 제공하면 끝이 없을텐데, 모든 필드 주고 거기서 너희가 사용할 필드 사용해 가 맞지 않을까요? 그러다 컬럼하나 추가될때마다 수정해주실껀가요??

동료 개발자랑 의견 충돌이 있어서 글 남겨봅니다.

14개의 답변

#api 목록