Comments 49
Какие дыры и какой ценой убирает?
Например, решает проблему N+1 запроса
А можно, пожалуйста, детальнее: как graphQL исправляет проблему N+1 запроса?
И создаёт проблему запрета таких запросов, чтобы всю базу не вытащили разом. =)
Если в REST вы точно знаете, какие данные вернете и это легко оптимизировать, то в GraphQL для этого надо парсить запрос.Потому что делать лишние JOIN если внутренние данные не просят не очень хорошая идея.
Тем не менее я согласен, что GrapQL это как AJAX 10 лет назад. Прорывная технология, но не все к ней еще пришли и готовы.
Если в REST вы точно знаете, какие данные вернете и это легко оптимизировать, то в GraphQL для этого надо парсить запрос.
он жзе возвращает то, что вы запросили. Или о чем вы?
При REST подходе разработчики API диктуют условия клиенту, знают когда и что возвращать и легко могут оптимизировать нужные эндпоинты.
odata выигрывает у graphql по стандартизации и возможностям и делает то же самое
odata больше целится в энтерпрайз и лучше работает с реляционными БД, ORM и т.д.
graphql больше ориентирован на стартапы, поэтому больше заточен на no-sql (прежде всего Mongo) и меньше заботится о документации.
graphql вероятно более web/js/script-kiddies ориентирован
Преимущество GraphQL над ODATA черным по-белому написано в статье
гибкость для интеграторов
Возможность точно определить необходимые вам данные
Например, написать на бумажке batch-query в ODATA без подготовки оч. сложно.
Написать batch-query в GraphQL элементарно.
Также GraphQL обязывает клиента перечислить все необходимые поля которые должен вернуть сервер, запросы в стиле SQL где можно написать 'select *' в принципе недопустимы.
Если вы интегрируетесь с GitHub API, это очень сильные преимущества.
API получается более простое, контракт лучше зафиксирован.
Например, написать на бумажке batch-query в ODATA без подготовки оч. сложно.Переформулирую — для работы с odata нужно пользоваться соответствующими библиотеками. Это может быть и недостаток, но я бы и graphql без библиотек не советовал использовать.
Также GraphQL обязывает клиента перечислить все необходимые поля которые должен вернутьсервер, запросы в стиле SQL где можно написать 'select *' в принципе недопустимы.
А в чём здесь преимущество? Наоборот, подход odata позволил добавить динамические свойства, которые в некоторых сценариях очень полезны.
А где единый стандарт REST?
Вот семантика создания новой сущности это PUT или POST?
И то, и другое. POST — если сервер решает, какой будет URI у новой сущности, и PUT — если клиент.
Просто докуривайте мануалы до конца, не забычковывайте посередине))
Ну тут глубже немножко:
PUT — модификация сущности, а POST — публикация оной.
Поэтому PUT требует Id сущности, чтобы знать, что изменять. Если сущности такой ещё нет, то, в логике REST, пустая сущность перезапишется сущностью с данными. Это всегда будет одна и та же сущность.
А POST, в свою очередь, при каждом запросе будет генерировать новую сущность, на базе отправленных в запросе данных.
В итоге можно сделать вывод, что физически новую сущность можно создать как с помощью PUT, так и POST, но PUT, в отличие от POST, позволяет сделать это идемпотентно.
В GraphQL эти тонкости учитываются при использовании mutations, но там своё шаманство.
Спасибо, да, так более подробно. За исключением, пожалуй, пассажа про id, поскольку вот этот наш привычный маппинг id => сущность в REST специально не описан, вместо id там полный URI. И вполне возможен сценарий, когда API CMS на PUT /api/v1/pages/some/path/to/page/ просто создаст страницу /some/path/to/page/ на сайте, а всё шаманство с autoincrement id от клиента спрячет.
Да, вы правы, это, конечно же, оттого, что, как многие уже в комментах отписались, у REST нет четкого RFC. Поэтому трудно найти общие термины — они во всей литературе разные.
Под Id сущности я имел ввиду имя ресурса, если пытаться говорить на языке REST, т.е., в вашем примере, pages, some, path, to и page являются именами ресурсов. У каждого ресурся есть свой уникальный URI, например у path это /api/v1/pages/some/path.
Слэш (/) указывает на иерархию, поэтому some является еще и коллекцией, в которой лежит ресурс по имени path. И так далее. Кстати, является ли page тоже коллекцией мы однозначно пока сказать не можем =).
Так что, в кратце, PUT требует имени создаваемого ресурса в URI, а POST — только имя и URI ресурса-коллекции, в которую нужно добавить новый ресурс.
На сколько удобно в GraphQL с реляционными БД работать?
GraphQL не предъявляет никаких требований в РБД и не описывает это в своей спеке.
Есть postgraphql, который делает всё автомагически, но ограничения доступа и пользователей нужно настраивать на уровне БД.
Понятно, что у вас тут перевод статьи из двух абзацев и одного комикса. Комикс вы не перевели и не приложили, но, вообще-то, можно было и статью не просто перевести, а использовать как основу для своего, развернутого, поста.
А он не должен вас смущать. Вы должны сразу понимать, что GraphQL — это БОЛЬ язык для составления запросов. Со всей добавленной головной болью.
Просто представьте, что ваш сервер должен предоставлять SQL-доступ к вашим данным.
Я прошу прощения за вопрос, я совершенно ничего не знаю о graphql, но по беглому описанию возникает вопрос — зачем тогда вообще бэкэнд? В чём смысл проксировать SQL к SQL базе данных? Не легче ли уже тогда в принципе чуть модифицировать RDBS решения, и бэкэнд разработчики в принципе умрут как вид?
Или тут дело в том, что бэкэнд это не только КРУД?
SQL был мною предложен как простая и понятная аналогия, с которой большинство встречалось. Просто как некое представление о порядке сложности задачи.
GraphQL, конечно же, не SQL, это скорее это развитие NoSQL трендов последних лет. Если SQL строился как язык для реляционных данных, то GraphQL создавался как язык запросов к графам объектов. И это не учитывая того, что у них совершенно разный синтаксис. Так что бэкенд вам понадобится хотя бы для перевода одного в другое.
Другое дело, что бэкенд, даже в простейшем случае CRUD операций, может быть точкой сопряжения огромного чила разных баз данных, хранилищ данных, внешних сервисов. Сейчас многие типичные проекты имеют одну или более базу данных, кеш (а то и не один), выделенные процессы, выполняющие долговременные операции (по запросу или по расписанию), подключения к нескольким внешним сервисам. Всем это хочется управлять, так сказать, на своей территории, не отдавая наружу (во фронтенд) лишнего.
Бинарный, мультиплексрованный HTTP2 разве не для того, чтобы количество roundtips не имело значения?
Те, кто юзают в бэкенде Java и Hibernate знают о такой вещи как JPA 2.1 Entity Graphs. Фактически это та же идея, что и GraphQL.
В итоге GraphQL может прийти на смену самому популярному на сегодняшний день типу API — REST API.
Вообще-то, GraphQL — подмножество REST.
нет ключевых особенностей REST — эндпойнты для разных ресурсов и http verbs.
Это просто такая реализация, которая затьмила весь REST.
wiki
В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API.
Мы сейчас используем jsonapi. Он гораздо ближе к graphQL.
jsonapi — это обычный стандартизированный rest, каким он должен быть.
{ "id": "<id>", attributes: { ... } }Тогда как самая простая сериализация имевшихся сущностей была такой:
{"id": <id>, "attribute1": <attribute1>, "attribute2": <attribute2>, ... }
Таким образом пришлось писать вокруг этого сериализаторы-десериализаторы.
И да, jsonapi в том проекте был через REST, ибо REST — это прежде всего способ утилизации http-протокола (формирование ссылок — «ресурсов» — и рекомендации по использованию HTTP verbs — «методов»), а не формата body.
С сериализацией/десериализацией проблем особо не было никогда. Обыкновенная работа со структурами данных.
Тут профит в том, что структура jsonapi-сущности документирована и исключает споры, тогда как «самых простых сериализаций» может быть несколько.
GitHub переходит на GraphQL