소비자 중심의 API (feat. GraphQL)

yeTi 2023. 2. 21. 16:49

안녕하세요. yeTi입니다.

오늘은 유영모님이 기고하신 GraphQL 그리고 MSA를 읽고
RestAPI를 설계하면서 옳바른 방향이 무엇인가에 대한 자의적인 해석에 대해 공유하고자 합니다.

현실

RestAPI의 specification 을 정의할때면 항상 드는 고민이 있었습니다.

서버 개발자의 편의 위주로 설계할 것인가? (공급자 위주)
프론트 개발자의 편의 위주로 설계할 것인가? (소비자 위주)

서버 개발자의 편의 위주로 설계를 하게 되면 사용성에 대한 고민이 없어지니 서버 개발자의 편의내에서 서비스 도메인을 구분하고 간결한 정보의 제공으로 정의하여 공표하면 되니 설계를 간결하고 빠르게 진행할 수 있게 됩니다.

반면에 프론트 개발자의 편의 위주로 설계를 하게 되면 도메인의 경계보다는 다양한 화면에 맞춰 특화된 API를 설계해야하기 때문에 동일한 도메인 정보라도 다수의 API를 만들어서 제공해야합니다.

그렇기 때문에 API 개발량의 증가와 화면에 노출하는 정보 변경시 그에 맞춰 API도 변경해야하는 이슈가 생길 여지가 있고, 만일. API를 화면에 특화하지 않고 보편적인 API의 컨셉을 가져간다면 API의 크기가 커져 네트워크 비효율을 야기할 수 있습니다.

설계적 관점에서 가장 임팩트를 느낀 문장입니다.

API 명세는 쓰임새가 주도한다.

개발자의 궁극의 목표와도 일치한다고 생각한 부분이 사용자에게 유용한 서비스, 사용자가 찾게 되는 서비스를 만들어내는 부분과도 일치한다고 느꼈습니다.

개발자라면 자신이 만들어내는 무의미한 코드의 생성이 아니라 진정 가치있는 무언가의 생산이 중요하다라고 생각을 하고 있고 서버 개발자라면 사용자가 원하는 API를 제공하는 것이 중요한 가치이다라는 생각이 들었습니다.

그러면서 글에서 언급한 UnderFeching, OverFetching 이슈도 자연스럽게 해소됩니다.

UnderFeching 이슈는 사용자가 원하는 데이터를 조합할 수 있도록 제공함으로써 해결할 수 있고, OverFetching 이슈는 사용자가 원하는 필드값을 선택할 수 있도록 제공함으로써 해결할 수 있습니다.

그리고 이를 해결할 수 있는 해결책으로 GraphQL을 제시하고 있습니다.

GraphQL 을 해석할 수 있는 레이어가 필요하기 때문에 서비스 관리 측면에서 리소스가 추가되는 부분이 있습니다.

하지만 이를 클라이언트의 자유로운 데이터 접근의 측면에서의 이득이 있기 때문에 trade-off 를 잘 고민해볼 필요가 있다고 생각합니다.

기존 RestAPI를 사용하면 Restdocs와 같이 명세서 형태의 문서가 필요했지만 GraphQL에서는 편집기를 활용해서 원하는 데이터를 가져올 수 있는 쿼리를 생성해 보는게 중요하게 보입니다.

본 글을 작성하고자 마음먹은 이유는 API 명세는 쓰임새가 주도한다 를 스스로 각인하고 싶은 마음이었습니다.

앞서 언급한 바와 같이 제품이나 서비스의 가치는 사용자로부터 나오기 때문에 사용자의 관점에서 편리하고 유용하게 사용할 수 있는 고민이 가치있게 느껴졌고,

그 동안 서버의 개발 편의성을 우선하여 설계를 해오던 관성을 깰 수 있는 계기가 되었다고 생각합니다.

가치를 인지하고 있으면 실천방안은 다양하게 응용 가능하고 적용 가능하기 때문에 API Composition Pattern, BFF, GraphQL의 의도를 이해하고 실무에서 가장 효율적인 방안을 선택하는게 합리적이라는 생각입니다.

관련 소스코드는 Springboot for GraphQL에서 확인하실 수 있습니다.