по идее юзкейс для grapgql - когда схема большая и сложная. Типа как у гитхаба. И тебе, обычно, нужно только какие-то куски каких-то срезов данных.

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

Ну если приложение - это просто мордочка к базе, то да

А просто к сервису с двумя эндпоинтами нет смысла делать graphql

Ну если приложение - это просто мордочка к базе, то да

причем здесь мордочка? это ортогонально

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

и клиентов в перспективе может быть полбанка, каждый со своими хотелками

тупо роуты мы не сможем поддерживать, у нас нет команды размером с апишную

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

Будут пародировать того болтливоготчувака. Спросони подумалось что для графовых запросов нужен категорный язык с индуктивными типами и замкнутой системой конструкторов. Чтобы каждое поле отдельной стрелкой и кортежи рождались на лету только как оптимизация. Тогда можно протянуть селективность полей и по микросервисам и к запросам в базу

я вот инвестигировал инвестигировал и выинвестигировал, мне надо пилить простые шаттп сервисы и посылать данные между ними, выбор стоит между grpc, finch, graphQl

О боже ж, эт ж не сравнимые вещи

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

Вот эт точно не так)

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

Ну вот кстати я б на коммуникацию между сервисами графкуэль не тащил бы, а вот для фронта само то

Ну вот кстати я б на коммуникацию между сервисами графкуэль не тащил бы, а вот для фронта само то

Речь исключительно о фронте.

Так вот если у тебя миллион микросервисов, то графкуэль вполне может пригодиться

И сложность я бы не сказал что выше

Вот эт точно не так)

Скиньте где почитать про это

У сангрии и почитай.

Там есть хороший learn

Но у сангрии конечно есть недостатки

Но у сангрии конечно есть недостатки

тебе в политику надо

есть задатки

тебе в политику надо

А?

А?

общих слов много, а конкретики нет)

а что тебе даст эта конкретика?

вопрос, что дает мне её отсутствие

ну ок, там есть проблема с генерацией циклических схем, если юзать макросы

приходится городить

у фетчера нет флетмата, иногда было б полезно

ну и баги конечно ж )

да там схему описать это анальная боль =) а уж fetcher сделать так и вообще

да там схему описать это анальная боль =) а уж fetcher сделать так и вообще

да не сказал бы

а в целом сангрия конечно хороша

впринципе схему не так сложно описать)

несложную схему не сложно и описать

ну у нас не маленькая схема, вполне себе ок

несложную схему проще не на графеуэль сделать меньше проблем, проще саппорт

эт вкусовщина же

кто ж признается что у него схема маленькая? каждый свою схему считает самой большой =)

давайте как тот чувак с го чатика спорить еще будем, что graphql не нужен, потому что все это можно сделать через rest

ну не сказать динамика в том месте, где она не нужна приводит к сложности, которая не нужна, а она есть

нужен

но далеко не всем

о какой динамике идет речь?

кто ж признается что у него схема маленькая? каждый свою схему считает самой большой =)

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

о какой динамике идет речь?

graphql vs json - ключевое различие ж в том, что схема в графе не статическая, фактически это язык запросов с возможностью хитрых/гибких вложений

ну что значит не статическая? схема то описана)

схема данных, а не самих запросов

гибкость появляется на фронте и на бэке - выбор что как подтянуть

давайте как тот чувак с го чатика спорить еще будем, что graphql не нужен, потому что все это можно сделать через rest

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

чаю этому господину

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

вот знаешь где графкуэль крут?))) когда нужно придумывать эндпоинты виде /user/orders/ /order/user )

ну и т.д) в глубину

вот знаешь где джсон запрос крут? когда нужно придумывать эндпоинты виде /user/orders/ /order/user )

я про роуты ничего не говорил

хех, ты про json rpc?

типо того

рауты можно штамповать без большого напряжения

ну да, только в jsonrpc ты будешь париться придумывать названия методу)

даже ручками

рауты можно штамповать без большого напряжения

да конечно, ага

депендз, кто спорит

даже ручками

классический пример с отношением и что в кого должно вкладываться - не понятно

я же говорю, вкусовщина)

вот знаете, где ваши мономорфные запросы huevos? Когда нужно придумать десяток пар запросов doSomeShit -> ShitDone | ShitConfirmationRequired confirmSomeShit -> ShitDone

Просто нам нужен правильный язык запросов. И ему нужны дженерики. И по во-зможности higher kinded и прочий шлак

Просто нам нужен правильный язык запросов. И ему нужны дженерики. И по во-зможности higher kinded и прочий шлак

дык сделай свою реализацию протокола

ну да, только в jsonrpc ты будешь париться придумывать названия методу)

но зачем методы? зачем быть к ее-джавист и прибиваться к практикам дедов и не смотреть по сторонам?

но зачем методы? зачем быть к ее-джавист и прибиваться к практикам дедов и не смотреть по сторонам?

там же обязательно название метода, он диспатчит вроде по нету, не?

дык сделай свою реализацию протокола

Ок. Но мне нужно заставить три расы клиентов ей пользоваться

Ок. Но мне нужно заставить три расы клиентов ей пользоваться

зачем? можно держать кучу эндпоинтов

и тебя будут любить все)

Просто нам нужен правильный язык запросов. И ему нужны дженерики. И по во-зможности higher kinded и прочий шлак

джаваскрипт ? hkt

Генерить сваггер из суперсваггера? Идея

а зачем тебе сваггер

давно пора сделать олеггер

?

давно пора сделать олеггер

Производство мозгослизней слишком затратное, чтобы зомбировать всех фронтендеров и мобильщиков

Производство мозгослизней слишком затратное, чтобы зомбировать всех фронтендеров и мобильщиков

))))

там же обязательно название метода, он диспатчит вроде по нету, не?

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

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

а хочешь скажу, что нету шума)

прошел шум, уже как год ,а может два назад

а хочешь скажу, что нету шума)

в сторону опять уходишь (коммент про политику)

прошел шум, уже как год ,а может два назад

Ещё скажи, что scala - не пузырь

в сторону опять уходишь (коммент про политику)

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

Ещё скажи, что scala - не пузырь

здесь снова должен появится @A64m_qb0 и приложить картинку где пузырь сдувается

ах нет, не могу, я слишком молод

у других языков мало что есть противопоставить этому: for comprehension, destructuring, pattern matching, flow typing, immutability by default, data objects, null safety, get/set/POJO infrastructure generate by default и это только что навскидку, там много чего еще

у других языков мало что есть противопоставить этому: for comprehension, destructuring, pattern matching, flow typing, immutability by default, data objects, null safety, get/set/POJO infrastructure generate by default и это только что навскидку, там много чего еще

Эт вообще про что)

Представьте вас бы спросили на собеседование, «что вам больше всего нравится в котлине» чтобы ответили?

null safety

null is safe now

Ребятки

Из Аделиска никого нет?

null safety

точно, в идее регулярно npe из котлина валится)))

я так то про скалу

:D

у других языков мало что есть противопоставить этому: for comprehension, destructuring, pattern matching, flow typing, immutability by default, data objects, null safety, get/set/POJO infrastructure generate by default и это только что навскидку, там много чего еще

Есть пейпер про flow typing?