а где progo? что с ним?

мы его закрыли

@vetcher, done

thx

мы его закрыли

Хм, и правда. Даже и не заметил :)

да

сильно с ним извращаться приходится?

сильно с ним извращаться приходится?

что такое извращаться?

сильно с ним извращаться приходится?

не сильно

в рамках твоей программерской парадигмы

ну там, интерфейсами жонглировать

reflect расчехлять

ну там, интерфейсами жонглировать

нет такого. все в рамках твоего домена

а какую либу для графа используешь на сервере?

https://github.com/graph-gophers/graphql-go

спс

Ребята, по тесту https://bit.ly/gogolang Отпишитесь, пожалуйста, кто хотел получить расшифровку своих ответов с правильными вариантами, но ещё не получил.

https://github.com/graph-gophers/graphql-go

Разве не ее клеймили сегодня за низкую производительность?

Разве не ее клеймили сегодня за низкую производительность?

не, я ее предложил на замену той. называются позоже просто

graphql-go vs go-graphql - юзать надо первую

Ребята, по тесту https://bit.ly/gogolang Отпишитесь, пожалуйста, кто хотел получить расшифровку своих ответов с правильными вариантами, но ещё не получил.

Я не получил. В спаме тоже нет

Я не получил. В спаме тоже нет

Ок, пометил себе, проверю

всем привет, видел выше небольшой срач про graphql. Скажите, кто-нибудь его использовал в связке с гошкой ?

да, мы используем

сильно с ним извращаться приходится?

не особо. Главное наивно resolver'ы не имплементировать и нормальную библиотеку юзать

нормальную - это graphql-go ?

нормальную - это graphql-go ?

у нас сейчас на вооружении https://github.com/graph-gophers/graphql-go

ну да, я её и имел ввиду

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

да уж, после GQL на REST уже не тянет

да уж, после GQL на REST уже не тянет

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

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

для тривиальных задач RPC лучше, с этим никто не спорит. но любой тривиальный проект может перерасти в нетривиальный и тогда начнётся special-endpoint канитель

Мне порой кажется что в мире существует только два варианта написания апи: rest и graphql

А про JSON RPC никогда не говорят (

А как же апи богов? SOAP например!

А как же апи богов? SOAP например!

Во во!

Мне порой кажется что в мире существует только два варианта написания апи: rest и graphql

скорее RPC и GraphQL (и ещё десятки других малых стандартов)

Мне кстати из многих апи что я видел понравился апи слака

в RPC (REST etc.) ты мыслишь: "что умеет API?" в GraphQL ты мыслишь: "какие данные предоставляет API?" в GQL ты думаешь о данных, их типах и взаимосвязях (relations)

потому что QL

В REST ты думаешь "как натянуть логику на методы HTTP")

В REST ты думаешь "как натянуть логику на методы HTTP")

и если не придумал, то POST?

в рест твой сервер думает

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

не может такого быть) ресолверы реализуешь ты, а не graphql

Или же "как представить сложные структуры используя параметры формы"

и если не придумал, то POST?

Конечно

В REST ты думаешь "как натянуть логику на методы HTTP")

сначала так думаешь, а потом "зачем я в это ввязался"

не может такого быть) ресолверы реализуешь ты, а не graphql

там либка делает биндинги по именам полей в структуре, мб он об этом?

не может такого быть) ресолверы реализуешь ты, а не graphql

я частично с ним соглашусь. Написать толковые ресолверы сложнее чем тупой HTTP endpoint но когда проект растёт HTTP/REST превращается в еле-типизированный, хаотичный, непонятный и запутанный ад

не может такого быть) ресолверы реализуешь ты, а не graphql

Там и пошёл костыль, что надо выяснить запрашиваемые поля и потом отдавать только их. А фронт находил новый способ запроса, что поля пролетали мимо анализатора

там либка делает биндинги по именам полей в структуре, мб он об этом?

не помню такого. насколько помню обе либы абстрагированы от db-слоя (но как работает первая, я честно говоря уже подзабываю)

ну та на динамике, там есть defaultResolver, который как раз и мапит поля на структуру. А еще map[string]interface{} тоже отлично хавает

Там и пошёл костыль, что надо выяснить запрашиваемые поля и потом отдавать только их. А фронт находил новый способ запроса, что поля пролетали мимо анализатора

overfetching не так страшен как underfetching. бару байт выбросить хуже хем пару недодать и в конце порадить дополнительный round-trip

я частично с ним соглашусь. Написать толковые ресолверы сложнее чем тупой HTTP endpoint но когда проект растёт HTTP/REST превращается в еле-типизированный, хаотичный, непонятный и запутанный ад

все мы частично с ним согласимся, но это проблема реализации, а не спеки. Как только в rest добавим выборку по полям, сразу придется городить такие же ресолверы. Или не заморчиваться и продолжать гонять агрегаты (ну так и в graphql то же самое будет)

все мы частично с ним согласимся, но это проблема реализации, а не спеки. Как только в rest добавим выборку по полям, сразу придется городить такие же ресолверы. Или не заморчиваться и продолжать гонять агрегаты (ну так и в graphql то же самое будет)

ну да

не помню такого. насколько помню обе либы абстрагированы от db-слоя (но как работает первая, я честно говоря уже подзабываю)

Делали на пхп, через ишидо

Там и пошёл костыль, что надо выяснить запрашиваемые поля и потом отдавать только их. А фронт находил новый способ запроса, что поля пролетали мимо анализатора

проблема не прояснилась. по спеке тебе прилетает список полей, gql ресолвит их черех ресолверы, написанные тобой. Анализ проходит внутри серверной либы

ну та на динамике, там есть defaultResolver, который как раз и мапит поля на структуру. А еще map[string]interface{} тоже отлично хавает

а, ну может быть. ну надо старую либу забыть - она референсная, то есть работает, но не продакшн реди, а скорее как proof-of-concept

overfetching не так страшен как underfetching. бару байт выбросить хуже хем пару недодать и в конце порадить дополнительный round-trip

А если эти пару байт будут sensitive данными?

Например, персональными

А если эти пару байт будут sensitive данными?

и что с ними произойдёт? такое впечатление что вы считаете что те поля которые мы запросили у бд но не отдали клиенту автоматически улетают на чёрный рынок ?

а, ну может быть. ну надо старую либу забыть - она референсная, то есть работает, но не продакшн реди, а скорее как proof-of-concept

а на вторую подзабили разрабы, и че вот делать?

и что с ними произойдёт? такое впечатление что вы считаете что те поля которые мы запросили у бд но не отдали клиенту автоматически улетают на чёрный рынок ?

Я наоборот про то что лишнее отдать можно

форкаться и пилить

Я наоборот про то что лишнее отдать можно

лишнее отдать? это как?

лишнее отдать? это как?

это через дырку в либе

я частично с ним соглашусь. Написать толковые ресолверы сложнее чем тупой HTTP endpoint но когда проект растёт HTTP/REST превращается в еле-типизированный, хаотичный, непонятный и запутанный ад

swagger тоже не спасает? он умеет типы отдавать, если сервер конечно потдерживает типы. В случае с явой так вообще полная автоматизация, пишешь эндпоинты, и у тебя генериться клиент. Я кроме JS ничего не использовал, но вроде есть разные целевые языки.

ERROR: S client not available

это через дырку в либе

ну ёмоё, дескридитировать GQL по багу в какой-то библиотеке...

а на вторую подзабили разрабы, и че вот делать?

вариантов нет. первая убогая. На вторую подзабили, видимо потому что нет достаточно мотивирующего фидбека. Можно ждать третью либу, но кажется придется довольствоваться второй

вариантов нет. первая убогая. На вторую подзабили, видимо потому что нет достаточно мотивирующего фидбека. Можно ждать третью либу, но кажется придется довольствоваться второй

или просто перейти на Ru... но нет ?

вариантов нет. первая убогая. На вторую подзабили, видимо потому что нет достаточно мотивирующего фидбека. Можно ждать третью либу, но кажется придется довольствоваться второй

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

или просто перейти на Ru... но нет ?

а есть там что-то хорошее?

в смысле имплементация интересная?

swagger тоже не спасает? он умеет типы отдавать, если сервер конечно потдерживает типы. В случае с явой так вообще полная автоматизация, пишешь эндпоинты, и у тебя генериться клиент. Я кроме JS ничего не использовал, но вроде есть разные целевые языки.

свагер может и "спасает" в плане типизации (хоть и не совсем), но от болезней RPC он никак не спасает. вообще. Underfetching в RPC решается только добавлением новых endpoint'ов а это некрасиво, грязно и т.д.

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

есть feature requests в ишьюсах

а есть там что-то хорошее?

не знаю честно говоря хорошее или нет.. но много говорят про juniper https://github.com/graphql-rust/juniper

во первых конечно реализовать subscriptions

есть feature requests в ишьюсах

Не, я о том, что стоило бы новой либы, а не доработки этой

Не, я о том, что стоило бы новой либы, а не доработки этой

а, ну можно форкнуть. я имел в виду в целом третью, можно не с нуля)

во первых конечно реализовать subscriptions

мы кстати обратную связь решили с помощью webwire, пускай не совсем GraphQL-idiomatic но работает считай делаешь mutation запрос с query строкой и она тебя подписывает на named-webwire-signal, который ты потом ловишь

не знаю честно говоря хорошее или нет.. но много говорят про juniper https://github.com/graphql-rust/juniper

слушай, ну вот для меня ключевая фича - это поддержка родной схемы, без необходимости ее описывать в терминах языка. https://github.com/graph-gophers/graphql-go/blob/master/example/starwars/starwars.go#L15

свагер может и "спасает" в плане типизации (хоть и не совсем), но от болезней RPC он никак не спасает. вообще. Underfetching в RPC решается только добавлением новых endpoint'ов а это некрасиво, грязно и т.д.

Но вообще никто не запрещает отдавать на одном энпоинте разный набор полей. Мы так часто делали в зависимости от привелегий.

слушай, ну вот для меня ключевая фича - это поддержка родной схемы, без необходимости ее описывать в терминах языка. https://github.com/graph-gophers/graphql-go/blob/master/example/starwars/starwars.go#L15

не совсем понял что ты этим хотел сказать

Но вообще никто не запрещает отдавать на одном энпоинте разный набор полей. Мы так часто делали в зависимости от привелегий.

вы не поняли. Дело не в overfetching'е (отдать поля, которые не нужны клиенту) а в underfetching'е (недодать данных)

не совсем понял что ты этим хотел сказать

я хотел сказать что не вижу в растовой либе поддержки этого

Но вообще никто не запрещает отдавать на одном энпоинте разный набор полей. Мы так часто делали в зависимости от привелегий.

проблема со специализированными endpoint'ами в tight-coupling'е. Т.е. как только меняются требования клиента (например дизайн изменили, теперь на дашборде оборажается X,Y,Z а не как прежде Y,M,C,A) - нужно переписывать backend для оптимизации, и так постоянно... а что если у вас не один клиент ещё в добавок? RPC очень быстро может превратиться в maintenance катастрофу. Из-за этого и появились раньше такие вещи как SQL, которые позволили решать разные проблемы не переписывая имплементацию бд.. с GQL теперь происходит подобное но уже на уровне API и в виде графа

я хотел сказать что не вижу в растовой либе поддержки этого

я честно не в курсе как там у juniper и rust.. меня больше Go интересует. Go + GQL по сути очень годная пара

проблема со специализированными endpoint'ами в tight-coupling'е. Т.е. как только меняются требования клиента (например дизайн изменили, теперь на дашборде оборажается X,Y,Z а не как прежде Y,M,C,A) - нужно переписывать backend для оптимизации, и так постоянно... а что если у вас не один клиент ещё в добавок? RPC очень быстро может превратиться в maintenance катастрофу. Из-за этого и появились раньше такие вещи как SQL, которые позволили решать разные проблемы не переписывая имплементацию бд.. с GQL теперь происходит подобное но уже на уровне API и в виде графа

Ладно, уговорил. Не вносить изменения в сервер вполне годная аргументация.

а я чет не вижу проблемы

все протоколы, начиная со второго, отдаются по эндпойнтам с префиксом /vN/, где N - номер версии. и все тип-топ, старые клиенты забирают то, что надо, новые - то чно хотят.

все протоколы, начиная со второго, отдаются по эндпойнтам с префиксом /vN/, где N - номер версии. и все тип-топ, старые клиенты забирают то, что надо, новые - то чно хотят.

я не про верионирование, а про то что в идеале для каждого клиента - отдельные endpoint'ы

а?!

а?!

меняется клиент - меняется сервер. tight coupling, ибо RPC. в GQL это не так, сервер меняется только в том случае если появляются новые требования к данным, а не к тому как и в каком виде они отдаются допустим мы изменили view'шку в приложении, было A,B стало A,C; в идеале нам нужно написать новый спец-endpoint для этого нового требования к тому "в каком виде" данные возвращаются. В GQL нам вообще никаких изменений на стороне сервера не потребуются, просто новый query на клиенте и всё.

Эх... Может sql напрямую передавать :) наверное этим все и кончится :)

Эх... Может sql напрямую передавать :) наверное этим все и кончится :)

это уже было

это уже было

Где? В толстых клиентах?

добрый вечер может кто подсказать библиотеки для того чтоб зашифровать строку на js а расшифровать на go