API의 설계 수법으로서 오랫동안 업계의 표준이었던 「REST API」. 그러나 최근 프론트엔드의 고도화에 따라 「GraphQL」을 채용하는 기업이 늘고 있습니다. 기술적인 이야기에 들어가기 전에, 우선은 양자의 차이를 「레스토랑의 주문」에 비유해 생각해 봅시다.
레스토랑의 REST API 한계
REST API는 말하자면 “메뉴마다 창구가 다른 푸드 코트"입니다.
예를 들어, 햄버거 세트를 요청하고 싶습니다. 먼저 햄버거 창구(/api/burgers/1)로 가서 감자 창구(/api/sides/potato)로 가서 마지막으로 음료 창구(/api/drinks/coke)로 가야 합니다.
이것은 여러 번 창구를 오가는 수고 (여러 번의 요청)가 걸립니다. 게다가, 「햄버거의 피클은 빼고 싶다」라고 생각해도, 창구에서는 반드시 피클스들이의 완성품이 건네져 버립니다. 이것은 불필요한 데이터까지 얻어 버리는 “오버 페치"라는 문제입니다.
GraphQL이라는 궁극의 맞춤형
대비 GraphQL은 “매우 유능한 전속 웨이터"입니다. 당신은 웨이터에게 “햄버거 (피클 빼기), 감자 S 사이즈, 콜라"라고 쓴 주문서 (쿼리)를 한 번만 전달합니다. 그러면 웨이터는 주방으로 돌고, 당신이 지정한 대로의 것을, 하나의 트레이에 정리해 가져옵니다.
이것이 GraphQL의 가장 큰 특징입니다. 프런트 엔드 (고객) 측에서 “어떤 데이터가 어떤 형태로 원하는지"를 핀 포인트로 지정할 수 있으며 백엔드는 그에 따라 과부족없이 데이터를 반환합니다.
GraphQL의 장점과 도입 벽
이 구조는 다음과 같은 이점을 제공합니다.
- 통신량 감소: 스마트폰과 같은 모바일 환경에서 불필요한 데이터를 얻지 못하면 성능이 크게 향상됩니다.
- 유연한 UI 변경: 화면에 새로운 표시 항목을 늘리고 싶은 경우에도 REST와 같이 새로운 엔드포인트를 백엔드 측에 만들 필요가 없고, 프런트의 쿼리를 재작성하는 것만으로 완결합니다.
한편, 마법의 지팡이가 아닙니다. 「캐시의 제어가 어렵다」 「N+1 문제가 일어나기 쉽다」 「백엔드의 실장 난이도가 오른다」라고 하는 과제도 존재합니다. 단순한 블로그 사이트 등이라면, 종래대로 REST API가 쉽고 적당한 경우도 많습니다.
어느 것을 선택해야합니까?
한 화면에서 다양한 유형의 리소스(사용자 정보, 게시물, 댓글, 좋아요 번호 등)를 복합적으로 표시하는 복잡한 웹 응용 프로그램을 개발한다면 GraphQL은 최고의 옵션이 될 수 있습니다. 자사의 ‘레스토랑’이 어떤 주문을 많이 받는지 알아보고 적절한 아키텍처를 선택하십시오.