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

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

Мне кажется, это определение "предсказуемости"

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

пусть умирает

допустим id 55 было не заюзано

тогда будет не монотонно

следующий запрашивающий id получит 56

тогда будет не монотонно

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

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

а если комета прилетит, то тогда на работу ходить не надо будет.

хз, ну вот postgres, вставляешь запись в транзакции - тебе дали id 55, транзакция откатилась по какой-то причине - следующий запрашивающий id в любому случае получит id 56

к вопросу в БД: Марко одобряет монолитные приложения и пишет почему именно: https://youtu.be/IVKpmk1QTWM?t=6m34s

Ильнур, тут вопрос в том, как ставится задача. Если дырки допустимы - это одно. Если нет, то другое. Самое простое - это генерить уникальные id-шки.

например - timeuuid

ага, а монтонность это обязательно без пропусков?

не. это просто чтобы росло

непрырвность - это без дырок.

м, тогда можно смело делать как в postgres)

или использовать его

это кому?

Это я за инет заплатил? тлрмознул малость... бывает

Эк вас тут торкнуло. Тут есть единственно верный способ - один канал для записи в мап (да куда угодно) условно реестр, второй канал с очередью - условно бродкастер (куда там ему нужно отправлять). Реестр ппринимает пуши для регистрации пользователя и с сует их и в мапу и в бродкастер. Реестр принимает запросы на удаление пользователей или маркировку их как обработанных от бродкастера. В случае краха бродкастера - подкачивать данные из мапа/БД и все с начала. А вообще реализация с мапом очень.... странная.

Эк вас тут торкнуло. Тут есть единственно верный способ - один канал для записи в мап (да куда угодно) условно реестр, второй канал с очередью - условно бродкастер (куда там ему нужно отправлять). Реестр ппринимает пуши для регистрации пользователя и с сует их и в мапу и в бродкастер. Реестр принимает запросы на удаление пользователей или маркировку их как обработанных от бродкастера. В случае краха бродкастера - подкачивать данные из мапа/БД и все с начала. А вообще реализация с мапом очень.... странная.

а читать свойства юзера как?

а читать свойства юзера как?

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

и как же будет работать этот геттер?

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

если уж на каналах решили все делать

и выходит, что map не очень уж и плохая идея.

если на каналах... но для ляма не грех и message bus

Всем добрый день, хотел сообщить что вчера оффициально вышла первая бета версия нашей библиотеки вебсокетов: https://github.com/qbeon/webwire-go было бы круто получить feedback от тех, кому тема интересна, буду рад вопросам / комментариям, в любом случае спасибо за внимение ?

и выходит, что map не очень уж и плохая идея.

Она не плохая, она ненадежная. Ухнется мап - пиши пропало. При этом тебе еще прийдется обвязать функционалом для аварийного останова

мне интересна. Использую гориллу сейчас. Но она делает лишнии аллокации при сжатии. Ваша умеет сжатие?

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

А, так вы гориилу и используете...

Всем добрый день, хотел сообщить что вчера оффициально вышла первая бета версия нашей библиотеки вебсокетов: https://github.com/qbeon/webwire-go было бы круто получить feedback от тех, кому тема интересна, буду рад вопросам / комментариям, в любом случае спасибо за внимение ?

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

Она не плохая, она ненадежная. Ухнется мап - пиши пропало. При этом тебе еще прийдется обвязать функционалом для аварийного останова

поясни плз проблему. не понял про надёжность.

Всем добрый день, хотел сообщить что вчера оффициально вышла первая бета версия нашей библиотеки вебсокетов: https://github.com/qbeon/webwire-go было бы круто получить feedback от тех, кому тема интересна, буду рад вопросам / комментариям, в любом случае спасибо за внимение ?

Супер, а то все либы для го поверх вебсокетов дохлые

мне интересна. Использую гориллу сейчас. Но она делает лишнии аллокации при сжатии. Ваша умеет сжатие?

это скорее не реализация websocket'ов, а абстракция над ними как и написано в описании, ибо сокеты это тупо труба в которую из каждой стороны можно что угодно залить.. данная либа воплощает req-rep, аутентификацию и прочее, всё в описании)

Супер, а то все либы для го поверх вебсокетов дохлые

почему дохлые. Есть как минимум две рабочие: гориллы и Сергея Камардина из мейла: https://github.com/gobwas/ws

почему дохлые. Есть как минимум две рабочие: гориллы и Сергея Камардина из мейла: https://github.com/gobwas/ws

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

поясни плз проблему. не понял про надёжность.

Как обновлять сервис обслуживающий эту мапу? Если это просто кэш, или важность данных на уровне "дахусим", то пойдет. Если это хранилище то... хз, я бы не рисковал.

почему дохлые. Есть как минимум две рабочие: гориллы и Сергея Камардина из мейла: https://github.com/gobwas/ws

ну это воплощение самих вебсокетов, а не абстракция над ними ?

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

именно, что-то на уровне ZMQ очень грубо говоря, но таки не ZMQ

Как обновлять сервис обслуживающий эту мапу? Если это просто кэш, или важность данных на уровне "дахусим", то пойдет. Если это хранилище то... хз, я бы не рисковал.

я делаю это так: госсипом постоянно рассылаю содержимое мапы другим нодам на случай их падения. А при рестарте у меня снача новая нода запускается, потом старая умирающая отправляет ей все данные так же, как если бы она отправляла их другим нодам. Т.е. данные не пропадают.

Т.е. данные в общем не теряются. даже при авариях они имеют шансы выжить. Но их потеря не очень критичная.

именно, что-то на уровне ZMQ очень грубо говоря, но таки не ZMQ

А есть что-то типа rooms из socket.io?

я делаю это так: госсипом постоянно рассылаю содержимое мапы другим нодам на случай их падения. А при рестарте у меня снача новая нода запускается, потом старая умирающая отправляет ей все данные так же, как если бы она отправляла их другим нодам. Т.е. данные не пропадают.

Если процесс передачи ненакладный то пойдет

А есть что-то типа rooms из socket.io?

есть пример chatroom: https://github.com/qbeon/webwire-go/tree/master/examples похож на пример socket.io, можно запустить Go сервер, подключить Go клиенты и JavaScript приложение: https://github.com/qbeon/webwire-js/tree/master/examples/chatroom-client-vue

есть пример chatroom: https://github.com/qbeon/webwire-go/tree/master/examples похож на пример socket.io, можно запустить Go сервер, подключить Go клиенты и JavaScript приложение: https://github.com/qbeon/webwire-js/tree/master/examples/chatroom-client-vue

https://github.com/qbeon/webwire-go/blob/master/examples/chatroom/server/sessions.go А вот тут не надо мапу с сессиями защищать мютексом?

https://github.com/qbeon/webwire-go/blob/master/examples/chatroom/server/sessions.go А вот тут не надо мапу с сессиями защищать мютексом?

да, здесь возможно нужно

да, здесь возможно нужно

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

я так понимаю, что нужна ещё и клиентская либа https://github.com/qbeon/webwire-js

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

в этом на самом деле и была изначальная фишка, библиотека не обязывает использовать какой-то определённый подход а позволяет реализовать какой угодно. Однако я соглашусь с тем, что было бы неплохо иметь стандартную имплементацию по умолчанию для облегчения так скажем "getting started" можешь добавить feature request в issue

да, здесь возможно нужно

Ага, я увидел, есть по-сути, интерфейс хуков и можно любую свою систему сессий замутить

я так понимаю, что нужна ещё и клиентская либа https://github.com/qbeon/webwire-js

конечно, она бесшовно связывает JavaScript приложение с Go сервером

беСшовно. от слова чёрт

есть желание реализовать ещё клиент на C++ Qt, но это уже как время останется

беСшовно. от слова чёрт

✌?

я просто немец, прошу строго меня в плане грамматики не судить)

@Romshark кстати, вот у хуков сигнатура коллбека: (ctx context.Context) (wwr.Payload, *wwr.Error) Может лучше сделать wwr.Payload указателем, чтобы не гонять пустую структуру в случае ошибки, например? А еще собственный тип для ошибок како-то тоже не очень

То бишь собственный тип для ошибки - ок, но возвращать лучше универсальный error, а дальше в обработчике попробовать скастовать к wwr.Error, если нет, то создать на основе обычного error

@Romshark кстати, вот у хуков сигнатура коллбека: (ctx context.Context) (wwr.Payload, *wwr.Error) Может лучше сделать wwr.Payload указателем, чтобы не гонять пустую структуру в случае ошибки, например? А еще собственный тип для ошибок како-то тоже не очень

не уверен что это лучше, в Go в принципе чем меньше указателей тем лучше, ибо меньше работы колектору. Payload из себя представляет слайс байтов и integer, копировать его очень дёшево

не уверен что это лучше, в Go в принципе чем меньше указателей тем лучше, ибо меньше работы колектору. Payload из себя представляет слайс байтов и integer, копировать его очень дёшево

Просто тогда надо инициализировать этот пейлоад, что просто синтаксически неудобно

@Romshark кстати, вот у хуков сигнатура коллбека: (ctx context.Context) (wwr.Payload, *wwr.Error) Может лучше сделать wwr.Payload указателем, чтобы не гонять пустую структуру в случае ошибки, например? А еще собственный тип для ошибок како-то тоже не очень

насчёт типа ошибки согласен, можешь плиз в issue запостить? сразу отмечу

насчёт типа ошибки согласен, можешь плиз в issue запостить? сразу отмечу

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

ERROR: S client not available

не уверен что это лучше, в Go в принципе чем меньше указателей тем лучше, ибо меньше работы колектору. Payload из себя представляет слайс байтов и integer, копировать его очень дёшево

Чем меньше указателей тем лучше? Лучше копировать туда сюда?

Просто тогда надо инициализировать этот пейлоад, что просто синтаксически неудобно

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

Чем меньше указателей тем лучше? Лучше копировать туда сюда?

порой да

если копируемые структуры небольшие

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

Преждевременная оптимизация

@Romshark кстати, дискуссионный вопрос, но мне кажется в го лучше названия файлов именовать в snake_case. Есть у нас типа SomeType, но класть в some_type.go. В исходниках докера так, например

@Romshark кстати, дискуссионный вопрос, но мне кажется в го лучше названия файлов именовать в snake_case. Есть у нас типа SomeType, но класть в some_type.go. В исходниках докера так, например

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

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

Просто даже тесты именуются: файлы с _test, функции Test

Просто даже тесты именуются: файлы с _test, функции Test

да, тесты то обязательно должны иметь постфикс _test.go, просто я по привычке пишу camelCase, но исправим

зачем?

зачем?

в смысле?

зачем файлы переименовывать?

зачем файлы переименовывать?

если в Go Community принят under_score то зачем идти против community guidelines?

так себе аргумент

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

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

так себе аргумент

посмотрим короче) не самая важная проблема

а если там солянка сборная - то по смыслу солянки снейкейсом

а если там солянка сборная - то по смыслу солянки снейкейсом

аналогично

если в Go Community принят under_score то зачем идти против community guidelines?

Я тебе по секрету скажу, если написать что-то серьёзное - мало того, что всем будет по барабану, так ещё и холиварить будут, мол вон а у Романа кэмэл- кейс и Роман - пацан толковый, херни не напишет. Так что забей

Я тебе по секрету скажу, если написать что-то серьёзное - мало того, что всем будет по барабану, так ещё и холиварить будут, мол вон а у Романа кэмэл- кейс и Роман - пацан толковый, херни не напишет. Так что забей

эта тема как всегда сугубо эмоцианальная.. разные стили пораждают в разных людях разные эмоции.. и если большинство Goферов привыкли к under_score то естественно camelCase пораждает не самые лучшие эмоции)

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

эта тема как всегда сугубо эмоцианальная.. разные стили пораждают в разных людях разные эмоции.. и если большинство Goферов привыкли к under_score то естественно camelCase пораждает не самые лучшие эмоции)

да ладно, вон в функциях и CamelCase и camelCase и нормально же

а?!

(осторожно) вы про экспортируемое-неэкспортируемое слышали?

ага

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

или это юмор для меня оказался тонковат?..

не, это я к тому, что гоферы привыкли к кемел кейсу

не, это я к тому, что гоферы привыкли к кемел кейсу

ну да, Reply_message выглядит как продукт чернобиля 30-летней издержки

не, это я к тому, что гоферы привыкли к кемел кейсу

Есть код-стайл, а есть необходимость. Экспортируемые/внутренние методы/структуры или _test файлы - это необходимость. Остальное - эстетство и вкусовщина.