신규 API를 작업하거나 기존 API를 변경하려면 백엔드는 물론이고 프론트도 개발되어야하고 수많은 데이터 중 하나라도 이름이 바뀌면 이를 사용하고 있던 화면에서는 전부 수정 작업을 해줘야한다. 이러한 작업들을 조금 더 효율적으로 하고자 GraphQL을 도입하면 어떨까 생각을 해보았다.

만약에

사용자 정보 { name, email }을 조회하는 GET /user API를 프로필 화면에서 호출하고 있다. 그러다 이벤트 참여를 위해 사용자 정보에 연락처만 필요로 하는 화면이 개발되었고 이를 위해 기존 API를 수정하는 방법과 신규 API를 개발하는 방법을 고민중이다. 기존 GET /user API를 수정하여 { name, email, phone }가 조회되도록 하거나 { phone }를 응답하는 GET /user/phone이라는 신규 API를 개발하면 된다. 기존 API에 추가 작업을 한 경우, phone이라는 값을 전혀 사용하지 않는 프로필 화면에서도 해당 데이터를 내려받아야만 하는 데이터 낭비가 발생하고 신규 API를 추가하는 경우에는 데이터 하나 변경 될 때 마다 새로운 API를 다시 개발해야한다.

GraphQL을 사용한다면?

사용자 정보를 조회하는 API GET /user에 대응되는 getUser라는 resolver에서 { name, email }을 반환하고 있다. 프로필 화면에서는 이름과 이메일 정보 둘 다 필요하므로 { name, email }을 가져온다. 그리고 새로 개발된 이벤트 화면에서 연락처를 사용하려고 하면 서버에서는 getUser 데이터에 phone을 추가해주면 되고 프론트에서 { phone }만 가져와 사용하면 된다. GraphQL을 사용하면 API를 여러개 만들지 않더라도 화면마다 필요한 데이터를 필요한 만큼만 조회해서 사용할 수 있게 된다. 이번 화면에서 사용하지 않는 전체 데이터를 가져오느라 낭비되는 것들이 줄어들 것이다.

내가 생각하는 가장 큰 장점

프로젝트를 진행하다보면 API가 먼저 개발되고 화면을 개발하는 것보다는 동시에 작업하는 경우가 많다. 그럼 프론트에서는 API에서 이러한 데이터가 이런식으로 조회되겠지 하는 가정을 하고 목업 데이터를 만들고 그에 맞춰서 화면을 그린다. 그리고 API가 개발 완료되어 전달받았을때 목업 데이터와 실제 데이터의 생김새는 슬프게도 너무 다르고(많은 소통으로 커버할 수 있겠으나 다르다) API 데이터를 화면에 맞게 변환하는 작업이 한번 더 필요하게 된다. 만약 GraphQL을 사용한다면 화면에 구성한 목업 데이터 형식과 똑같은 API를 구성할 수 있을 것이라 생각된다.

완전한 대체가 가능할까

데이터가 간단하게 조회하고 생성하는 것이라면 GraphQL을 사용하는 것은 괜찮다고 생각된다. 그러나 만약 운영하고 있는 서비스의 데이터들이 서로를 서로가 감싸고 바라보고 사슬로 연결되어 있는 듯 Join되어있다면 과연 GraphQL을 사용하는게 좋은 생각일까? GraphQL에서는 Join이 없다. 대신 Resolver로 서브쿼리처럼 서브 API를 쿼리 내 작성하여 마치 Join인듯 데이터를 가져올 수 있다. 사용자 정보를 가져왔고 사용자마다 이벤트 참여 기록을 불러오고 싶다면 { name, event: { record } }와 같은 형태로 사용자의 이벤트 기록을 묶어줄 수 있을 것이다. 이때 사용자 name 별로 record를 조회해오는 resolver를 만들고 사용자를 가져오는 resolver에 서브 형태로 추가해주면 된다. 이런 형태로 REST API를 완전하게 대체할 수 있을까? 아직은 물음표이다. 관계형으로 구성되는 데이터가 거대한 서비스의 경우 REST API로 개발하는게 운영하는데 효율적이라 여겨진다.

아직은 완전하게 대체할 수 없다고 생각하는 GraphQL이지만 거대한 관계 데이터가 분리되기 시작한다면 REST API를 대체할 수 있지 않을까? 유저, 이벤트 데이터를 각각 호출하여 가져오면서 데이터가 서버 의존에서 벗어나 프론트에서도 관리할 수 있게 된다면...

참고

웹 앱 API 개발을 위한 GraphQL