мы его закрыли
Хм, и правда. Даже и не заметил :)
Anonymous
Cat
Aleksandr
в рамках твоей программерской парадигмы
Alexander
ну там, интерфейсами жонглировать
Alexander
reflect расчехлять
Alexander
а какую либу для графа используешь на сервере?
Aleksandr
https://github.com/graph-gophers/graphql-go
Alexander
спс
it works
Ребята, по тесту https://bit.ly/gogolang
Отпишитесь, пожалуйста, кто хотел получить расшифровку своих ответов с правильными вариантами, но ещё не получил.
Daniel
https://github.com/graph-gophers/graphql-go
Разве не ее клеймили сегодня за низкую производительность?
Aleksandr
Разве не ее клеймили сегодня за низкую производительность?
не, я ее предложил на замену той. называются позоже просто
Aleksandr
graphql-go vs go-graphql - юзать надо первую
Daniel
Roman
Roman
сильно с ним извращаться приходится?
не особо. Главное наивно resolver'ы не имплементировать и нормальную библиотеку юзать
Alexander
нормальную - это graphql-go ?
Roman
нормальную - это graphql-go ?
у нас сейчас на вооружении https://github.com/graph-gophers/graphql-go
Alexander
ну да, я её и имел ввиду
Roman
есть несколько адептов, которые его продвинают, и используют. в принципе - он иделогически лучше реста
да уж, после GQL на REST уже не тянет
Artem
да уж, после GQL на REST уже не тянет
Реализовывать для тривиальных задач рест приятнее, в графкуэль напарывались, что он высчитывает незапрашиваемые данные и тд
Roman
Реализовывать для тривиальных задач рест приятнее, в графкуэль напарывались, что он высчитывает незапрашиваемые данные и тд
для тривиальных задач RPC лучше, с этим никто не спорит.
но любой тривиальный проект может перерасти в нетривиальный и тогда начнётся special-endpoint канитель
.
Мне порой кажется что в мире существует только два варианта написания апи: rest и graphql
.
А про JSON RPC никогда не говорят (
Alexander
А как же апи богов? SOAP например!
Roman
Мне порой кажется что в мире существует только два варианта написания апи: rest и graphql
скорее RPC и GraphQL (и ещё десятки других малых стандартов)
.
Мне кстати из многих апи что я видел понравился апи слака
Roman
в RPC (REST etc.) ты мыслишь: "что умеет API?"
в GraphQL ты мыслишь: "какие данные предоставляет API?"
в GQL ты думаешь о данных, их типах и взаимосвязях (relations)
Artem
потому что QL
.
В REST ты думаешь "как натянуть логику на методы HTTP")
Artem
В REST ты думаешь "как натянуть логику на методы HTTP")
и если не придумал, то POST?
ketamine ranch
в рест твой сервер думает
Aleksandr
Реализовывать для тривиальных задач рест приятнее, в графкуэль напарывались, что он высчитывает незапрашиваемые данные и тд
не может такого быть) ресолверы реализуешь ты, а не graphql
.
Или же "как представить сложные структуры используя параметры формы"
Aleksandr
В REST ты думаешь "как натянуть логику на методы HTTP")
сначала так думаешь, а потом "зачем я в это ввязался"
Artem
не может такого быть) ресолверы реализуешь ты, а не graphql
там либка делает биндинги по именам полей в структуре, мб он об этом?
Roman
не может такого быть) ресолверы реализуешь ты, а не graphql
я частично с ним соглашусь. Написать толковые ресолверы сложнее чем тупой HTTP endpoint
но когда проект растёт HTTP/REST превращается в еле-типизированный, хаотичный, непонятный и запутанный ад
Artem
не может такого быть) ресолверы реализуешь ты, а не graphql
Там и пошёл костыль, что надо выяснить запрашиваемые поля и потом отдавать только их. А фронт находил новый способ запроса, что поля пролетали мимо анализатора
Aleksandr
там либка делает биндинги по именам полей в структуре, мб он об этом?
не помню такого. насколько помню обе либы абстрагированы от db-слоя (но как работает первая, я честно говоря уже подзабываю)
Artem
ну та на динамике, там есть defaultResolver, который как раз и мапит поля на структуру. А еще map[string]interface{} тоже отлично хавает
Roman
Там и пошёл костыль, что надо выяснить запрашиваемые поля и потом отдавать только их. А фронт находил новый способ запроса, что поля пролетали мимо анализатора
overfetching не так страшен как underfetching.
бару байт выбросить хуже хем пару недодать и в конце порадить дополнительный round-trip
Aleksandr
я частично с ним соглашусь. Написать толковые ресолверы сложнее чем тупой HTTP endpoint
но когда проект растёт HTTP/REST превращается в еле-типизированный, хаотичный, непонятный и запутанный ад
все мы частично с ним согласимся, но это проблема реализации, а не спеки. Как только в rest добавим выборку по полям, сразу придется городить такие же ресолверы. Или не заморчиваться и продолжать гонять агрегаты (ну так и в graphql то же самое будет)
Artem
Aleksandr
Там и пошёл костыль, что надо выяснить запрашиваемые поля и потом отдавать только их. А фронт находил новый способ запроса, что поля пролетали мимо анализатора
проблема не прояснилась. по спеке тебе прилетает список полей, gql ресолвит их черех ресолверы, написанные тобой. Анализ проходит внутри серверной либы
Aleksandr
ну та на динамике, там есть defaultResolver, который как раз и мапит поля на структуру. А еще map[string]interface{} тоже отлично хавает
а, ну может быть. ну надо старую либу забыть - она референсная, то есть работает, но не продакшн реди, а скорее как proof-of-concept
Yaroslav
overfetching не так страшен как underfetching.
бару байт выбросить хуже хем пару недодать и в конце порадить дополнительный round-trip
А если эти пару байт будут sensitive данными?
Yaroslav
Например, персональными
Roman
А если эти пару байт будут sensitive данными?
и что с ними произойдёт?
такое впечатление что вы считаете что те поля которые мы запросили у бд но не отдали клиенту автоматически улетают на чёрный рынок 😂
Artem
а, ну может быть. ну надо старую либу забыть - она референсная, то есть работает, но не продакшн реди, а скорее как proof-of-concept
а на вторую подзабили разрабы, и че вот делать?
Yaroslav
и что с ними произойдёт?
такое впечатление что вы считаете что те поля которые мы запросили у бд но не отдали клиенту автоматически улетают на чёрный рынок 😂
Я наоборот про то что лишнее отдать можно
Artem
форкаться и пилить
Andrey
я частично с ним соглашусь. Написать толковые ресолверы сложнее чем тупой HTTP endpoint
но когда проект растёт HTTP/REST превращается в еле-типизированный, хаотичный, непонятный и запутанный ад
swagger тоже не спасает? он умеет типы отдавать, если сервер конечно потдерживает типы.
В случае с явой так вообще полная автоматизация, пишешь эндпоинты, и у тебя генериться клиент. Я кроме JS ничего не использовал, но вроде есть разные целевые языки.
Aleksandr
а на вторую подзабили разрабы, и че вот делать?
вариантов нет. первая убогая.
На вторую подзабили, видимо потому что нет достаточно мотивирующего фидбека.
Можно ждать третью либу, но кажется придется довольствоваться второй
Roman
Artem
вариантов нет. первая убогая.
На вторую подзабили, видимо потому что нет достаточно мотивирующего фидбека.
Можно ждать третью либу, но кажется придется довольствоваться второй
это еще нужно придумать, что сделать в третьей, что б она была конкурентом
Aleksandr
в смысле имплементация интересная?
Roman
swagger тоже не спасает? он умеет типы отдавать, если сервер конечно потдерживает типы.
В случае с явой так вообще полная автоматизация, пишешь эндпоинты, и у тебя генериться клиент. Я кроме JS ничего не использовал, но вроде есть разные целевые языки.
свагер может и "спасает" в плане типизации (хоть и не совсем), но от болезней RPC он никак не спасает. вообще. Underfetching в RPC решается только добавлением новых endpoint'ов а это некрасиво, грязно и т.д.
Aleksandr
это еще нужно придумать, что сделать в третьей, что б она была конкурентом
есть feature requests в ишьюсах
Roman
а есть там что-то хорошее?
не знаю честно говоря хорошее или нет.. но много говорят про juniper https://github.com/graphql-rust/juniper
Aleksandr
во первых конечно реализовать subscriptions
Aleksandr
Не, я о том, что стоило бы новой либы, а не доработки этой
а, ну можно форкнуть. я имел в виду в целом третью, можно не с нуля)
Roman
во первых конечно реализовать subscriptions
мы кстати обратную связь решили с помощью webwire, пускай не совсем GraphQL-idiomatic но работает
считай делаешь mutation запрос с query строкой и она тебя подписывает на named-webwire-signal, который ты потом ловишь
Aleksandr
не знаю честно говоря хорошее или нет.. но много говорят про juniper https://github.com/graphql-rust/juniper
слушай, ну вот для меня ключевая фича - это поддержка родной схемы, без необходимости ее описывать в терминах языка.
https://github.com/graph-gophers/graphql-go/blob/master/example/starwars/starwars.go#L15
Andrey
свагер может и "спасает" в плане типизации (хоть и не совсем), но от болезней RPC он никак не спасает. вообще. Underfetching в RPC решается только добавлением новых endpoint'ов а это некрасиво, грязно и т.д.
Но вообще никто не запрещает отдавать на одном энпоинте разный набор полей. Мы так часто делали в зависимости от привелегий.
Roman
Roman
Но вообще никто не запрещает отдавать на одном энпоинте разный набор полей. Мы так часто делали в зависимости от привелегий.
вы не поняли. Дело не в overfetching'е (отдать поля, которые не нужны клиенту) а в underfetching'е (недодать данных)
Aleksandr
не совсем понял что ты этим хотел сказать
я хотел сказать что не вижу в растовой либе поддержки этого
Roman
Но вообще никто не запрещает отдавать на одном энпоинте разный набор полей. Мы так часто делали в зависимости от привелегий.
проблема со специализированными endpoint'ами в tight-coupling'е. Т.е. как только меняются требования клиента (например дизайн изменили, теперь на дашборде оборажается X,Y,Z а не как прежде Y,M,C,A) - нужно переписывать backend для оптимизации, и так постоянно...
а что если у вас не один клиент ещё в добавок?
RPC очень быстро может превратиться в maintenance катастрофу. Из-за этого и появились раньше такие вещи как SQL, которые позволили решать разные проблемы не переписывая имплементацию бд.. с GQL теперь происходит подобное но уже на уровне API и в виде графа