Roman
то, что на первый взгляд может выглядеть очень безобидно, на деле выльется в 17 джойнов
Vladislav
Классический SQL тоже так проектировали. Потом оказалось, что некоторые запросы могут поставить базу в известную позицию. При этом не только сами будут выполняться медленно, так ещё и притормозят все остальные.
Я так как-то ебнул сервак оракловской бд одним запросом. Ещё порождал зомби сессии, получал ошибки с текстом «пишите в наш саппорт»
Диёр
то, что на первый взгляд может выглядеть очень безобидно, на деле выльется в 17 джойнов
так ты заранее знаешь что по этому полю сложный запрос будет
Roman
Откуда фронтендер знает, что по этому полю у нас будет тяжелый запрос?
Dmitry
откуда?
я тоже не пойму :c
писать какой-то валидатор, который определяет сложность запроса? как это так
Roman
я тоже не пойму :c
писать какой-то валидатор, который определяет сложность запроса? как это так
ну типа нажал кнопку "скажи сложность" и он говорит: "че-та сложна". Вот тебе и валидатор)
Диёр
ну да
Диёр
тебе запрос приходит и ты на бэкенде считаешь по полям
Диёр
по аргументам
Диёр
смотришь нагруженность сервисов
Roman
отлично. Т.е. теперь мне нужно в коде дублировать схему базы?
Roman
с индексами и прочим говном?
Roman
И делать это динамически?
Vladislav
АНГЛИЧАНЕ ЧТО-ТО ПОНИМАЮТ
Бахнул певка - здоров как бык. А ещё лучше после певка подраться, физическая активность организм укрепляет
Dmitry
ну типа нажал кнопку "скажи сложность" и он говорит: "че-та сложна". Вот тебе и валидатор)
https://kazanexpress.hb.bizmrg.com/blsi4v2sr16rrsukqoig/original.jpg
Диёр
и почему дублировать
Диёр
просто комлпексити на поля вешаешь
Диёр
джойн другой таблицы у нас оформлялся как подсущность
Диёр
и без этой вложенности джойна нет
Диёр
на каждую вложенность ^2 комплексити
Roman
так у тебя комплексити для одного поля одной сущности разное, в зависимости от того, откуда и кто делает запрос
Roman
комплексити же не статичная
Диёр
так у тебя комплексити для одного поля одной сущности разное, в зависимости от того, откуда и кто делает запрос
как оно зависит от того, кто делает запрос
Диёр
и откуда
Диёр
и как блять я тогда повешу комплексити на поле-то?
ну есть у тебя схема такая
{
a
b
c
}
вот ты на a вешаешь 1, на b вешаешь 2 и на c вешаешь 3
Диёр
и говоришь что если комплексити больше 5 иди курить
Диёр
или
{
a
b
c {
d
e
}
}
Диёр
и говоришь что а 1 b 2 и если есть c, то весь остальной комплексити условно ^2
Диёр
или
{
a (limit: 1000)
b
c
}
и говоришь что за каждый лимит по a ты туда плюсуешь +1
Диёр
ну и всё такое
Roman
Диёр
это graphql схема
Диёр
a b c это поля схемы
Диёр
ну вообще в корне схемы обычно поля query mutation subscription, но пусть пока будет так
Roman
ну я вот пока не понимаю, что эта graphql схема мне должна сказать. Что это за поля — это сущность какая-то или параметры запроса или что вообще?
Диёр
a b c это поля
Roman
поля чего?
Диёр
вот где limit 1000 это аргумент по полю a
Roman
ты троллишь что ли?
Диёр
нет
Roman
что такое графкл схема тогда?
Диёр
набор полей
Roman
спасибо. На этом у меня все.
Диёр
ну вот откопал один из запросиков
Диёр
query packages {
packages {
id
game {
id
title
}
count
price
is_active
most_popular
top_pack
}
}
Диёр
как раз простой
Диёр
это запрос который прилетает в схему
Диёр
и просто из схемы все эти поля резолвятся
Диёр
допустим packages это запрос в базу и по дефолту 100 записей
Диёр
вот все поля кроме game это поля в таблице
Диёр
game это джойн соответственно
Диёр
за каждым полем стоит резолвер, куда можно аргументы прокинуть
Nikolay
Люблю андроидовские эксепшоны:
mediaRecorder.start();
RuntimeException: start failed.
at android.media.MediaRecorder.start(Native Method)
Roman
game это джойн соответственно
ок. А что делать, если game связана с текущей таблицей через 5 джойнов?
Ayrat
Диёр
ок. А что делать, если game связана с текущей таблицей через 5 джойнов?
вешаешь на game комплексити который ты считаешь подходящим для 5 джойнов
Vladislav
Диёр
у packages комплексити резолвишь как
лимит по-умолчанию 100
гейм это *5 например
Vladimir
а потом оказыватся что иногда надо делать 5 джойнов, а иногда не надо в зависимости от остальных параметров
Диёр
ну так и считай их
Anatoly
Мило. Мне кажется, инженерная сложность грамотной валидации сложности запроса существенно выше сложности решения, где есть разные эндпоинты с урезанными проекциями
инженерная сложность предоставления иерархических запросов поверх реста невообразимо выше, чем аналогично в графкуэле.
Anatoly
и когда у тебя основной драйвер апи - это main FE, поток ченджей на апи гигантский и graphql снимает кучу проблем
Anatoly
если появляется какой-то сложный и медленный запрос, он виден в статистике, выносится в отдельную функцию и оптимизируется как надо
Диёр
ты же хочешь статически в схеме эту пятерку прописать
так это от тебя зависит как будешь делать
Диёр
просто когда комплексити считаться по полю будет у этого поля вызовется резолвер его комплексити
Диёр
что туда напишешь так и будет
Диёр
хоть юних таймстемп туда пихай
Vladimir
т.е. каждый раз когда я добавляю логику на джойны, мне нужно синхронно добавить логику на резолв комплексити и поддерживать их всегда в актуальном состоянии
Anatoly
вы пытаетесь решить задачу полностью, это не нужно
Диёр
+
Диёр
ну и в графкл можно ещё deferred fields юзать для полей которые терпят по времени