Comments 142
Вот только вчера потыкал палочкой гитхабовский GraphQL, остался доволен, особенно explorer порадовал.
Вообще, с подобными технологиями скоро уже действительно будет всё выглядеть так, что изменение одного поля в БД точечно изменяет строчку в компоненте на экране тысяч пользователей по всему миру (ну и в обратную сторону, конечно). Разработчику останется только писать словарики, прокидывающие названия полей)
Может кто поделится Best Practics?
Было бы интереснее почитать сравнение GraphQL и ODATA (http://www.odata.org), которая давно решает эту же задачу.
И только после шести запросов мы можем собрать ответы и обеспечить компонент необходимыми данными.
Полнейший бред. Бэкенд может спокойно возвращать вложенный JSON. Сейчас бэкенд на .NET так работает, Django REST это умеет.
Т.е. вместо того чтобы найти нормального бэкенд разработчика предлагается ещё больше всё усложнить.
В целом же я сторонник той трактовки REST, которая предполагает создание отдельного ресурса, возвращающего максимум информации минимумом запросов. В приведенном примере это был бы ресурс personRoot.
запрос этого ресурса не должен возвращать что-то, кроме данных самого ресурса и гиперссылок на связанные ресурсы
это не так. существование ресурсов — вот парадигма rest. Должны ли вложенные документы быть или нет, rest не говорит. rest — это вообще не спека. Это набор общих принципов. Все, что в прицнипах не оговорено, ты волен делать сам. Одна из спек rest — jsonAPI — например описывает возможность вложенных полей.
понятно, что нужно соблюдать баланс, но всё-таки в общем случае лучше иметь еще и расширенную версию ресурса, чем только одну, но перегруженную.
ну в graphql же у вас есть возможность вложенности. Опасно вам стало?
rest не описывает вложенность. но никому не мешает написать спеку с описанной вложеностью, и методами для частичного получения полей и документов.
А graphql это сделал, и сделал неплохо, и сделал досконально — в этом соль.
Самый большой гемор с JSONAPI — собирать все данные, на мобильных приложениях это оказывается довольно весомо, тем более на ReactNative, где код выполняется на JS'e и слегка подтормаживается. GraphQL очень хорош для мобильных приложений, где клиент должен быть максимально быстрым и тупым. Вся структура ответа изначально известна, красивая чистая верстка без мучений с линковкой данных.
Почему возможности опасны? Это один из базовых принципов построения архитектуры: ограничивать спектр возможностей, но не исключая их, оставляя выбор конкретных решений разработчикам этих решений, следующих данной архитектуре.
Ведь в конце концов, если вернуться к истокам этой аббревиатуры, REST — это архитектурный стиль. То бишь, поименованный набор архитектурных ограничений (см. диссертацию Филдинга). У этого архитектурного стиля есть определённый и хорошо описанный контекст, набор достоинств и отстоинств (в той же диссертации).
GraphQL — это же не архитектурный стиль. Почему мы их сравниваем? (Или я ошибаюсь?)
На мой взгляд, у REST есть ещё один замечательный юз-кейс в современных микросервисных системах, который на момент написания диссертации ещё не существовал. Если ввести дополнительное ограничение и оставить только безопасные и идемпотентные методы — тогда он отлично будет применим в CQRS/ES для моделей для чтения.
Почему возможности опасны?
потому что ведут к разнообразию, а разнообразие в рамках одного проекта ведет к хаосу.
GraphQL — это же не архитектурный стиль. Почему мы их сравниваем? (Или я ошибаюсь?)
потому что GraphQL плохо вписывается в парадигму REST, и использование его как инструмента ведет к необходимости пересмотра архитектуры в целом.
архитекуры чего? только адаптеров клиентов к апи. graphql — это view. view не требует пересмотра архитектуры.
в вопросе противопоставления GQL и REST реализация REST предполагает наличие раздельных эндпоинтов для разных сущностей. соответственно, необходимости делать множество запросов к апи для получения множества связанных сущностей.
статья и большая часть обсуждения, действительно, не имеют смысла при наличии адаптеров между апи и потребителем. но адаптеры — это дополнительная сложность, которой стараются избежать, потребляя апи напрямую.
использование GQL напрямую с апи, очевидно, потребует изменений некоторых эндпоинтов. активное использование приведет к отказу от использования большинства эндпоинтов.
я не очень вас понимаю тогда:
потому что GraphQL плохо вписывается в парадигму REST, и использование его как инструмента ведет к необходимости пересмотра архитектуры в целом.
использование GQL напрямую с апи, очевидно, потребует изменений некоторых эндпоинтов. активное использование приведет к отказу от использования большинства эндпоинтов.
да, graphql — это не rest, в нем один эндпойнт, и клиенты нужно будет переписать. это не плюс и не минус. Это миграция.
Film возвращать как дочерний объект с полями ID и Name например.
Посыл статьи «не смогли реализовать REST API попробуем GraphQL».
Если уж хвалить GraphQL так за какие-то реальные преимущества, а не возможность решить надуманные проблемы.
Смотрю Graphene-Django, есть интересная фича фильтровать данные по параметру например, это реально полезно и может сэкономить время и силы.
В общем как с реактом, идея хорошая, ждём пока будет достойная реализация.
Хорошо, вы можете предусмотреть inclusion на манер JSON-API. А если понадобиться больше чем один уровень вложенности?
Все это в лучшем случае ведёт к грязному апи. В худшем к необоснованной денормализации данных и страданиям.
Что мешает создать endpoint на бэкенде, который будет возращать только нужную информацию?
Типичный ответ бекенд-разработчика: «Мне что пилить новую модель под каждую потребность?» И последующие объяснения, что наследование хоть и хорошо, но поддерживать большое количество моделей труднее, или надо их хачить в каждом отдельном сервисе и т.д. и т.п.
GraphQL же предлагает выставить все внутренности наружу.
Условно говоря — выдавать сигареты из окошка киоска намного проще и более контролируемое действие, чем открыть двери нараспашку, а потом пытаться ограничить бесконтрольный вынос всего и вся из магазина.
GraphQL же предлагает все вывалить на станции метро в час пик.
И не предлагает решений и спецификаций как это ограничить за разумные деньги и усилия.
GraphQL же предлагает все вывалить на станции метро в час пик.
И не предлагает решений и спецификаций как это ограничить за разумные деньги и усилия.
GraphQL предлашает спеку, как апи сделать удобным для фронта и не описывает серверную сторону. Серверные решения — за вами
Типичный ответ бекенд-разработчика: «Мне что пилить новую модель под каждую потребность?»
Если альтернативой будет выпиливание универсальной модели под все потребности, то лично я на месте бекенд-разработчика предпочел бы выпилить новую модель.
Честно говоря, не понимаю вот эти вот описания типа «мы получили список пользователей, а теперь, если нам нужно получить топ-10 их сообщений, мы просто добавляем...»
Чтобы на фронтенде что-то «просто добавить», это все должно быть сначала реализовано на бекенде. То есть, язык запросов почему-то зачастую преподносят как готовый инструмент.
Мне кажется, лучше изначально применить архитектуру, исключающую избыточность, чем каждый раз ломать голову над дизайном моделей и коллекций, потом долго оптимизировать, подхачивая модели по месту.
Не отрицаю, можно построить великолепный RESTful API, снабдить его отличным свагером. Но так получается, что есть одно слабое место – избыточная выгрузка, другое – жестко заданные модели, которые не всегда легко подстроить под меняющиеся потребности, третье – версионность. В сумме это повышает вероятность зашить в API неисправимые дефекты, которые потом станут сакральными багами. Встречали такие? Это когда благодаря багу все более-мене работает на фронте. Стоит его пофиксить, и все развалится. Не отсюда ли пословица «работает — не трогай!» :)
фронт потихоньку хочет стать драйвером всей разработки
Вы проницательны и частично правы. Но такое стремление фронта не от желания захватить мир.
Если свести дуализм проблемы REST–GQL к одной фразе, то эта фраза будет о том, кто лучше готовит view-оринтированные данные.
Любой API – это этап на пути трансформации данных во view-оринтированный формат. Отправная точка — БД. В ней данные разбиты на информационные сущности и, что важно, нормализованы и индексированы ради оптимального расходования места и скорости доступа (если говорить про реляционную БД). Замечу, ни у кого не вызывает сомнения необходимость нормализации ради компактности.
Но такие данные вряд ли годятся для визуализации. Потому API является не просто шлюзом к данным, но как-то трансформирует их под ту или иную задачу фронта. Поскольку задач у фронта много и они возникают иногда с пугающей скоростью, беку просто не угнаться за подготовкой данных под каждую задачу.
Все приходит к тому, что бек говорит, мол мы же дали вам два массива связанных данных, соберите из них, что вам конкретно нужно. И фронт каждый раз собирает. Каким бы мудрым не был API очень редко ответ сервер не требует дополнительного процессинга на фронте.
И тут появляется GraphQL, а вместе с ним возможность декларативно объявить и получить именно те данные, которые нужны компоненту. Конечно, такая плюшка притягательна для фронта. Представляет, сколько строк кода можно сэкономить повсеместно? Причем для бека сложность поддержки GQL вряд ли больше, чем поддержки REST. Поэтому фронт, как конечный потребитель данных, хочет быть услышан
Для проектов, где достаточно crud-like логики и апи есть смысл сделать анемичным – тут GQL выигрывает во всём. Но когда у вас добавляются пользовательские настройки, десяток ролей с разными уровнями доступа, фильтры по всему подряд и какая-нибудь god-like-табличка у пользователя с хитрыми формулами расчёта и тому подобным – любой endpoint, способный возвращать что угодно клиенту становится самым узким местом как в логике, так и в производительности.
Упомянутые выше RESTful + JsonData отлично справляются с задачами «не дублировать данные» и «дать свободу клиенту выбирать какие связанные данные нужны в ответе, а какие нет», при этом не ограничивая бекенд-разработчика и позволяя ему, например, оптимизировать дорогой запрос руками.
В случае же оптимизации GQL приходится с клиентами устанавливать негласные соглашения об ограничениях запросов в духе «да, ты можешь делать так, но это будет на порядок дольше чем вот так», – что, даже в случае наличия документации, не очевидно и не поддерживаемо.
Я, как бекендер, с удовольствием перейду на GQL когда (если!) появится вменяемая реализация, позволяющая решить проблемы выше (доступ, оптимизация). Для PHP я ни одной такой пока не нашёл, например.
Единственное почему graphQL лучше за REST — это то что Вы можете запросить совсем не связанные ресурсы одним запросом.
Например, в блог приложении Вы можете единственным запросом:
- статьи из рубрики с учетом пагинации
- топ авторов
- топ статьи
- топ комментарии
Аналогично можно сохранить сразу пачку не связанных сущностей.
В остальном все то же самое можно сделать в REST. Как правильно упоминали в комментариях, еще в 2007 Microsoft придумало стандарт oData, который решает те же проблемы. Но почему-то такого ажиотажа, как c GraphQL — не было :)
Вот интересное сравнение — https://www.progress.com/blogs/rest-api-industry-debate-odata-vs-graphql-vs-ords
Например, в блог приложении Вы можете единственным запросом:
Почему нельзя то же самое сделать в REST?
В REST URL является уникальным идентификатором для ресурса. Поэтому если у Вас на GET /articles можно запросить и еще кучу всего не связанного, то это уже не REST, так как теряется смысл урлов вообще. Ведь можно просто сделать GET /api, который по GET параметрах возвращает все что угодно. И тогда Ваш REST эволюционирует в oData или GraphQL :)
Производительность имеет огромное значение, если Вы пишете мобильное приложение :) Вы же не хотите чтобы Ваши пользователи говорили что оно глючное (3G, покрытие и т.д.).
Поэтому 4 промиса решают проблему объединения данных, но Вы каждый раз будете тратить время на соединение, проверку CORS, авторизацию, права доступа и что там еще есть. А так — все за один раз.
Согласен на счет ресурса агрегатора, но это в том или ином виде получится GraphQL.
Кстати, я не думаю, что GraphQL полностью вытеснит REST. GraphQL очень хорошо работает для микросервисных архитектур как API Gateway наружу. А внутри проще использовать REST или RPC.
Чаще всего оказывается что запрашивать данные с такой гранулярностью не получатся и начинается подход — «Загрузим все а потом отфильтруем в памяти».
Что напрочь убивает всю задумку.
Ну, или приведите пример, в каких случаях и что конкретно не получается.
Поэтому для большинства проектов я бы сказал слишком громкий заголовок у статьи
Я в случае с mongo те-же 6 запросов в итоге будут, если films и persons в разных коллекциях лежат.
Есть также взгляд, что RESTful API можно делать поверх GrpahQL API
Вот реально, GraphQL продвигают фронтендеры, потому что упрощается их работа.
В этом случае сложность бэкенда перекроет все плюсы
Какую дополнительную сложность приносит GraphQL в подобной ситуации?
Мне кажется, не сильно усложняет, может и не усложняет вовсе. Но я не бекендер, мне не видно
Со стороны фронта, кончено, упрощение встретят «на ура». Но причина не в лени.
Какой проект не возьми, везде свои решения для запроса данных, кеширования, асинхронных уведомлений от сервера. Каждый раз думаешь, когда мы слезем с велосипеда в этой части?
И тягу к идеальному нельзя задвинуть. Оптимизация запросов на клиенте, отсутствие избыточного пейлоада, повышение отзывчивости – это хорошо, это правильно.
И к слову, чтобы все это применить на клиенте, тоже надо руки приложить. Особенно такой фреймворк,
как Relay Modern. По меньшей мере придется как следует разобраться с вебпаком, чтобы применить правильный лоадер для graphql-схемы, поставить плагин в бабель, изучить React, понять что есть HOC. Не скажу, что GraphQL это прямо подарок лентяю.
Я тоже задаюсь этими вопросами. Пока что, исключительно для себя, ответы такие:
Какие проблемы оно решает?
Мы не знаем, какие данные и в каком виде нам потребуются на клиенте завтра, но мы хотим получать их максимально просто, быстро и эффективно — т.е. одним запросом и без "лишних" полей в ответе. Примерно так, как бэкенд может получать данные через SQL. При этом мы не хотим открывать клиенту полный доступ к базе (это небезопасно), и хотим избежать необходимости вносить изменения на бэкенде под каждый новый тип запросов, который понадобился клиенту (это ограничивает свободу творчества на клиенте и скорость его разработки).
Чем лучше старого-доброго RPC?
Формально это и есть один такой универсальный вызов RPC "считать/записать (почти) любые данные". Но по сути это лучше старого-доброго RPC тем, что это один вызов, который достаточно реализовать один раз, и нет необходимости добавлять новые вызовы на бэкенде под каждый новый тип запросов клиента.
Почему его сравнивают с REST?
Потому что в REST нет возможности "считать/записать (почти) любые данные" одним запросом, и REST клиенты страдают, реализуя этот функционал вручную, через кучку отдельных запросов. <sarcasm>Так что GraphQL "это как REST, только лучше".</sarcasm> На самом деле, конечно, ничего общего между REST и GraphQL нет.
Резюмируя всё это, моё личное мнение: корректно и полноценно реализовать GraphQL на сервере — крайне сложно. И я сейчас не про парсер GraphQL, который уже реализован в куче библиотек, а про бизнес-логику функций, которые получают/изменяют конкретные поля данных. В GraphQL слишком много от прямого доступа к данным, что сильно усложняет корректную реализацию бизнес-логики того, какие поля в каких ситуациях кому можно читать/писать. Так что требования к сложности, гибкости и разнообразию клиентских запросов должны быть поистине гигантскими (примерно масштабов фейсбука), чтобы вся эта сложность реализации GraphQL на бэкенде стала оправданной.
P.S. Думаю, в будущем мы увидим очень много примеров дыр нового типа GraphQL-injection, когда через специальным образом сформированные GraphQL-запросы можно будет считывать и изменять данные, к которым доступа у этого юзера быть вообще не должно.
REST — это не
GET — /people/{id}
:)
GraphQL — сам подмножество REST.
Безграмотность.
В GraphQL можно, например, сделать мутацию GET-запросом, а это идёт вразрез идеологии REST. Так что рассматривать GraphQL как подмножество REST не очень корректно.
По поводу множества запросов — тоже полнейший бред. REST никак не стандартизирует это. Вы вполне можете создать endpoint /getFilm который вернет фильм с жанрами, актерами и т.д.
И да, в таком виде «GraphQL — сам подмножество REST».
Имплементировать мутацию на GET-запрос то можно, но это уже не будет идеологиский REST. Спецификации на REST нету, но если почитать оригинальную диссертацию дядьки Роя Филдинга, то там указывается на использование методов HTTP по назначению и GET приводится как пример "retrieving a representation of a resource". Также там запрашиваемый ресурс идентифицируется URL-ом (в GraphQL обычно всего один endpoint). Конечно, между GraphQL повех HTTP и REST поверх HTTP будет что-то общее — собственно HTTP и отсутсвие состояния на сервере. Но GraphQL не ставится REST-ом из-за этого.
По поводу /getFilm — многие идеологи REST Вам скажут, что такое именование не очень "идеологично". Оно указывает на действие, а не на ресурс, т.е. это RPC-style, а не pure REST-style. В идеале должен быть ресурс типа /film/<id>. Но если вернуться к вопросу о множестве запросов — допустим вы реализовали endpoint, который возвращает фильм со списком актёров, где для каждого актёра указан его id и имя. Но тут frontend-щикам понадобилось вдруг больше инфы, там, например, пол актёра, чтобы картинку сбоку отобразить. Конечно, проблема решаема — ticket для backend-еров в backlog, ожидание следующего планирования пока он попадёт в sprint, потом QA и frontend-щики разблокированы, если к тому времени они не решили делать 1001 запрос для каждого актёра. Но в таком случае цикл получается длинее и agile становиться не таким уж и гибким. Конечно, если Вы — единственный разработчик или же у вас всё продумано заранее, есть чёткие спецификации от BA, то REST писать куда проще. Но для некоторых проектов, могу предположить, GraphQL будет иметь итоговую выгоду.
===
REST — это архитектурный подход предполагающий клиент-серверное взаимодействие, БЕЗ хранения промежуточного состояния. Нет состояния, нет проблем, есть куча фишек вроде кеширования и слоистости. Это не про ресурсы /user:id user/:id/comment/:id, не про GET-PUT-DELETE… как думают многие и откуда растёт миф.
это уже ваша надстройка
Это не моя "надстройка". Это "надстройка" Роя Филдинга, который собственно ввёл понятие REST и на которого есть ссылки в Википедии. Например, про идентификацию ресурсов — http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#tab_5_1
Но я совсем не хочу спорить насчёт терминологии. Если определиться, что REST — это любой клиент-серверный подход со stateless протоколом коммуникацией и не более, то почти всё в таком случае — "подмножество REST", там в т.ч. запросы в библиотеку через голубиную почту.
И я совсем не утверждаю, что GraphQL — это единственный правильный подход, который подходит для всех проектов. Кто-то может сделать универсальный /getFilm и напихать туда всю инфу, которую только можно представить, и не заботится о траффике, кто-то может сделать 1001 endpoints под всевозможные случаи и не заботится о количестве запросов, а кто-то может запускать цикл разработки по-новой из-за любого чиха PO/BA/UX-UI-щика. Каждому своё — у каждого свои потребности и свои ресурсы на их удовлетворение.
Это не моя «надстройка». Это «надстройка» Роя Филдинга, который собственно ввёл понятие REST и на которого есть ссылки в Википедии. Например, про идентификацию ресурсов — www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#tab_5_1И где тут про GET? Я не вижу там этого слова.
Это было про идентификацию ресурсов. По поводу использования методов HTTP (или другого протокола нижнего уровня) для семантики запросов там чуть ниже написано:
standard methods and media types are used to indicate semantics and exchange information
А ещё чуть ниже на той же странице есть пример, касательно REST поверх HTTP:
The most frequent form of request semantics is that of retrieving a representation of a resource (e.g., the "GET" method in HTTP)
А в 6-й главе REST поверх HTTP рассматривается подробнее.
В общем, если почитать диссертацию внимательнее или последующие статьи этого дядьки, то некоторая картина складывается и многие аспекты идут вразрез с новомодными идеями GraphQL. Но, т.к. это не строгая спецификацию, то не вижу смысла спорить.
Не совсем понимаю, какое правильно применения у этой технологии. Сам с REST API полноценно не работал (не создавал), и могу ошибаться по поводу того, как должно быть правильно и канонично.
Как я понимаю, чаще всего в реальном приложении, api представляет сложнее, чем простой CRUD, требующей выполнения какой-то логики на бэкенде для обработки запросов к endpoint'ам.
GraphQL выглядит как Data Access Level и неплохо ложиться на SQL и всякие ORM поверх него. Но где в таком случае сама логика? "Позади" GraphQL, т.е. GraphQL обращается не к данным из хранилища, а к бизнес логике?
Но в таком случае скорее всего невозможна та гибкость, о которой пишут, ведь априори логика реализует какой-то ограниченный функционал.
Или может быть сейчас вообще всю логику переносят на клиент, оставляя на бэкенде лишь CRUD доступ к данным и авторизацию+аутентификацию?
Например, на graph.cool для этих целей предлагается использовать функции. Они позволяют сделать что-то на разных этапах обработки запроса. На скриншоте показан выбор этапа при создании функции.
Сами функции могут хоститься на облачных сервисах типа AWS Lambda.
Если пишете свой GraphQL бекенд, то используете какую-то библиотеку. Она, наверняка, будет предлагать аналогичный механизм келбеков.
не целую архитектуру, а взаимодействие с фронтэндом.
если предположить, что ваше приложение построено на некоем сервисном слое, то graphql — это то, что до сервисного слоя, и то, что после. Бизнес логика остается с вами.
и то, что после
Я правильно понял, вы предлагаете GQL использовать для доступа к сырым данным (это обычно БД)?
Но главное — это то, что GQL крут именно возможностью гибко запрашивать информацию целыми графами. Изменять состояние этими же целыми графами — очень нетривиальная задача, и я бы не рисковал реализовывать (или использовать реализованную в числе первых… ну миллиона) настолько сложную систему.
GQL — для чтения, REST/RPC/чтотоеще — для записи.
да, перечитал свой коммент и понял что неправильно сформулировал. Читать так:
если предположить, что ваше приложение построено на некоем сервисном слое, то graphql — это то, что до сервисного слоя во время реквеста, и то, что после во время респонса. Бизнес логика остается с вами.
request -> graphql -> сервисный слой -> бизнес-логика -> сервисный слой -> graphql -> response
вы навреное не понимаете как graphql работает. graphql ничего сам не записывает и ничего не читает. он принимает запрос, валидирует его, роутит в определенный ресолвер, где вы чем хотите тем и обработаете. И после обработки выплюнет результат.
Обработка (чтение или запись) всегда остается на вашей совести.
Мне кажется, вы видите проблему в том, что запись не может быть столь же произвольно безграничной, как получение данных. Блокировки–транзакции–индексирование на уровне БД ограничивают попытки менять данные произвольным образом. Все ради поддержания целостности и доступности данных.
Но GQL не дает абсолютной свободы ни в запросах, ни в мутации. Это только кажется, что любой путь в графе доступен. Представление данных в виде графа позволяет делать крутые оптимизации на фронте. Но на беке, чтобы путь в графе был доступен, он должен быть разрешен схемой.
Некоторые сервисы, например graph.cool, имеют два варианта API — упрощенный и полнофункциональный. В упрощенном API для всех типов данных неявно создаются разрешения на доступ к их полям, а если какое-то поле связано с другим типом, то и к узлам этого типа. В полном API ситуация строже — нужно самостоятельно определить разрешенные для чтения пути.
С мутациями все еще строже. Нет никакой произвольности. В схеме должны определять доступные мутации. Каждая мутация – это функция, которая может проверить входные данные и сделать нужные запросы к БД. Клиенту доступна та или иная мутация, он может вызывать ее с разными параметрами, но он не может через GQL менять любые данные в графе, как заблагорассудится.
PS. На мое знание GQL пока нельзя полагаться – только недавно стал изучать GQL и больше со стороны фронта.
p. s. Я не веб-программист, если порю чушь, извините.
Представьте себе, что сегодня изобрели язык SQL, но ещё нет ни одной СУБД, которая с ним работает. Какой смысл в SQL тогда? Никакого. Что с этим языком можно делать обычному программисту? Ничего.
Собственно, пока не будет развитой системы библиотек, поддерживающих GraphQL нативно, чтобы действительно можно было заниматься решением непосредственных задач, а не тратить всё время на то, чтобы это хоть как-то шевелилось, во имя далёкого светлого будущего, использование GQL остаётся больше академической задачей, чем практической.
Та вроде бы уже хватает библиотек, хотя всё же заметен перекос в сторону ноды.
Могу ошибаться, но профита для себя (и для нашей компании) пока не вижу.
Но интерес присутствует, наблюдаю уже давно.
На сколько я вижу, эти библиотеки пока что, грубо говоря, из области «парсинг SQL»
поясните фразу.
GraphQL никак не относится с sql, и все что там парсится — это json-оподобный язык запросов фронта.
Если я захочу использовать GQL, то у меня 80% времени (если не все 100) уйдёт тупо на обеспечение его поддержки, собственными костылями и подпорками в виде тех библиотек.
Возьмём для сравнения OData. Я, как программист на .NET, имея под рукой любую СУБД, сложную и развитую схему данных, Entity Framework, подключаю OData и получаю полностью работоспособного сервера, который может обрабатывать OData-запросы с клиентов, отдавать мета-данные и схему, делать фильтрацию по любым полям, сортировку, агрегацию, запрашивать за один round-trip целые графы данных и это будет транслироваться в очень эффективные SQL.
GQL на сегодняшний день может похвастаться только идеей. Но не реализацией. И пока вчистую проигрывает той же OData по всем фронтам. Это не значит, что его время не наступит. Но чтобы его двигать, надо получать пользу прямо сейчас, а не когда мы перепишем весь свой код под GQL, навтыкаем костылей и заставим шевелиться, то тогда может быть, должно быть, всё вообще станет радужно и прекрасно.
А можете в readme.md показать все с обвязкой в Startup.сs (Microsoft.AspNetCore), т.е. как вы переправляете запросы типа http://MyService/OData/Orders?$select=Name на ваш обработчик-parser? Чтобы понять время жизни объектов.
Example Asp.Net Core OData service in \sln\OdataToEntityCore.Asp.sln, client Microsoft.OData.Client in \sln\OdataToEntity.AspClient.sln
Startup
Не стоит так категорично за все библиотеки говорить. Relay — довольно продвинутый фреймворк, а не только парсинг синтаксиса GraphQL. Ну а .NET — да… там исторически сложилось, что всё очень консервативно (enterprise как-никак), всё новомодное в нормальной имплементации появляется почти самым последним и часто только с пинка Microsoft.
Пример в доке: https://doc.cuba-platform.com/manual-6.5/rest_api_v2_ex_get_entities_list.html
Так что совсем не обязательно внедрять GraphQL, можно использовать существующие языки, дополнительно лишь описывая требования к глубине детализации.
А когда я был маленьким было принято бить по рукам за прямые *QL запросы с клиента на сервер :) Инъекции, вот это всё.
Оказывается надо было просто заменить S на Graph.
Чем это вообще лучше простого SQL с экранированием?
Фронтендер зависит от бекендера, чего не скажешь об обратном. По этой причине фронтендер так или иначе вникает в проблемы бека, но не всегда бывает наоборот.
Если бекендер вложил массу времени и сил в изучение архитектурных подходов REST, а затем свел руки вместе, поднял над собой и сказал: «Я в домике», – то фронтендеру остается с грустным видом удалиться, волоча на шнурке какой-нибудь GraphQL.
Но если смотреть на сервис как на конечный продукт и понимать проблемы фронтенда (к слову, современный фронтенд вряд ли уступает по сложности бекенду), то GraphQL будет выглядеть незаменимым инструментом для решения многих проблем:
1. Уменьшение количества запросов и пейлоада, о чем говорилось в статье.
2. Обновление состояния приложения на сообщениях от сервера на основе subscriptions.
3. Оптимальное кеширование. Оба популярных клиентских фреймворка – Relay и Apoll реализуют его из коробки.
4. Проблема начального этапа разработки, когда отсутствие эндпоинтов вынуждает мокать данные, писать обертки в коде. Вместо этого фронтенд может воспользоваться BaaS-сервисами типа graph.cool и scaphold для быстрого и бесплатного прототипирования, а когда будет готов свой бекенд, – просто поменять адрес сервера.
5. Декларативность кода. Лично у меня давно возникает диссонанс от необходимости писать модуль fetch с retry, создавать словари для разных ресурсов и HTTP-методов. По сравнению с подходом того же Redux, это кажется громоздким, бессмысленным, ибо повторяется из проекта в проект, не соответствующем времени.
GraphQL не только язык. Как бывает с удачными подходами — они вдохновляют на создание целой экосистемы инструментов, решающих основную и сопутствующие проблемы. Такими инструментами являются упомянутые клиентские фреймворки Relay и Apollo. Да, их применение требует изменить многое на бекенде, и тут могут быть сложности.
Но сложность связана с новизной, с необходимостью бекен-разработчика изучать новые подходы, когда он столько сил потратил на изучение старых. Это понятно и оправдано. Но в конечном счете, общее дело делаем. И вы правда считаете REST вершиной эволюции? Уверены, что через 10 лет кто-то будет вспоминать про REST? Как бы не оказаться в хвосте очереди
Почему GQL встречает такое сопротивление?
Потому что приходит кто-то и говорит: «Вы используете REST? А я вам вот GraphQL принёс! Вы с ним сможете делать такие же проекты, как с REST, только без REST. Теперь ваш REST мертвый. Давайте переучивайтесь поскорей.»
И дело даже не в банальной вежливости (я, например, больше 10 лет использую технологию, которая «мертва» уже 20 лет, и каждый раз когда мне об этом напоминают, я только улыбаюсь). Дело в том, что вы не Гугл и не Facebook, где внедрение такой технологии сэкономит терабайты трафика. И то, что вам кажется сопротивлением — всего лишь трезвый взгляд на новую вещь.
Но и сводить достоинства GQL к экономии трафика не совсем верно. У него гораздо больше плюсов. Да, их получаю в основном фронтенд-разработчики. При правильной организации, плюсы получит сервис в целом (надеюсь). Непосредственно со стороны бекенд-разработчика, возможно, плюсов не так много.
А по факту я вовсю давно пользуюсь loopback (на node.js), который все может (определять поля в ответе, вкладывать связанные сущности, генерировать модели по json'у, выдавать результаты реактивно по подпискам и кучу всего разного), причем имеет коннекторы ко всем распространенным базам, и их в проекте может быть сколько задашь.
И еще из коробки: ставить хуки на запросы, управлять доступом, смотреть апи через эксплорер, имеет SDK для Android, iOS и angular…
Подожду loopback на GraphQL, пожалуй.
суть не в том, что кто-то чего-то умеет — почитайте комменты, так или иначе многие решали у себя в проектах проблемы, решаемый grapqhl.
суть в том, что теперь не надо самому придумывать велосипед разной степени качества и готовности — написана отличная спецификация и куча реализаций на разных языках.
я не работал с loopback. Выделите несколько ключевых особенностей, чтобы понять зачем вообще аналог нужен с graphql.
Graphql уже есть, и есть реализации на многих языках как серверной части, так и клиентской.
К нему легко подцепляются EventSource и socket.io.
Есть кстати у loopback даже discover — построение моделей по уже существующей базе. То есть взял базу, и через 20 минут у тебя к ней REST API (с пользователями и настройками ролей/доступов).
С другой стороны есть вообще замечательный parse-serer, который из коробки дает интерфейс создания произвольных моделей, тоже может уведомлять с сервера (у него есть т.н. LiveQuery), одно но — он работает только с MongoDB.
Я ничего против graphql не имею, просто не знаю, есть ли готовые универсальные решения по типу описанных с ним, или нет. И пока думаю что нет. Знаю что meteor вроде собирался поддерживать graphql, но на метеоре я считаю имеет смысл делать только проекты с небольшим числом пользователей (до 1000 скажем).
Зависимость клиента от сервера.… 2) не привязывает клиента к конкретному серверу.
М, это как? Я смогу отпрвить тот-же запрос к Github например?
в другом три поля
в итоге не закешировать ничего. или же придется хранить по 100500 разных копий одинаковых данных — тем самым ваша якобы оптимизация сводится на нет.
а когда запрос на 1 набор данных — можно закешировать.
Если GraphQL API не публичный и предназначен для внутренних клиентов (мобильных или веб), можно использовать списки доступа и предварительно одобренные запросы. Клиенты требуют сервер выполнить такие запросы, указывая вместо запроса его идентификатор. Кажется, Facebook применяет такой подход.
Зачем тут GraphQL?
предварительно одобренные запросы
Так это и есть RPC
Если вы делаете публичный API может и есть смысл, если же API предназначен для внутренних клиентов RPC самое оно.
Множество вещей, которые клиент не должен видеть, часто на основе ролей запрашивающего пользователя.
Частичный ответ позволяет разработчикам запросить только ту информацию, которая им нужна. Например, запросы к некоторым API могут вернуть кучу лишней информации, которая почти не используется: всякие таймстампы, метаданные и т.д. Чтобы не запрашивать лишнюю информацию, в Google придумали частичный ответ.
Linkedin /people: (id, first-name, last-name, industry)
Facebook /joe.smith/friends?fields=id,name,picture
Google ?fields=title, media:group(media:thumbnail)
Это совершенно никак не связанные вещи.
Тут вы неправы. Оба два — это языки запросов, что следует прямо из их названия, при этом GraphQL ещё и транслируется в SQL по достаточно очевидному алгоритму.
Я бы сказал что GraphQL это просто синтаксический сахар над SQL. Не писать лишний раз несколько ключевых слов вроде SELECT, FROM и WHERE… Да и всё, пожалуй. Ну, хотя, ещё структуру ответа он сам подгоняет к JSON требуемой формы.
То, что GraphQL это язык запросов, не говорит о том, что он напрямую связан с SQL-запросами и базами данных. Откуда данные возвращаются, уже другой вопрос.
Ну да, никто и не говорит что он напрямую со SQL работает. Там может быть и монга отвечать, суть не меняется.
Только вот и SQL и GraphQL всё равно — языки запросов. И они очень даже взаимозаменяемы.
{
person(personID: 4) {
name,
birthYear,
homeworld {
name
},
filmConnection {
films {
title
}
}
}
}Вот такой вот запрос на GraphQL мог бы быть заменён на вот такой в SQL:
SELECT p.name, p.birthYear, h.name,
array_agg(SELECT f.title FROM p LEFT JOIN persons_films AS pf ON p.id=pf.person_id
LEFT JOIN films AS f ON pf.film_id = f.id)
FROM persons AS p, planets AS h
WHERE p.id = 4 AND h.id = p.homeworld_idНу, условно, потому что SQL я не пользовался очень давно. Тут можно отметить что GraphQL запрос куда более прост для составления (никаких больше явно прописываемых джойнов!), но при этом менее гибок (хотя это скорее потому что в сравнении со SQL что угодно покажется дубовым).
И, вообще-то, SQL тоже не налагает никаких ограничений на то, откуда именно берутся данные — он лишь говорит какие именно данные ему нужны, точно так же как и GraphQL. И это крайне логично, ведь, повторюсь, оба они есть лишь языки запросов — то есть, способ запросить данные у провайдера, не завязываясь на том, как именно они у него хранятся. Так что SQL запрос тоже не обязан совершаться как выборка данных из БД.
Так что SQL запрос тоже не обязан совершаться как выборка данных из БД.
FROM persons AS p, planets AS hА как быть с этим?
А что с этим? Это всего лишь названия коллекций, которые присутствуют и в GraphQL запросе. Я даже немного перепишу запрос для наглядности:
SELECT p.name, p.birthYear,
(SELECT h.name FROM planets AS h WHERE h.id = p.homeworld_id),
array_agg(SELECT f.title FROM p LEFT JOIN persons_films AS pf ON p.id=pf.person_id
LEFT JOIN films AS f ON pf.film_id = f.id)
FROM persons AS p
WHERE p.id = 4Всё что делает GraphQL — это несколько упрощает написание запроса, беря на себя менеджмент отношений one2many и many2many, хотя при этом быстродействие значимо не повышается (сами посмотрите список возможных проблем, там в том числе указана и DoS атака с запросом множественно вложенных сущностей). Ну и лексика у него более компактна, что конечно достаточно большой плюс с одной стороны… А с другой — ну вот сколько таких запросов может быть в типичной приложухе? Десятки? Несерьёзно, GraphQL слой можно настраивать куда дольше чем времени будет потеряно на десятке-другом SELECT, FROM, WHERE и JOIN. Но при этом если кто-нибудь увидит что из приложения я отсылаю на сервер SQL запросы, со мной потом за руку здороваться перестанут, а скорее даже к дому с факелами, смолой и перьями придут. А GraphQL запросы — это ничего, это нормально, стильно, модно и молодежно :)
Если GraphQL API не публичный и предназначен для внутренних клиентов (мобильных или веб), можно использовать списки доступа и предварительно одобренные запросы. Клиенты требуют сервер выполнить такие запросы, указывая вместо запроса его идентификатор. Кажется, Facebook применяет такой подход.
Где можно об это почитать?
К версионированию GraphQL относится интересно. От версионирования можно полностью отказаться. По сути, можно добавлять поля, не удаляя существующие, ведь данные представляют собой граф, и можно как угодно наращивать на нем узлы. Поэтому можно оставить пути для старых API и ввести новые, не помечая их номерами версий. Просто API подрос.
Ок, но мы ведь будем и удалять поля? Как клиенты об этом узнают?
GraphQL позволяет получить все необходимые данные за один запрос к серверу.Не всегда хорошо грузить одним запросом не связанные между собой данные. Во-первых — размер. Придется пользователю подождать и смотреть на пустой экран, пока не загрузятся данные.
Покойся с миром, REST. Долгих лет жизни GraphQL