🆚 REST API vs GraphQL
둘의 차이는 무엇이고 어떤 경우에 쓰면 좋을 지 비교해보자.
🔯 GraphQL이 REST API보다 나은점
데이터를 가져옴에 있어서, 고정된 요청과 응답이 아닌 필요한 것만 골라서 가져와야 할 경우 GQL이 유리하다.
특정 데이터만 필요한데 서버에서 결정된 데이터의 집합을 반환하는 것은 너무 과하고(많은 일을 처리해야 하고 데이터가 많으면 전송도 느려질 수 있고)(Over fetching), 반대로 RDB에 관계로 엮여있는 특정 데이터가 필요한데 여러번 조회를 해야지만 해당 데이터에 접근할 수 있는 REST 대신 GQL을 사용하면 한번의 조회로 해당 데이터에 접근이 가능해 Under fetching에 대한 문제가 해결될 수 있다.
또한 단일 Endpoint를 사용해 데이터를 교환하는 GQL은 REST에 비해 네트워크 요청 수를 줄 일 수 있고 이는 곧 REST에서 Endpoint 단일화 작업 시 발행하는 많은 커스텀 미들웨어 비용을 아낄 수 있게 되는 것이다!
그리고 API에 대한 Version 관리를 별도로 할 필요가 없어지기도 하며, GQL은 Schema 자체가 문서로써 동작하고 있기에 별도의 문서화 과정이 필요가 없어 협업에 용이하다.
☁ REST API가 GraphQL보다 나은점
HTTP 기반을 이용하는 REST API는 HTTP의 특징인 캐싱을 사용할 수 있다. GQL은 독자적으로 지원하는 기술을 써야 하는데 비해 REST API는 이 캐싱을 활용하여 응답 시간이 빨라지고 REST Server의 트랜잭션이 발생하지 않기에 전체 응답시간, 성능, 서버의 자원 이용률을 향상 시킬 수 있다.
또한 GQL은 오류와 성공 모두 200 응답을 주며 이때 오류일 경우에만 Error 속성에 별도로 Data를 넣어서 제공해주는 반면 HTTP 상태 코드를 사용하여 오류 및 성공 요청&응답에 관해 직관적인 상태 코드 확인이 가능하다.
🔚 결론
두가지를 공존해서 쓰는 것이 가능하다고 하니 그것이 좋을 것 같았다.
어느 것이 좋고 나쁘고의 문제가 아니라 그저 다르게 사용하는 것이기 때문에 서버에 양쪽 다 구현해 두고, 누구에게 어떤 정보를 제공 하느냐에 따라 다르게 전달하면 되기에 어느 한쪽의 대체품으로 사용하기 보다 공존해서 사용하는 편이 각각의 이점을 살려서 데이터를 제공하는 것이 좋다.
앞으로는 이 두가지를 공존해서 어떻게 풀어서 서비스에 적용할 지를 생각 연구 해야 할 듯 싶다.
