R
пацаны у меня есть отношение manytomany как мне одним ифом проверить что один обьект связан с другим?
Size: a a a
2019 September 06
V💊
пока gRPC не принято пихать, но уже можно и это стабильно
ну пока на js фронте топ это gql все же, слишком много плюшек там
SB
пацаны у меня есть отношение manytomany как мне одним ифом проверить что один обьект связан с другим?
Обратись к связующей таблице с фильтром
V💊
но не разбивать на микросервисы всё равно не получится если команда большая, люди начнут мешаться друг другу
в случае если есть микросервисы и gateway разросся до монолитного большого адаптера, большие команды же тоже будут мешать друг другу ;(
AO
ну пока на js фронте топ это gql все же, слишком много плюшек там
GraphQL - это возможность лишний раз не писать бекендеру просьбу "плиз, сделай мне API", вот основная фишка
AO
из-за этого уменьшается ttm
AO
фичи релизятся быстрее
AO
это отражается на KPI команды
V💊
GraphQL - это возможность лишний раз не писать бекендеру просьбу "плиз, сделай мне API", вот основная фишка
а кроме этого это возможность удобно собирать запрос в SPA, кгда компонент передает навех "хочу адрес аватара и ник", родитель пердает наверх "хочу адрес аватара, ник и тело комментария" и т.д. а на входе получаем красивый запрос один. как такую штуку собрать с каким-нибудь axios я даже придумтаь пока не смог ;9 а в gql это искарпки ;(
AO
нагрузка выше, запросы более дорогие и менее оптимальные? ну, да, возможно, но это плата за ttm
AO
это тот же плюс - оптимизация time to market'а
AO
дешевле выкатить фичу пораньше, но посильнее нагрузить железо, а потом уже дальше это может быть как-нибудь отрефакторено если будет потребность/свободные люди без дела
AO
мб появится какой-нибудь отдельный метод, который собирает это и работает быстрее и тогда будет использоваться он
V💊
нагрузка выше, запросы более дорогие и менее оптимальные? ну, да, возможно, но это плата за ttm
вот кстати с менее оптимальными запросами рест и гкл могут поспорить у кого хуже, и что-то мне подсказывает тот же рест после пары лет будет ужасен в плане скорости и появится необходимость пилить
v2 и т.д. потому что фонтраз попросил добавить поле, два, три, и вот эндпоинт разросся до адских размеров и уже может не укладываться в таймаут ;( (реальный кейс на прошлой работе) ;(AO
вот кстати с менее оптимальными запросами рест и гкл могут поспорить у кого хуже, и что-то мне подсказывает тот же рест после пары лет будет ужасен в плане скорости и появится необходимость пилить
v2 и т.д. потому что фонтраз попросил добавить поле, два, три, и вот эндпоинт разросся до адских размеров и уже может не укладываться в таймаут ;( (реальный кейс на прошлой работе) ;(ну, тут суть в том, что зная, какой будет запрос, можно оптимизировать его работу)
AO
а GraphQL - это универсальный способ спросить что угодно, плата за универсальность - большая медлительность
AO
сама Django (основной её плюс) - это как раз оптимальный ttm
V💊
сама Django (основной её плюс) - это как раз оптимальный ttm
ну потому её и выбирают в стартапы)
AO
то есть причины любить Django и GraphQL похожи - это желание получить более оптимальный ttm