Comments 22
А как фронт/мобилку интегрируете с GQL? Руками или есть автогенерация?
Да, кодогенерация один из основных подходов в случае с GraphQL. На фронте есть GraphQL Codegen. Он использует т.н. Introspection Query (запрос к GraphQL для получения документации)
У себя на канале я делал видео и по REST и GraphQL. Автогенерацию тоже разбирал.
Думаю, стоило рассказать о то, что GraphQL зачастую используют в качестве альтернативы API Gateway (наверное даже чаще, чем в контексте единого сервиса), и о том как он позволяет один запрос перенаправить сразу на кучу сервисов. Например в контексте книг: сами книги приходят с сервиса поиска, а комментарии, соответственно, с микросервиса комментариев. И именно под такое применение заточены большинство бекенд-фреймворков GraphQL (тот же Apollo, или амазоновский AppSync)
Или, например, про то что GraphQL - самодокументируемый с использованием Introspection, и о том что это тоже полезная фича при распределенной разработке и помогает взаимодействию команды
По фронту буду в ближайшее время записывать. Как раз учту этот вопрос, и покажу как со стороны бэка, так и фронта.
GraphQL конечно интересная штука.
Но все его плюсы, мне кажется очень сильно преувеличены.
- Для REST API тоже можно сделать возможность указывать какие поля нужно вернуть.
- В GraphQL присутствует проблема n+1 запрос. Если при REST API на беке можно было написать запрос с JOIN. И это будет один запрос к БД, то при GraphQL это будет множество запросов.
Тема «проблема n+1» решённая :) по крайней мере в библиотеке со стороны бэка «Hot Chocolate».
Отвечая про join. Почему это будет несколько запросов? Будет именно join. Так же в видео это показывал.
У меня есть видео GraphQL где я сравниваю производительность REST и GraphQL. Я думал что будет равенство, а получилось что GraphQL быстрее.
REST хорошая вещь, но уже реально устаревшая, многие функции приходится решать внешними «расширителями», например даже swagger (open API) это расширение, и много мелких проблем, когда при любом чихе мы делаем новую работу на бэке, ну или оставляем не оптимальные запросы, поверьте знаю о чём говорю. На канале по REST 19 видео, а GraphQL пока 8.
Меньше кода? Как это работает? В вашей экосистеме есть батарейки, которые автоматически генерируют запросы в базу, а для rest таких нет? В экосистеме питона, например, для graphql таблеток нет, и какая тогда бэку разница, для какого протокола запросы в базу составлять.
Честно не знаю как там на пайтоне, но на C# .net Core и hot chocolate можно меньше кода писать. У вас в запросе вы можете писать аналог SQL WHERE, где можете делать условия, эти условия транслируются потом в запрос SQL. На бэке мы имеем не так много функций, а фронт может вызвать функцию с условиями как вашими, так и универсальными, я этот момент рассматривал. На фронте часто приходится по требованию заказчика переигрывать какие-то моменты, и тогда, не нужно дорабатывать бэк.
Кроме того группировка запросов увеличивает скорость работы, на мобилках меньше батарейку ест. Да можно сделать оптимальные REST запросы, но в GraphQL это делается чуть ли не автоматом, а на REST вам каждый раз нужно все руками делать, и это может занимать много человекочасов. Я думал что REST при одинаковых условий будет чуть быстрее, но по моим тестам, наоборот GraphQL оказался быстрее, с результатами можете ознакомиться.
Сколько не сталкивался с gql, столько раз приходил к тому, что "плоское - лучше вложенного". Ибо, вместо написания запросов к бд со стороны бекенда, Вы – отпускаете эту задачу к клиенту, который не обязан вдаватся в оптимизацию и чтение плана запроса, что делает сложным и сверх вариативным набор тест-кейсов для бека и соответственно позволяет декларировать бизнес-логику со стороны клиента.
Это может весьма неплохо работать при агрегации разных API и использовании одного и того же стека со стороны бекенда и клиента, а также при относительно простых API но ИМХО неизбежно ведет к усложнению логики приложения.
Многи библиотеки работающие с REST сегодня предоставят вам автогенерацию эндпоинтов и OIS 3.0 документации. И чаще у них предусмотрены инструменты для ограничения количества полей, связей и набора фильтров.
Для REST API тоже можно сделать возможность указывать какие поля нужно вернуть.
Указание полей ожидаемых в результате крайне маленькая часть GraphQL . Поля указать можно в REST, но поля вложенных объектов с аргументами указать будет уже сложнее и распарсить в REST особенно если они меняются. Как говориться "можно, а смысл"? В GraphQL сам запрос древовидный, отличается по идеологии от REST
Если при REST API на беке можно было написать запрос с JOIN
Все верно и в случае с GraphQL - не имеет разницы - можно написать такой же запрос чтобы вернуть такие же данные за один раз. Если нужны связанные (вложенные) данные которые не вернуть одним запросом - делать несколько запросов к БД придется и в REST и в GraphQL.
Если вы о Data Shaping, то в контексте .NET мы уменьшим трафик по сети, но шейпинг неизбежно будет на основе рефлексии, dynamic, expando object или схожих механизмов, что в свою очередь может ударить и по перфу. Если я не прав и вы можете подсказать эффективные механизмы Data Shaping в .NET буду признателен.
Я разработчик на .net core ( раньше работал много лет и со старым . net framework ). Все примеры как раз на . net5 (на 6 переведу в ближайшее время) С поддержкой все очень хорошо, есть библиотека hot chocolate, которая встраивается в pipeline, она полностью бесплатная очень мощная, и с открытым кодом. Сам работаю последние года с entity framework, который и используется на бэке для работы с данными, а уже GraphQL через него, великолепно работает. Функциональности выше крыши, тут скорее нужно посмотреть что есть, что бы свои костыли не изобретать, многие вещи делаются буквально пару строк кода. Каких-то сложностей нет, всё что с моего взгляда чуть сложнее рассказываю и еще несколько материалов точно будет.
Rest и GraphQL - это всё же две крайности. Rest - прям вот вообще просто и банально. GraphQL - хороший, со странностями, и всё ещё не rpc и не sql.
Существует ещё одна альтернатива - json:api. У вас на канале про него не увидел обзоров, хотя он так же позволяет конструировать ответы, и к тому же достаточно привычен.
Я еще пользовался OData, про него тоже расскажу. Но всё-таки GraphQL гораздо удобнее.
Даже подписки вы можете делать оптимизированными и говорить что из полей вы хотите получать. + один стандарт определяет всё что нужно, а не несколько разных.
Я понимаю что на вкус и цвет у каждого свои предподчтения, поэтому нет плохих стандартов. Это как в анекдоте: было 10 стандартов, мы придумаем супер стандарт который в 1000 раз лучше, и так появляется 11-й стандарт, потом 12-й.
Поставили значит на бэкенд GraphQL. Так сильно при разработке на Android я ещё не страдал (возможно потому, что мы не юзали их либу, а формировали запросы длинющей строкой). Самое неудобное - это то, что нужно на каждый запрос вводить, какие поля объекта нужно получать, и в каком порядке, что делает запросы просто огромными. Можете зайти в playground и убедиться в этом. А в остальном всё ок
Много букв, мало смысла.
GraphQl не замена REST api и не его альтернатива, наиболее корректное сравнение с oData.
И Вот с этой точки зрения, ответте сами себе на вопрос, что будет если в базе много связаннных сущностей и с клиента пришол запрос глубокой вложенности? Как вы в этом мире будете обеспечивать поодержку SLA по нагрузке на бд и на время ответа сервера?
GraphQl прекрасная альтернатива для построения BFF. Да бесспорно, тут он однозначно удобен. Но как говориться и тут не без подводных камнений.
Если сервис не умеет делать выборку по запрашиваемым полям или не умеет делать пагинацию из корбки. Какого поведения вы ждёте от GraphQl? Чуда не будет, будут материализованы объекты полностью, пост обработка на стороне сервиса и формирования результата по запрошенному формату.
GraphQl как и любая технология имеет свою область применения и свои, местами весьма сущесьвенные минусы. Палить из пушки не всегда выход если вы не умеете правильно строить архитектуру БД или проектировать красивое простое апи.
На своих проектах мы всегда исходим из подхода что проще выполнить два легко весных запроса к разным апи и обработать их на фронте, чем городить один супер ответ и создавать точку отказа в API.
Это вводная статья, конкретика будет в следующих статьях (уже есть в видео)
GraphQL легко заменяет REST
Вложенность легко ограничивается. Была такая форма атаки, когда спамили гигантскими вложенными запросами. Это давно решено
Тем чем я пользуюсь. Умеет делать пагинацию из коробки причём как минимум 3х видов: курсоры, сдвиги, и вы можете вообще свою реализацию подкинуть.
GraphQL очень применим для связи фронта и бэка. А вот для связи микросервисов между собой, я предпочитаю шину.
Один суперответ(хотя прям такое редко случается), больше сгруппированные запросы, вам помогают оптимизировать запрос в БД, а так же ответ сервера, почитайте материалы Facebook где они показывают, насколько сократилось потребление энергии в мобильном устройстве, а это огромный + в наше время.
GraphQL позволяет отказаться от REDUX (лично я его не долюбливаю)
В общем вижу плюсы, а минусов не вижу. Есть моменты котрые я бы хотел еще более развить в GraphQL, например выполнять в одном запросе и чтения и записи.
GraphQL: как сделать бэкенд приложения экономнее и быстрее