OData vs GraphQL

Есть ли хорошее сравнение GraphQL & OData с точки зрения производительности, удобства использования разработчиков, сообщества и т.д. Все статьи, которые я нахожу в Интернете, очень предвзяты.

Какой был бы лучший способ вернуть большие объемные JSON или двоичные данные?

Ответы

Ответ 1

Я исследовал, а также попытался использовать GraphQL в Dot Net и Odata в DotNet Web API, чтобы создать рабочую демо-версию.

  1. Удобство использования для разработчиков Учитывая, что у вас уже есть WebAPI (DotNet Framework) и вы хотите перейти на WebQL-интерфейс, совместимый с GraphQL или OData, тогда я отвечаю на вопрос о выборе OData из-за его легкой интеграции и функции "Готовые фильтры", OrderBy, Select, Expand и т.д. (См. MSFT на DotNet OData). Если вы выберете GraphQL, вам придется проделать большую работу, такую как "Создать тип", "Схема и запрос" и "Реализовать реализацию" для каждого запроса.
  2. Производительность зависит от вашей логики запроса. GraphQL и Odata Оба имеют возможность получать то, что вы запрашиваете, используя $ select в OData, а в GraphQL вы можете запрашивать их по соглашению запросов.
  3. Разработка API с нуля, если вам нужна только одна конечная точка для всех запросов API и вы не хотите поддерживать конечную точку управления версиями, имя поля Autosuggest и тип схемы, тогда GraphQL - лучший вариант. Но доступность библиотеки GraphQL для каждого фреймворка и сообщества зависит от стека технологий (например, nodejs, С#, Ruby, Java и т.д.)

Да, я просмотрел и прочитал статью Telerik, в которой подробно описал. Сравнительный PDF Для GraphQL и Odata. Я прилагаю изображение сравнения только рядом, вы можете найти подробности в Ссылочная ссылка GraphQL против OData.

Стандартный API

Standard API

Здесь, нет в API Управление версиями/поддержка положительно означает единую конечную точку и избавиться от двух версий API

Возможность запроса

Query Capability

Возможность поверхности

Surface Capability

В основном сервис OData используется, когда вы хотите предоставить доступ к вашей базе данных с минимальными усилиями для работы CRUD.

Однако, если вы знаете об API REST Sharepoint и API REST Office 365, он основан на OData и предоставляет широкий спектр API. Сейчас Microsoft создает универсальный API, который называется Graph API или Microsoft Graph, который по умолчанию включен для запроса CORS и унифицированных конечных точек для запроса из Office 365, динамика 365, Outlook Exchange API, Onedrive API и т.д., Которые также поддерживают OData.

Ответ 2

Также не очень хорошая идея использовать метод POST для запроса данных. И, очевидно, объем данных, необходимых для запроса к серверу, намного больше. По примерам из статьи Сумит Саркар:

Example for OData

Example for GraphQL

Количество данных, переданных для выполнения запроса, в GraphQL намного больше, чем в OData. Хотя результат (ответ) тот же.