Ограничение сложности запросов GraphQL || Охэхэнный бекенд

[@hhtech]

Внутри: 00:00 Интро 00:20 Вступление 00:57 Коротко про Talantix 01:38 "Сложна" или сложно? 03:22 Ходим мы по графу 04:25 Запрашиваем кандидатов с откликами 05:07 Так сложно или нет? 06:19 Ставим себе требования 08:21 Ищем готовые решения 08:59 MaxQueryComplexityInstrumentation 10:13 ComplexityAnalysisInstrumentation 11:49 Пилим свою функцию сложности 13:24 Вернемся к нашим кандидатам 15:00 Запускаем разные запросы 15:47 А почему бы не сделать идеально? 16:08 Все не так просто 16:37 Что же мы узнали? 17:30 Заключение

[@wydiwys]

Видео понравилось, но т.к. упомянули микросервисы задам вопрос: а между собой у вас микросервисы общаются каким образом? Тоже GraphQL? Или там более привычный REST? Или может что-то еще? Если про это уже был ролик - буду благодарен за ссылку)

[@genromgsu]

Конкретно ролика как между собой у нас общаются микросервисы не припомню (именно про REST).. Но там REST) GraphQL мы ввели достаточно по конкретным причинам, которые рассказываем в первом видео kzbin.info/www/bejne/oaKkYmqfrKasp9k поэтому это наиболее болело в общении фронта и бэка

[@wydiwys]

@@genromgsu Благодарю, спасибо) Буду ждать следующих роликов) Может надумаете про межсервисное взаимодействие рассказать) Если вдруг надумаете - сразу вопрос который интересен лично мне(ну а вдруг) - как решается проблема запросов(дублирования запросов) между сервисами, когда сервис А может обратиться в сервис Б, который обратится в сервис С, который даст ответ и сервис А потом уже самостоятельно сходит в сервис С за той же самой информацией которую получал сервис Б. По другим причинам естественно. Но кажется что это вполне возможный сценарий, и по идее такие вещи хочется видеть и как-то помечать, потому что место явно требует оптимизацию в том или ином виде... Надеюсь понятно отписал)