А запросы можно собирать как то так «GraphQL request JSON body builder»

Тг не даёт вставлять зашкварный код с апострофами😂

В руководстве var query опять не годится: только значения полей для вставки.
А мне надо всё, вплоть до имён полей на выдачу
Про бодибилдера покурю завтра

Importing graphQL files

?

Посмотрите код gql, они пишут вот что на
GraphQL strings are the right way to write queries in your code, because they can be statically analyzed using tools like eslint-plugin-graphql. However, strings are inconvenient to manipulate, if you are trying to do things like add extra fields, merge multiple queries together, or other interesting stuff.

Вот это ближе, обсуждают ... https://github.com/graphql/graphql-js/issues/958

Всем привет
Реакт и вообще фронт только начал изучать для своих потребностей (бекендер до костей)
Слышал что-то такое, что на основе схемы полученной можно кодогенерить модели
Имеется в виду обычные классы с данными, которые уже потом используешь? Или как вообще это работает и зачем? Еще что-то слышал про валидацию схемы, чтобы на этапе билда эрор выбросило и не залилось дальше, но пока что хз

В общем, буду рад ссылкам или кратким обьяснениям

если кратко: на основе схемы и твоих кверей/мутаций кодогенератор генерит просто интерфейсы для инпутов/аутпутов (возвращаемых структур кверей/мутаций)

насчет валидации на этапе сборки могу сказать только за relay, да, он проверяет, что все квери мутации на клиенте валидны.
но, имхо, если у тебя есть типизация и нагенегереные интерфейсы, то это лишнее (главное, не забывать генерить актуальные)

Здравствуйте помогите пожалуйста на ингалятор для дочки добавить,не хватает 400 рублей люди помогли не много  от всего сердца прошу вас🙏🙏🙏🙏

Всем привет! Кто нибудь знает почему в graphql есть изначально эта проблема с n+1 запросов. И одно из решение этой проблемы было реализовано в рамках не самой технологии, а отдельной библиотекой, что скорей всего говорит о том, что для них это не проблема?

Потому что запросы к базе изначально атомарные

Хорошо поставленный вопрос и содержит уже сам в себе ответ.

В реализации самой спецификации GraphQL нет проблемы N+1. Графкуэль берет и выполняет запрос который прислал клиент. Проблема N+1 возникает непосредственно в вашем коде резолверов. В коде который вы написали сами. Если чутка “умнее” написать свой код, например с помощью DataLoader’а, то проблема решается.

Описание проблемы N+1: эта проблема возникает, когда вы запрашиваете Список элементов и к каждому элементу этого списка запрашиваете связные ресурсы. В графкуэль-запросе попросили 100 статей, и к каждой статье запросили данные автора.

Чтобы выполнить такой запрос клиента, необходимо (вариант ИЗИ):
- получить 100 статей из базы (1 запрос в БД)
- из каждой статьи взять id автора
- сделать отдельный запрос на получение данных автора по полученному id шагом выше (N запросов в БД)

Как такая проблема решается с DataLoader’ом (вариант НОРМ)
- получить 100 статей из базы (1 запрос в БД)
- из каждой статьи взять id автора
- положили id автора в DataLoader, который возвращает promise (N операций отложи ID)
- на следующий тик eventLoop’а выполнить один запрос findMany (вместо findById) по всем собранным id-шникам авторов (1 запрос в БД)
- полученных авторов отдать в DataLoader в правильном порядке, которые разрезолвит промисы на 3-ем шаге.

Как решается проблема по другому без DataLoader (вариант ХАРД)
- Вы получили запрос от клиента, и можете в резолвере на первом (верхнем) уровне получить из 4-го аргумента info AST-дерово запроса. Согласно этого AST’a сразу сделать большой запрос с JOIN’ами в базу, и полченные данные трансформировать в форму которую запросил клиент. Т.е. у вас резолверы только на верхнем уровне. По такому пути, Hasura работает.

——

Как же мы незаметно попадаем на проблему N+1?
- 1) Решили описать тип Post
- 2) Потом описали тип Author
- 3) Описываем связь 1 к 1 - добавляем поле Post.author и в нем просто по authorId дергаем запись автора из базы через findById.
…некоторое время спустя…
- 4) А давай-ка прикртим в Query.postMany поле, которое будет возвращать список Post.
…бац, и у вас незаметно появилась проблема N+1…

На шаге 4 вы ничего страшного не сделали, просто запросили список статей. Корень проблемы в шаге 3 - когда вы его реализовывали, вы даже и не думали что создавая такую простую связь по id через findById, она может быть использована как то “неоптимально”. А именно – будет запрошана кучу раз в одном запросе от клиента.

Итог прост: если вы “связываете” между собой два типа (Post и Author), то старайтесь сделать резолвер подготовленным к множественному вызову в рамках одного запроса. например как написано здесь: https://github.com/nodkz/conf-talks/tree/master/articles/graphql/dataloader

——

Ах, да. Проблема N+1 также существует и с REST API, просто она менее очевидна, но смысл тот же. В тупую дернули список статей, а потом дергаем описание авторов по одному (нагрузка на бэк такая же как и с GraphQL). Как решаете эту проблему с REST API:
- новая агрегационная ручка (похоже на вариант ХАРД выше)
- на клиенте собираем список авторов в какой-нить масивчик, а потом через метод findMany дергаем всех за один запрос (похоже на вариант НОРМ выше)
- нифига не делаем, бэкендеры там все кэшируют (похоже на вариант ИЗИ выше)

а может просто использовать графовую БД?)

Спасибо большое, очень развёрнутый и понятный ответ.

Как раз у себя реализовал через один запрос, парсю аст

Отлично. Но хочу дополнить, что проблема N+1  была и до GraphQL, это понятие хорошо известно в мире баз данных. Благодаря более удачным решениям в коде, можно её нивелировать.

У Павла Черторогова, замечательные примеры и разбор работы с dataloader, огонь.

Нужно иметь титул графа)

Раскурил ветку...
Спасибо, было познавательно но печально:
Ответ на вопрос не найден, общие впечатления от js мира с каждым днём всё хуже. Попробую сделать на .net blazor

Привет! подскажите как описать скалярний тип параметра инпута?
мне нужно чтобы это была одна из двух строк - "full" или "partial"
ну или подскажите как правильно загуглить)