LINUX.ORG.RU
ФорумTalks

GraphQL - плохой дизайн?

 , ,


0

1

Объясните мне зачем нужен сабж. Единственное преимущество, которая я вижу, что клиенту не надо менять дикак бэкенд, чтобы запросить другие данные.

Но - допустим, он захочет отфильтровать/сортировать по какому-то полю, для которого нет индекса в базе данных - это будет очень медленно и потенциально так можно создать огромную нагрузку на бэк.

Всякие join`ы тоже лучше как-то контролировать. Например, иногда лучше сделать отдельный запрос.

То что можно несколько запросов в один объеденить тоже странная практика. Во-первых по-идее через http/2 и т.п. и так можно делать несколько запросов через одно соединение, хотя я не думаю вообще что количество соединений - проблема. Во-вторых, когда запросы идут отдельно их гораздно удобней кешировать, делать инвалидацию кэша и т.п.

Ну и выхлоп его со всеми этими edges избыточных имхо и не слишком человеко-читаемый.

★★★★★

возможность запрашивать только часть данных, только то что нужно.

про индексы и джойны немного не в тему, у тебя вообще на беке могут быть 25 редисов из которых все собирается а повесить базу запросом можно и без graphQL

http2 не рвет коннект но запросы на беке обрабатываются отдельно друг от друга.

TDrive ★★★★★
()

кешировать кстати нифига не удобно если данные для разных запросов пересекаются, консистентность можно потерять.

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

запросы на беке обрабатываются отдельно друг от друга.

Это ничего не меняет. Запросы к бд всё равно будет отедьльные.

pawnhearts ★★★★★
() автор топика
Ответ на: комментарий от TDrive

Всмыслне пересекаются? Вообще инвалидировать кэш можно автоматически в т.ч. если orm использовать. В больинстве случаев это работает. Типа всяких https://django-cachalot.readthedocs.io/en/latest/

pawnhearts ★★★★★
() автор топика

Объясните мне зачем нужен сабж

Декларативный подход к описанию API.

vvn_black ★★★★★
()

захочет отфильтровать/сортировать по какому-то полю, для которого нет индекса в базе данных

Кто ж ему даст?

no-such-file ★★★★★
()
Ответ на: комментарий от pawnhearts

или не будут, ты почему то связываешь протокол апи с реализацией бека но этой связи нету

TDrive ★★★★★
()
Ответ на: комментарий от pawnhearts

так это кеширование на уровне орм, а я про запросы к апи говорил, вот если апи для разных запросов возвращает пересекающиеся данные то проще юзать кеширование в орм, как вариант.

TDrive ★★★★★
()

Сабж, очевидно же, - для того, чтобы не таскать туда-сюда кучу запросов-ответов, а уместить все в одну атомарную единицу. А что касается отсутствующих индексов и т.д. - ну это уже зависит от бэковой реализации, где эти графкульные запросы парсятся, какие поля там объявлены, какие поля наллбл и по дефолту, какие DTOшки дёргаются и т.д.

megajack
()

не слишком человеко-читаемый.

А он на это и не расчитан. JSON тоже не читаем, но шото API на YAML я не видел. А стоило бы…

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от cobold

А смысл? Yml это формат удобный для человеков. А API это программный интерфейс по определению

Ну я типа об этом же. Хотя я вот попытался найти сравнение JSON и YAML в плане плотности информации, и что-то ничего не находится путного. Но YAML должен быть примерно на том же уровне, а значит нет ни одной причины чтобы не использовать его для API. Читаемость – приятный бонус.

hateyoufeel ★★★★★
()
Ответ на: комментарий от cobold

У json есть хотя бы несколько типов данных. У yaml есть только строка и массив

В YAML есть те же типы. В любом случае, если ты не валидируешь данные при парсинге, ты баклажан. А если валидируешь, то эти типы для индивидуальных значений особо не нужны.

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)

первое - схема для фронта. Шлягер не панацея, его надо все время поддерживать. SDL-first GraphQL с генератором этот вопрос решает. Не, шлягер-схему тоже можно натянуть, но родной кодген не фонтан, а для GraphQL в большинстве случаев один фиг свое писать, снимает лишние вопросы

второе - сколько данных отдавать. Для мобильных это важно. Да и вообще пихать 3 метра жсона чтоб отдать id это жесть.

он захочет отфильтровать/сортировать по какому-то полю, для которого нет индекса в базе данных

с чего это он захочет? Отфильтрует так как сказали, это к бэку а не GraphQL

Ну и выхлоп его со всеми этими edges избыточных имхо и не слишком человеко-читаемый

с одной стороны да. С другой я как раз в пятницу это отдал фронтам в разработку и они прибежали типа «ой хотим еще вот по этому полю курсор». И внезапно эта схема оказалась вполне удобной.

Плюс все сильно зависит от того как ты эту штуку юзаешь. Я пробовал графен, было больно. Сейчас для пистона тартифлет со сраной тонной кастомных генераторов и всякими датаклассами чисто под наш проект - и вот теперь действительно реально удобно.

p.s. я не фанат graphql. Меня скажем бесит отсутствие input union, буквально на той неделе пукан рвал от ненависти. Плюс если фронт криво написал запрос то бек начинает срать жсоном хуже чем от реста. Ну и фрагменты и сабклассы выглядят вырвиглазно. Но если сделать грамотно и натурально «по инструкции» - в целом это сильно облегчает работу с фронтом

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 3)

кстати что еще из плюсов для бэка вспомнил: директивы. На той неделе делал дополнительную валидацию. 10 строк кода, 5 минут пихания собак в схему - усе работает, бомба же. На шлягере так сделать можно, но не для всего, фигню сложнее регулярки протащить не так просто

upcFrost ★★★★★
()

Во-вторых, когда запросы идут отдельно их гораздно удобней кешировать, делать инвалидацию кэша и т.п

клиенты часто умеют сами обновлять кеш если мутация возвращает объект. Тот же Аполло это из коробки делает, прикрутили пару недель назад

upcFrost ★★★★★
()
Ответ на: комментарий от cobold

У json есть хотя бы несколько типов данных. У yaml есть только строка и массив

YAML это надстройка над JSON) любой валидный JSON валиден для парсера YAML

TDrive ★★★★★
()
Последнее исправление: TDrive (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

Ну я типа об этом же. Хотя я вот попытался найти сравнение JSON и YAML в плане плотности информации, и что-то ничего не находится путного. Но YAML должен быть примерно на том же уровне, а значит нет ни одной причины чтобы не использовать его для API. Читаемость – приятный бонус.

по плотности инфы скорее всего одно и то же, а вот скорость парсинга стоит потестить.

TDrive ★★★★★
()
Ответ на: комментарий от TDrive

по плотности инфы скорее всего одно и то же, а вот скорость парсинга стоит потестить.

Парсинг YAML вроде как медленее, но это потому что YAML сложнее. В отличие от JSON, в YAML есть ссылки и прочее. Но в API всё это видеть – нет уж, увольте. Я бы сократил YAML для подмножество, совпадающего по семантике с JSON, в данном случае.

hateyoufeel ★★★★★
()
Ответ на: комментарий от theNamelessOne

JSON, YAML, все это ваше говно нетипизированное. Делайте API на Dhall.

Чем это поможет?

hateyoufeel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.