GraphQL은 매우 인기가 있고 강력하지만, 근본적으로 OData와는 다릅니다. 그래서 어느 쪽이 절대적으로 더 낫다는 뜻은 아닙니다.
몇 가지 말씀드릴 수 있는 점이 있습니다.
OData = URL 내 SQL
OData는 SQL 문장을 URL로 직렬화하는 방법이었습니다
클라이언트 측의 쿼리 기능을 제한하기는 어렵습니다.
OData 표준화
OData의 사양은 RPC가 RESTful에 하는 강점과 같습니다. RESTful은 명세가 있고 이해하기 쉽지만, 모든 것을 표현하기는 쉽지 않습니다. RPC는 모든 것을 표현할 수 있지만, 너무 비표준적입니다.
OData의 결함
OData는 보통 데이터베이스 스키마 상태보다 더 엄격해서 SQL 쿼리와 비슷하고, 스키마가 변경되면 이전 버전을 유지하기가 더 어려워집니다.
OData는 통합 관리(unified management)를 선호하며, 특수한 경우에 최적화하기가 어렵습니다.
가장 잘 설명된 것
OData는 SQL Query와 비슷하고, GraphQL은 저장 프로시저와 같습니다. 천천히 맛을 느껴.
따라서 이 두 가지는 공존하며 서로를 보완해야 합니다.
요약
OData는 SQL Query와 비슷하고, GraphQL은 저장 프로시저와 같습니다.
OData는 RESTful과 비슷하고, GraphQL은 RPC와 비슷합니다
간단한 통합을 원할 때는 RESTFul이 훌륭하고, SQL 쿼리도 충분하며, OData도 좋습니다.
하지만 특별한 상황에서 간단한 방법, RPC, 저장 프로시저를 사용할 수 없을 때, GraphQL은 그 매력을 잘 보여줍니다.
양측의 사용 시나리오를 살펴보겠습니다. OData는 SAP와 같은 엔터프라이즈 애플리케이션을 위한 API로 기능하는 경향이 있습니다. 보통은 더 단순한 관계형 데이터베이스 패턴입니다.
GraphQL은 인터넷 애플리케이션이자 노출된 API, 그리고 NoSQL과 같은 어떤 유형의 데이터입니다
요약하자면, GraphQL은 OData보다 더 많고(더 자유로운) 표현이 가능하며, OData는 GraphQL보다 규칙(더 많은 제약 조건)을 가지고 있습니다
외부 세계를 위해 GraphQL을 사용할지, 내부에서는 OData를 선택해야 할지, 프로젝트에 따라 다릅니다.