А в c++?

в с++ плохо все, вообще-то. экосистему захватили технофилы какие-то, и теперь в ней все похоже на буст. но - да, в с++ можно было бы писать многотредное не сложнее, чем в go писать многорутинное. если бы там вообще было можно писать (на самом деле - проблема, скорее, с чтением)

+много за jsonrpc2

мне тоже хорошо зашёл. Сейчас вот на вебсокете сделал в обе стороны

batching

это аргумент. но скажи - часто ли оно нужно?

мне тоже хорошо зашёл. Сейчас вот на вебсокете сделал в обе стороны

ну вот надо взять в руки себя, спеку swagger 3.0, подпилить ее под jsonrpc2 и написать кодогенератор

и будет очень хорошо

а пока - надо советовать сваггер всем пионерам

а пока - надо советовать сваггер всем пионерам

а вы graphql не рассматривали?

пока не дошли руки

но по первому впечатлению - все совсем не так жестко, как хотелось бы

но по первому впечатлению - все совсем не так жестко, как хотелось бы

у меня по опыту в пет-проекте сложилось впечатление, что апи получается проще, тесты и документацию писать на него проще

и для фронтенда его проще приспособить чем rest api. Фронтендеры (нормальные) будут счастливы получать graphql через фреймворк Apollo

но по первому впечатлению - все совсем не так жестко, как хотелось бы

если решитесь, смотрите сразу на https://github.com/vektah/gqlgen

Такой вопрос

xor является арифметической операцией

ну это операция

только если в математики это больше функция

так же это логическая операция

но никак не арифметическая ?

Отлично

если решитесь, смотрите сразу на https://github.com/vektah/gqlgen

спасибо!

только если в математики это больше функция

А в математике операция и функция - есть суть одно и то же

Нет

А в чем разница?

Арифметическое или логическое действие

Это операция

Ну функцию думаю объяснять не надо

Арифметическое или логическое действие

А если изъясняться в математических терминах?

И чем тебе сложение не функция?

Арифметическое или логическое действие

.

Принимает два аргумента, возвращает один

Эээ

Результат

Ладно возьмите интеграл от 0 до 1 операции сложения

в с++ плохо все, вообще-то. экосистему захватили технофилы какие-то, и теперь в ней все похоже на буст. но - да, в с++ можно было бы писать многотредное не сложнее, чем в go писать многорутинное. если бы там вообще было можно писать (на самом деле - проблема, скорее, с чтением)

а как же c++ asio и std::thread ?

По какому параметру?

по двум, объемный :)

С объемными не работал, уж извините

И ко мне вполне можно на ты, кстати

и для фронтенда его проще приспособить чем rest api. Фронтендеры (нормальные) будут счастливы получать graphql через фреймворк Apollo

о даа, мы полностью на GQL перешли, вспоминаю REST как страшный сон, однако GQL ещё довольно молод и с этим связанны некоторые проблемы незрелости реализации GQL на Go

Вы не правильно интерпритируете функцию в математике и в программировании

это аргумент. но скажи - часто ли оно нужно?

Любой дерьмовый инет. Надо просто попользоваться restful api на edge и сразу вопросы отпадут

Функция в математике есть наиболее абстрактное понятие функции в программировании

Точнее даже наоборот

"точнее наоборот" - это мое любимое...

о даа, мы полностью на GQL перешли, вспоминаю REST как страшный сон, однако GQL ещё довольно молод и с этим связанны некоторые проблемы незрелости реализации GQL на Go

что страшного в REST? да и сравнение неточное, graphql задает тон на всю архитектуру, а REST только поверхностно

Функция в программировании - частный случай применения абстракции, которая зовется функцией в математике

Любой дерьмовый инет. Надо просто попользоваться restful api на edge и сразу вопросы отпадут

ответы быстрее приезжать не начнут, и синхронные операции тормозить не перестанут

То есть любую функцию в программировании можно выразить функцией в математике

Другое дело, чтор это может быть очень сложным процессом

"точнее наоборот" - это мое любимое...

Я просто написал немного не то, что имел в уме =)

о даа, мы полностью на GQL перешли, вспоминаю REST как страшный сон, однако GQL ещё довольно молод и с этим связанны некоторые проблемы незрелости реализации GQL на Go

круто, молодцы! Да, либы для Го ещё сыроваты.

круто, молодцы! Да, либы для Го ещё сыроваты.

Какой язык такие и либы

что страшного в REST? да и сравнение неточное, graphql задает тон на всю архитектуру, а REST только поверхностно

1. underfetching 2. overfetching 3. no typing & no validation 4. no documentation standard 5. no introspection 6. tight coupling всё это в GQL решено. Особенно критичные пункты: 1, 6 и 3

Какой язык такие и либы

Скидыщ, да начнется холивар

3-4. решены в сваггере.

1. underfetching 2. overfetching 3. no typing & no validation 4. no documentation standard 5. no introspection 6. tight coupling всё это в GQL решено. Особенно критичные пункты: 1, 6 и 3

постойте, вы сваливаете проблемы на REST, которые должны решаться разработчиками. graphql пытается наладить все это и для большей части приложений, это так, но, как я и сказал выше, сравнение не совсем верное.

3-4. решены в сваггере.

если хорошо постараться то можно реализовать хороший REST, но вот проблему 1, 2 и 6 это никак не решит, тут REST обречён

ответы быстрее приезжать не начнут, и синхронные операции тормозить не перестанут

Нет http-запроса на каждый чих, нет tls хендшейка(даже с тикетами)

постойте, вы сваливаете проблемы на REST, которые должны решаться разработчиками. graphql пытается наладить все это и для большей части приложений, это так, но, как я и сказал выше, сравнение не совсем верное.

как вы решите underfetching? только 6м пунктом, а именно tight coupling. а как вы решите tight coupling? да никак))

изменился клиент? меняй API... а что если у тебя 2 клиента? а что если 3 как было у Netflix? а что если их вообще может быть X ? REST из-за tight coupling'а может превратиться в ночной кошмар API разработчика

Нет http-запроса на каждый чих, нет tls хендшейка(даже с тикетами)

ты, конечно, извини, но keep-alive довольно давно придуман. tls handshake происходит саавсем не на каждый запрос. кроме того, с элиптическими парами он сильно подешевел

как вы решите underfetching? только 6м пунктом, а именно tight coupling. а как вы решите tight coupling? да никак))

вы переживаете о лишних 3-5% траффика, но не учитываете насколько graphql замедляет ваш сервис. и усложняет его

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

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

3-5% это вы сейчас придумали? тут вопрос не в трафике а в latency, в колве round-trip'ов. underfetching означает что вам не хватит 1 round-trip'а и придётся бегать на API'шку постоянно туда сюда туда сюда... с GQL у вас обычно 1 round-trip плюс к этому, модульные большие приложения писать на GQL гораздо легче, ибо представьте, что у вас 20 умных компонентов в приложении и каждый хочет данные, с GQL каждый компонент может запросить малую часть графа, библиотека клиента GQL агрегирует все эти мини-запросы в 1 большой, чем снимет нагрузку на бд, сеть и вообще всё. Сервер вместо 20 малых запросов обработает 1 большой, что, как всем известно, производительнее. и с чего вы взяли что он замедляет сервер? придумали? Хорошая у вас фантазия)) в REST'е underfetching рано или поздно создаёт серьёзные проблемы производительности и поэтому приходится создавать спец-endpoint'ы для конкретных запросов аля api/users_with_posts а это неизбежно приводит к tight-coupling'у, что приводит в конце к тому, что изменения на клиенте трeбуют изменений в API, а это кошмар если у вас такие изменения происходят часто, и тем более если у вас несколько клиентов, либо вообще открытый API

открытый апи на gql?

кстати вы сказали инфлакс?

кто разрабатывал говнодрайвер к нему

ERROR: S client not available

мне охото человека просто расстрелять

4 вложенных цикла для сбора ROW

открытый апи на gql?

по ощущениями отдавать наружу gql это почти как отдать клиентам sql (кстати некоторые так и делают, например stackoverflow)

res, err := e.Db.Query(influxClient.NewQuery("select * from TABLE", "DBNAME", "")) if err != nil { panic(err) return nil } for _, result := range res.Results { for _, series := range result.Series { for _, row := range series.Values { rowMap := make(map[string]string) for n, value := range row { for i, colum := range series.Columns { if i == n { switch v := value.(type) { case json.Number: rowMap[colum] = v.String() case string: rowMap[colum] = v default: rowMap[colum] = "NULL" } break; } } // Собрали rowMap } } } }

сохраните кто будет работать с инфлаксом ?

драйвер - github.com/influxdata/influxdb/client/v2

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

из опыта цифру назвал. обычно, если ендпоинт(ы) более значимый, в REST отступают от правил и возвращают смешанные данные. никто не запращает, спецификация легко переносит добавление новой сущности. с учетом того, что под высокую нагрузку пишутся микросервисы, а не гигантские монолиты, это еще и скейлится на ура. опять же нужно всегда думать наперед и не создавать месиво. иногда лучше сделать 2 запроса чем один, разница пользователю заметна не будет. в общем, нужно думать и подстраиваться. у всех так или иначе это получается. даже у гигантов замедляет, потому что появляются доп. звенья в цепи доставки данных. 5 вместо 2-х, например. снижает нагрузку на бд аггрегацией запросов? сомнительная оптимизация. к тому же она напрямую неконтролируется, что потенциально приводит к обратному. на деле, я не спорю, что штука удобная, особенно хороша в стартапах, где раз-два - и в продакшн. но REST не стоит сравнивать

открытый апи на gql?

есть много способов обезопасить себя от malicious requests если вы об этом. самый радикальный и простой способ это завести whitelist запросов. Вы скажете "так чем это тогда лучше REST?!", отвечаю: разница в том, что в любой момент можно просто обновить whitelist, просто добавить туда новый шаблон query за 5 секунд не переписывая ни строчки API, в то время, как в REST придётся писать новый endpint. второй, более элегантный, но сложный способ это complexity budget. Каждому клиенту даётся бюджет на определённое время, например 5 секунд, Resolver'ы полей минусуют бюджет в зависимости от сложности Resolver'а, если бюджета на выполнение запроса не хватает - возвращаем access denied

по ощущениями отдавать наружу gql это почти как отдать клиентам sql (кстати некоторые так и делают, например stackoverflow)

нет, не надо заводить людей в заблуждение.

Всем привет. А помогите по рефлексии: func myFunc(arr interface{}) { varr := reflect.ValueOf(arr) varr.SetLen(varr.Len() - 1) } Паникует с using unaddressable value. Возможно ли мне как-то сделать interface{}, который под капотом - слайс - addressable и изменить его длину?

Всем привет. А помогите по рефлексии: func myFunc(arr interface{}) { varr := reflect.ValueOf(arr) varr.SetLen(varr.Len() - 1) } Паникует с using unaddressable value. Возможно ли мне как-то сделать interface{}, который под капотом - слайс - addressable и изменить его длину?

свят-свят... а вам зачем?

слайс - штука ОООЧЕНЬ специфичная

из опыта цифру назвал. обычно, если ендпоинт(ы) более значимый, в REST отступают от правил и возвращают смешанные данные. никто не запращает, спецификация легко переносит добавление новой сущности. с учетом того, что под высокую нагрузку пишутся микросервисы, а не гигантские монолиты, это еще и скейлится на ура. опять же нужно всегда думать наперед и не создавать месиво. иногда лучше сделать 2 запроса чем один, разница пользователю заметна не будет. в общем, нужно думать и подстраиваться. у всех так или иначе это получается. даже у гигантов замедляет, потому что появляются доп. звенья в цепи доставки данных. 5 вместо 2-х, например. снижает нагрузку на бд аггрегацией запросов? сомнительная оптимизация. к тому же она напрямую неконтролируется, что потенциально приводит к обратному. на деле, я не спорю, что штука удобная, особенно хороша в стартапах, где раз-два - и в продакшн. но REST не стоит сравнивать

на микросервисы в основном ходят через gateway

из опыта цифру назвал. обычно, если ендпоинт(ы) более значимый, в REST отступают от правил и возвращают смешанные данные. никто не запращает, спецификация легко переносит добавление новой сущности. с учетом того, что под высокую нагрузку пишутся микросервисы, а не гигантские монолиты, это еще и скейлится на ура. опять же нужно всегда думать наперед и не создавать месиво. иногда лучше сделать 2 запроса чем один, разница пользователю заметна не будет. в общем, нужно думать и подстраиваться. у всех так или иначе это получается. даже у гигантов замедляет, потому что появляются доп. звенья в цепи доставки данных. 5 вместо 2-х, например. снижает нагрузку на бд аггрегацией запросов? сомнительная оптимизация. к тому же она напрямую неконтролируется, что потенциально приводит к обратному. на деле, я не спорю, что штука удобная, особенно хороша в стартапах, где раз-два - и в продакшн. но REST не стоит сравнивать

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

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

руками написанный и продуманный запрос всегда лучше сгенерированного

руками написанный и продуманный запрос всегда лучше сгенерированного

сгенерированный запрос? это кто в GQL генерирует запросы?

сгенерированный запрос? это кто в GQL генерирует запросы?

мне казалось, что GQL-это именно про язык запросов? Ошибался?

GQL - отличная штука, избавляет от кучи проблем реста, если у вас не ресурсный crud, то советую GQL

ты, конечно, извини, но keep-alive довольно давно придуман. tls handshake происходит саавсем не на каждый запрос. кроме того, с элиптическими парами он сильно подешевел

Кипалайв не вечен, да и переиспользовать соединение можно только после того как тебе что-нибудь ответят и это все равно 1 раундтрип. Легко проверить на netem или edge. Ну и натягивание предметной области на ограниченное множество http verbs - то ещё удовольствие

3-5% это вы сейчас придумали? тут вопрос не в трафике а в latency, в колве round-trip'ов. underfetching означает что вам не хватит 1 round-trip'а и придётся бегать на API'шку постоянно туда сюда туда сюда... с GQL у вас обычно 1 round-trip плюс к этому, модульные большие приложения писать на GQL гораздо легче, ибо представьте, что у вас 20 умных компонентов в приложении и каждый хочет данные, с GQL каждый компонент может запросить малую часть графа, библиотека клиента GQL агрегирует все эти мини-запросы в 1 большой, чем снимет нагрузку на бд, сеть и вообще всё. Сервер вместо 20 малых запросов обработает 1 большой, что, как всем известно, производительнее. и с чего вы взяли что он замедляет сервер? придумали? Хорошая у вас фантазия)) в REST'е underfetching рано или поздно создаёт серьёзные проблемы производительности и поэтому приходится создавать спец-endpoint'ы для конкретных запросов аля api/users_with_posts а это неизбежно приводит к tight-coupling'у, что приводит в конце к тому, что изменения на клиенте трeбуют изменений в API, а это кошмар если у вас такие изменения происходят часто, и тем более если у вас несколько клиентов, либо вообще открытый API

+много. И атомарность в rest забавно делать

сгенерированный запрос? это кто в GQL генерирует запросы?

как вы вытаскиваете данные из 3 таблиц?

мне казалось, что GQL-это именно про язык запросов? Ошибался?

об этом и речь. язык запросов во многом порождает архитектуру вашего приложения. это совсем несравнимо с REST

об этом и речь. язык запросов во многом порождает архитектуру вашего приложения. это совсем несравнимо с REST

Ну, соответственно, он вполне себе модет генерить запрос к БД на бэкенде, что таки подтверждает тезис о том, что в перспективе фиксированный эндпоинт рест несколько проще поддается оптимизации

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

Не, я не то, чтобы рест защищал. У меня к нему, по большому счету одна, но уберважная претензия: http verbs

Собственно, огромная часть болячек Реста, можно сказать, побеждена в виде grpc

Собственно, огромная часть болячек Реста, можно сказать, побеждена в виде grpc

вот смотрю, начинают тянуться к gRPC. окружение постепенно нарастает

А вот позиция "статичные запросы говно, да здравствует язык запросов на клиенте" - так себе позиция. GQL порождает примерно столько же проблем, сколько и решает, только в других плоскостях. Чудес, как известно, не бывает...

Кроме gRPC

вот смотрю, начинают тянуться к gRPC. окружение постепенно нарастает

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

Кроме gRPC

gRPC - весчь, и ниипет)

мне казалось, что GQL-это именно про язык запросов? Ошибался?

GraphQL это язык, на котором клиент обращается к серверу. Тебе, как разработчику API, нужно написать переводчик GQL в данные, как ты это сделаешь уже другой вопрос. У нас слоистая архитектура такова: 1. transport (transmit, authenticate) - отвечает за передачу данных и аутентификацию клиента, может быть HTTP(s), может быть WS(S), в нашем случае это https://github.com/qbeon/webwire-go 2. graph (parse, validate, authorize) - отвечает за парсинг, валидацию и авторизацию. Вызывает resolver функций для каждого поля графа. За парсинг у нас отвечает библиотека https://github.com/graph-gophers/graphql-go, а авторизация происходит в самих resolver функциях на основе тех данных, которые нам 1 транспортный уровень передал о клиенте. 3. loaders (batch, cache) - отвечает за batching и caching, грубо говоря на этом слою устраняются лишние engine-call'ы, если какие-то entity уже имеются в кэше или уже запросились другим resolver'ом, то мы его не дублируем 4. engine interface (engine capabilities) - это абстрактный интерфейсный уровень. Каждая реализация движка сервиса должна полностью воплощать этот интерфейс 5. engine (business logic, databases) - отвечает за бизнес логику и работу с бд, обязан полностью воплощать интерфейс. У нас обычно 2 движка: mock & production, mock тупо в памяти, production на основе какой-либо бд