но сейчас через глобальые переменные в пакете тоже не ок

можно DI заюзать, но я не люблю DI в го

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

Знатоки gin-gonic, подскажите пожалуйста, как сделать так, чтобы данные из хедера POST-запроса были доступны и в middleware и в конечной функции? Проблема в том, что если я делаю в middleware c.BindJSON(&myStruct) то данные вычитываются(пропадают) из контекста.

CoffeeGo

Жуть

Знатоки gin-gonic, подскажите пожалуйста, как сделать так, чтобы данные из хедера POST-запроса были доступны и в middleware и в конечной функции? Проблема в том, что если я делаю в middleware c.BindJSON(&myStruct) то данные вычитываются(пропадают) из контекста.

А там не так? ?

А там не так? ?

вопрос не понятен.

хотел подобное делать сам. зачёт ))

вопрос не понятен.

Ну - у меня в миддлварах доступен тот же контекст, что и в хендлере, а исходя из вопроса, в gin не так

Ну - у меня в миддлварах доступен тот же контекст, что и в хендлере, а исходя из вопроса, в gin не так

ну, контекст он "тот же". Не в этом же проблема.

ну, контекст он "тот же". Не в этом же проблема.

А, именно пропадают с концами?

Данные

секунду, проверяю кое-что

А, именно пропадают с концами?

да.

и, если их не биндить в middleware, они доходят до конечного хендлера.

Я понимаю, что можно из в middleware считать, и перезапихнуть в контекст, но мне это кажется костылями.

Я понимаю, что можно из в middleware считать, и перезапихнуть в контекст, но мне это кажется костылями.

ну — это ожидаемый костыль, да

что для websocket использовать?

зависит от задания, что тебе конкретно нужно? сомневаюсь что нужен чистый низкоуровневый вебсокет, может скорее нужна bidirectional связь?

мне нужна полнодуплексная шина сообщений) как можно высокоуровневая)

мне нужна полнодуплексная шина сообщений) как можно высокоуровневая)

глянь https://github.com/qbeon/webwire-go

вижу твое творчество. Используется где?

а где пример веб-клиента?

вижу твое творчество. Используется где?

сейчас используется у нас в проде (fitcat.pro) и ещё недавно https://www.drom.ru/ подкатили

сейчас используется у нас в проде (fitcat.pro) и ещё недавно https://www.drom.ru/ подкатили

первый не открыть

раньше открывался

первый не открыть

webwire положил)

а где пример веб-клиента?

https://github.com/qbeon/webwire-go/tree/master/examples/chatroom имеется JS example клиент: https://github.com/qbeon/webwire-js/tree/master/examples/chatroom-client-vue

первый не открыть

maintenance))

maintenance))

заглушка бы не помешала

я сначала подумал опять проделки ркн

заглушка бы не помешала

фронт ещё не в проде

webwire положил)

webwire != HTTP ?

webwire != HTTP ?

а вот скажи, это замена горилле?

какие еще варианты есть? огласите весь список, пожалуйста

Вчера весь день срались на эту тему там буква А в конце латинская

И как мы можем об этом узнать?

а вот скажи, это замена горилле?

нет, это более высокий уровень абстракции. Под капотом тот-же горилла вебсокет вебсокет это тупая труба, она умеет только подключиться и слать сообщения туда сюда.. вебсокет по умолчанию понятия не имеет об request-response, аутентификации, сессиях, авто-восстановление соединения и сессии и т.д. в прочем, надеюсь что достаточно хорошо описал features: https://github.com/qbeon/webwire-go#features

нет, это более высокий уровень абстракции. Под капотом тот-же горилла вебсокет вебсокет это тупая труба, она умеет только подключиться и слать сообщения туда сюда.. вебсокет по умолчанию понятия не имеет об request-response, аутентификации, сессиях, авто-восстановление соединения и сессии и т.д. в прочем, надеюсь что достаточно хорошо описал features: https://github.com/qbeon/webwire-go#features

да, перепутал. имел в виду melody, который на горилле https://github.com/olahol/melody

И как мы можем об этом узнать?

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

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

но проявив подобную дедукцию я нашел еще 4 правильных ответа

да, перепутал. имел в виду melody, который на горилле https://github.com/olahol/melody

он не умеет REQ-REP как минимум

ок. скажи, насколько webwire тяжелый. если я например решу внедрить ws в своем пете, это будет оправданный выбор?

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

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

ок. скажи, насколько webwire тяжелый. если я например решу внедрить ws в своем пете, это будет оправданный выбор?

тяжёлый? в каком конкретно смысле тяжёлый? с точки зрения кода? с точки зрения performance'а? traffic overhead?

скорее функциональный оверхед

скорее функциональный оверхед

он по сути умеет всё что умеет тупой сокет и HTTP/2, но предоставляет тебе возможность самому определить формат общения, будь то UTF8 text, JSON, Thrift, Protobuf, plain binary... у webwire сообщений довольно малый overhead, 9-10 байт для запросов, 3-4 байт для сигналов сигналы отличаются от простых message'ей тем что несут информацию о кодировке сообщения и имя для route'инга

скорее функциональный оверхед

а интерфейс довольно простой. Имплементируешь интерфейс сервера/клиента и там всё более менее интуитивно. от concurrent access'а все интерфейсы взаимодействия с connection'ами, сервером, клиентом, сессиями и т.д. защищены

по производительности: https://github.com/qbeon/webwire-go/issues/17#issuecomment-401216669 ещё не идеально, но 10к rps на 10к соединениях тянет без особых проблем

нет, это более высокий уровень абстракции. Под капотом тот-же горилла вебсокет вебсокет это тупая труба, она умеет только подключиться и слать сообщения туда сюда.. вебсокет по умолчанию понятия не имеет об request-response, аутентификации, сессиях, авто-восстановление соединения и сессии и т.д. в прочем, надеюсь что достаточно хорошо описал features: https://github.com/qbeon/webwire-go#features

годнота, может заюзаем в нашем чате в будущем

ну — это ожидаемый костыль, да

Но не подходящий, потому что в middleware мы ещё не знаем в какую именно структуру парсить данные из запроса. В каждом хендлере - происходит c.BindJSON в свою структуру.

по-моему, для такой архитектуры джин не оч заходит

по-моему, для такой архитектуры джин не оч заходит

ну а зачем там middleware придуманы тогда?

Здравствуйте, есть ли Go канал для новичков, по типу python_beginners?

тут задвайте

возможно, я саму задачу неверно решаю. Мне в запросе нужно ловить аутентификационный токен и сами данные запроса. На группу адресов я назначил мидлвер и там ловлю аутентификационный токен, и если он подходит, то данные должны идти дальше в хендлер. Логично же?

разве что обычно просят пройти go tour перед вопросом

тут задвайте

Как лучше начать изучение Go? Сразу с фреймворка или самому писать свои миддлвари, орм и т.д.?

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

фрейворки у нас не жалуют

ну а зачем там middleware придуманы тогда?

чтобы галочку в ридми поставить можно было

фрейворки у нас не жалуют

ой, не гони, а

... и прохождения туториала

фрейворки у нас не жалуют

пришел человек, что в $GOPATH/src всё разрабатывает ;p

прямо в корне?

то есть по сути Go по типу микрофреймворка? В стандартном пакете есть все для веба -> дальше сам крафтишь свой апп? Почти как Flask в питоне, так?

ERROR: S client not available

то есть по сути Go по типу микрофреймворка? В стандартном пакете есть все для веба -> дальше сам крафтишь свой апп? Почти как Flask в питоне, так?

в стандартной поставке почти все есть

то есть по сути Go по типу микрофреймворка? В стандартном пакете есть все для веба -> дальше сам крафтишь свой апп? Почти как Flask в питоне, так?

есть

понял, спасибо

Есть JSON RPC сервис, построенный на стандартном пакете. И что бы клиенту вызвать какой то метод, он должен передать имя структуры и имя метода ИмяСтруктуры.ИмяМетода, можно ли как то переписать сервис на стандартном пакете, что бы клиент вызывал метод имяметода.

существует уже кодо-анализатор который способен относительно экспортируемых символов пакета вычислять semver версию? допустим в новом комите я изменил интерфейс пакета, переименовал экспортируемую функцию: было: package mypack // ParseText parses texts from a file func ParseText(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } очевидно я поломал обратную совместимость, поэтому анализ должен это распознать и присвоить моему комиту версию 2.0.0 однако если я не поломал совместимость в комите: было: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } // CreateFile creates a new file func CreateFile() error { /*...*/ } т.е. например добавил новую функцию, тогда он считает feature version v2.1.0 а если я ничего не ломал но и ничего не добавлял но изменил что-то в недрах - то v2.1.1 думаю такая автоматизация версионирования была бы очень полезна

существует уже кодо-анализатор который способен относительно экспортируемых символов пакета вычислять semver версию? допустим в новом комите я изменил интерфейс пакета, переименовал экспортируемую функцию: было: package mypack // ParseText parses texts from a file func ParseText(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } очевидно я поломал обратную совместимость, поэтому анализ должен это распознать и присвоить моему комиту версию 2.0.0 однако если я не поломал совместимость в комите: было: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } // CreateFile creates a new file func CreateFile() error { /*...*/ } т.е. например добавил новую функцию, тогда он считает feature version v2.1.0 а если я ничего не ломал но и ничего не добавлял но изменил что-то в недрах - то v2.1.1 думаю такая автоматизация версионирования была бы очень полезна

интересный концепт штук таких не видел, но идею себе схоронил - даже написать proof-of-concept был бы интересно

существует уже кодо-анализатор который способен относительно экспортируемых символов пакета вычислять semver версию? допустим в новом комите я изменил интерфейс пакета, переименовал экспортируемую функцию: было: package mypack // ParseText parses texts from a file func ParseText(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } очевидно я поломал обратную совместимость, поэтому анализ должен это распознать и присвоить моему комиту версию 2.0.0 однако если я не поломал совместимость в комите: было: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } // CreateFile creates a new file func CreateFile() error { /*...*/ } т.е. например добавил новую функцию, тогда он считает feature version v2.1.0 а если я ничего не ломал но и ничего не добавлял но изменил что-то в недрах - то v2.1.1 думаю такая автоматизация версионирования была бы очень полезна

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

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

нененене, ясное дело что можно поломать совместимость поломав поведение функции. Но я скорее говорю про облегчение стандартного workflow разработчика Go а не про охоту на баги. Если уж ты назвал функцию CreateFile то она конечно должна создать файл, если она этого не сделает то мы получим баг. Данный анализ не сможет защитить от багов! Он сможет лишь значительно облегчить CI/CD, тебе не нужно мануально выкатывать версии с CHANGELOG'ом и всё ручками писать.. сервис с каждым комитом track'ит версию и по нажатию кнопочки можно получить release + semver версию + changelog

изменение в интерфейсе пакета: major increment (compatibility) добавление в интерфейс пакета: minor increment (feature) внутренние изменения: patch increment (bug fix / improvement)

commit message может быть использован в качестве пункта в CHANGELOG'е дополнительно к автоматически сгенерированному пункту по поводу того что изменилось и как

существует уже кодо-анализатор который способен относительно экспортируемых символов пакета вычислять semver версию? допустим в новом комите я изменил интерфейс пакета, переименовал экспортируемую функцию: было: package mypack // ParseText parses texts from a file func ParseText(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } очевидно я поломал обратную совместимость, поэтому анализ должен это распознать и присвоить моему комиту версию 2.0.0 однако если я не поломал совместимость в комите: было: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } стало: package mypack // ParseFile parses texts from a file func ParseFile(file string) error { /*...*/ } // CreateFile creates a new file func CreateFile() error { /*...*/ } т.е. например добавил новую функцию, тогда он считает feature version v2.1.0 а если я ничего не ломал но и ничего не добавлял но изменил что-то в недрах - то v2.1.1 думаю такая автоматизация версионирования была бы очень полезна

для руста подобное видел

для руста подобное видел

хотелось бы видить что-то подобное для Go, поскольку Go это рай для статик-анализа)

хотелось бы видить что-то подобное для Go, поскольку Go это рай для статик-анализа)

> Go > рай для статик-анализа Оо. Ты о том, что это го это рай для компаний производящих проприетарные решения для статик-анализа? Ну всё же цпп ему ен переплюнуть.

нененене, ясное дело что можно поломать совместимость поломав поведение функции. Но я скорее говорю про облегчение стандартного workflow разработчика Go а не про охоту на баги. Если уж ты назвал функцию CreateFile то она конечно должна создать файл, если она этого не сделает то мы получим баг. Данный анализ не сможет защитить от багов! Он сможет лишь значительно облегчить CI/CD, тебе не нужно мануально выкатывать версии с CHANGELOG'ом и всё ручками писать.. сервис с каждым комитом track'ит версию и по нажатию кнопочки можно получить release + semver версию + changelog

Если не ошибаюсь, в своем цикле статей, перед выкаткой vgo, как раз об этом писал

> Go > рай для статик-анализа Оо. Ты о том, что это го это рай для компаний производящих проприетарные решения для статик-анализа? Ну всё же цпп ему ен переплюнуть.

Go исходники относительно легко анализировать

Если не ошибаюсь, в своем цикле статей, перед выкаткой vgo, как раз об этом писал

где и о чём конкретно писал?)

https://forum.golangbridge.org/t/go-1-2-immutability-proposal/10613

https://forum.golangbridge.org/t/go-1-2-immutability-proposal/10613

ща Роб Пайк выйдет и надёт вам по жопам, ишь блжад, иммутабельности захотели, в его годы они даже такого слова не знали, а тут молодёжь совсем распоясалась

ща Роб Пайк выйдет и надёт вам по жопам, ишь блжад, иммутабельности захотели, в его годы они даже такого слова не знали, а тут молодёжь совсем распоясалась

раньше было лучше (с) во времена ассамблера не говнокодили (с)

раньше было лучше (с) во времена ассамблера не говнокодили (с)

Кстати, handle err это же точь в точь калька с сишного способа обработки ошибок с помощью goto, не?

Еще как.

Ребят, я как понял в Go горутины - самые обычные корутины, только с implicit event loop'ом?

Ребят, я как понял в Go горутины - самые обычные корутины, только с implicit event loop'ом?

Не совсем. Корутины предполагают кооперативную многозадачность, чего горутины не гарантируют.

Ребят, я как понял в Go горутины - самые обычные корутины, только с implicit event loop'ом?

И пулом тредов в подкладке

Не совсем. Корутины предполагают кооперативную многозадачность, чего горутины не гарантируют.

А?!

Чёт я походу не особо подумал. Потому что корутины могут и на нескольких потоках крутиться

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

Но к примеру в ноде, корутина не прерывается пока не встретилось слово await.

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

Многозадачность бывает кооперативная и вытесняющая. Горутины - кооперативная

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

Так она и отдает При вызове IO При вызове не-inline функции При вызове Goshed

хм