[Комуникация] OData – OData срещу GraphQL

GraphQL е много популярен, много мощен, но е фундаментално различен от OData. Така че не е така, че едното е абсолютно по-добро от другото.

GraphQL не е OData:Входът към хиперлинк е видим.

Дискусия в Twitter:Входът към хиперлинк е видим.

Има няколко точки, които мога да получа.

OData беше начин за сериализиране на SQL оператор в URL адрес

Трудно е да се ограничи възможността за заявки от страна на клиента.

Спецификацията на OData е нейната сила, точно както RPC прави с RESTful. RESTful има спецификации и е лесен за разбиране, но не е лесно да се изрази всичко. RPC може да изрази всичко, но е твърде нестандартизирано.

OData обикновено е по-стегнат от състоянието на схемата на базата данни (като SQL Query), и след като схемата се промени, е по-трудно да се поддържа старата версия.

OData предпочита унифицирано управление и е трудно да се оптимизира за специални случаи.

OData е като SQL Query, GraphQL е като съхранена процедура. Вкусваш бавно.

Затова тези две трябва да съжителстват и да се допълват.

OData е като SQL Query, GraphQL е като съхранена процедура.

OData е като RESTful, а GraphQL е като RPC

Когато искаш проста унификация, ще откриеш, че RESTul е страхотен, SQL Query е достатъчен, OData е добър.

Но когато имате специални ситуации и не можете да използвате прост метод, RPC, запазена процедура, GraphQL подчертава своя чар.

Нека разгледаме сценариите на употреба и от двете страни. OData е склонен да бъде API за корпоративни приложения, като SAP. Обикновено по-простият, релационен модел на база данни.

GraphQL е интернет приложение, изложен API и какъвто и да е вид данни (като NoSQL)

В обобщение, GraphQL може да изразява повече (по-свободно) от OData, OData има правила (повече ограничения) от GraphQL

Кое е това, или GraphQL за външния свят, или OData за вътрешния – наистина зависи от проекта, който ще използва.

Оригинален:Входът към хиперлинк е видим.