ой, прошу прощения, я ничего не читал и увидел «Тесты не компилятся»

стригеррился

помог, надеюсь

компилятся

Т.е. не компилятся. Иначе зачем этот файл?

Без этого файла так то вообще ничего не компилится

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

Попробуй убрать “lib” )

ну кстати да, получается тесты не компилятся

компилится test/support

Вот :)

тесты .exs, просто запускаются таском

В целом наверно пофиг, не главная проблема сейчас

У них просто определенный формат

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

Расскажи какие с ними беды

^ this

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

Удобные примитивы - это вебсокеты в Cowboy

Следующий уровень - это феникс

Я готов поспорить с тобой на 100 баксов, что ты не сможешь сделать что-то между ними. Так же как и вставить ws в плаг.

откуда берется "свой формат"? как к топику прицепить, например, SSE+HTTP POST клиент?

Я не уверен, что правильно понял твой вопрос

ну или вот: broadcast! socket, "user:entered", %{user: msg["user"]}какое отношение pubsub топик имеет к сокету канала?..

Но для server side events можно сделать отдельный сокет с кастомным протоколом

я не совсем про то, что между ws и каналами нужно что-то вставлять

я скорее о том, что в абстракцию "канал" спрятано что-то кроме ws с не очень понятными мне целями

ну или вот: broadcast! socket, "user:entered", %{user: msg["user"]}какое отношение pubsub топик имеет к сокету канала?..

так, стоп, это шляпа какая-то

это код 2015ого года, сорри

я скорее о том, что в абстракцию "канал" спрятано что-то кроме ws с не очень понятными мне целями

Канал это как раз таки абстракция пабсаба

И только

Можно канал без сокета использовать

В пабсабе

Можно и сокет без канала

ммм. а подцепить сокет к топику на лету?

Ты имеешь ввиду канал?

Или фронтенд?

давай с начала. канал - это как amqp exchange. сокет - примерно как консюмер одной или более amqp queue подцепленным к этому эксчейнджу + автоматический паблишер сообщений от клиента + описание транспортов до клиента.

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

Нельзя

Вернее говоря можно, но в рамках одного канала

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

господи

вот опять мне хочется бить себя ушами по лицу и кричать.

Не вижу в этом проблемы

Если бы была меньшая абстракция - пришлось бы делать то же самое

Потому что не было бы каналов

Сокет - это генсервер, который держит соединение с клиентом. На каждую «подписку на канал» от клиента он делает новый генсервер - канал

У одного сокета может быть несколько каналов

Канал получает сообщения из двух мест - сокета и пабсаба

Для сокета - handle_in

Для пабсаба - handle_out

У одного сокета может быть несколько каналов

но определяется это только в compile time

И отправляется в сокет либо пабсаб

Через push или broadcast соответственно

Все

В 5 сообщениях - вся логика вебсокетов в фениксе

но определяется это только в compile time

Типы каналов, которые могут быть - только в compile time. Фактическое их количество - по запросу с клиента

Это просто роутер

Хочешь без него - пихай все сообщения в один канал *:*

И всю логику туда же

Тогда получится n2o

Или вебсокеты cowboy

А ещё, для развлечения, можно сделать 2 сокета с разным транспортом

И всю логику туда же

какую логику

Бизнес логику

"канал - это как amqp exchange." вот это было неправильно

эксчейндж спрятан

Я не так силён в ampq

К сожалению

Да и exchange по-моему не в протоколе, а только в rabbit mq

на самом деле, плохая аналогия, сова не натягивается на глобус

Но вот как в фениксе - я тебе рассказал

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

Скорее всего хотели сделать изи чат

Получил сообщение от одного из клиентов - разослал всем

В принципе все остальные кейсы вообще не требуют роутинга и каналов как таковых

Но тогда можно просто взять cowboy

Пока я делал вебинары, я ощутимо хлебнул дерьма с пабсабами и мне сложно принять, что такой набор примитивов является достаточным и вообще приносит пользу. Это конечно bias, но всё же имеющий под собой какие-то основания.

@TTaraskin Для REST-интерфейса разница не чувствуется между cowboy-ем и n2o никак. Не удивительно, абстракция в 100 строчек, которая при этом не кастомизируется и всё равно переписывать с нуля - оставляет впечатление её отсутствия. В плане вебсокетов, ничего не могу сказать, документация и примеры у n2o, что я нашёл настолько скудные, что я предполагаю ( предположение), что на cowboy-е написать websocket server и минимальный ws client с нуля у меня получилось быстрее, чем я смог бы разобраться в n2o. Или точнее выяснить, что оно возможно снова что-то не то делает и нужно снова велосипедить самому.

В данном случае Plug показывает верх кастомизации(это преувеличение конечно), потому что даже если бы не было у плага нужных плагов, легко можно было бы написать нужный plug и изменить поведение, как и в каком порядке обрабатыватся. В случае с n2o - rest - выкидываешь rest, пишешь поверх ковбоя. Ну и остаётся ощущение, что пишешь на ковбое, а не на фреймворке, который должен что-то упрощать.

Я до опыта c n2o меньше ценил то, как хорошо сделан plug.

@TTaraskin Для REST-интерфейса разница не чувствуется между cowboy-ем и n2o никак. Не удивительно, абстракция в 100 строчек, которая при этом не кастомизируется и всё равно переписывать с нуля - оставляет впечатление её отсутствия. В плане вебсокетов, ничего не могу сказать, документация и примеры у n2o, что я нашёл настолько скудные, что я предполагаю ( предположение), что на cowboy-е написать websocket server и минимальный ws client с нуля у меня получилось быстрее, чем я смог бы разобраться в n2o. Или точнее выяснить, что оно возможно снова что-то не то делает и нужно снова велосипедить самому.

яхз что там может быть сложно с вебсокетами в n2o есть html-страница (или основа, где есть только доктайп и маленький js который устанавливает вебсокет с сервером), есть модуль, есть функция event(init) — она срабатывает когда вебсокет-соединение установилось — удобно актуальную часть страницы обновить или вообще отправить и есть функции event({client,{your_huita}}) которые обрабатывают ваши запросы с клиента, дергаем клиент с сервера wf:wire("js_huita"), wf:wire(wf:f("js_huita('~s');",[Var])) и дергаем сервер с клиента ws.send(enc(tuple( atom('client'), tuple( atom('your_huita') ) ))) ( тут же — querySource('huita_id'), bin("huita"), number(777) ) я понимаю что Максим и его команда доку пишут только на инглише, и сам я жаловался что примеров не слишком много (ясен пень хотелось бы побольше, и еще я нитик и местами дурак), но блоть... с хера не зайти в чат разработчиков n2o, не спросить? вам ответят на ваш выбор — на инглише, русском или украинском, продложат 2-4 варианта решения вашей задачи ... я многое могу понять, одно понять не могу — почему люди люблят ныть\страдать и не спросят совета\помощи в кого-то более опытного? корона не отвалится же, люди...

В данном случае Plug показывает верх кастомизации(это преувеличение конечно), потому что даже если бы не было у плага нужных плагов, легко можно было бы написать нужный plug и изменить поведение, как и в каком порядке обрабатыватся. В случае с n2o - rest - выкидываешь rest, пишешь поверх ковбоя. Ну и остаётся ощущение, что пишешь на ковбое, а не на фреймворке, который должен что-то упрощать.

да, в n2o по умолчанию рест маленький, я тоже пилил на ковбое с другой стороны — не рестом единым — для рест и голый ковбой ок c n2o — прицепил epgsql, узял js-хеш-роутер, и можешь шаманить на одной страничке что-угодно, кучу табов с кастомными хеш-адресами, удобное обновление-подзагрузка по вебсокетами, ммм... думаю для трейдерского бота с графиками и тд — вообще милое дело ну как и для игр ))

Всем привет! А подскажите как лучше сделать. Надо один раз в день в заданное время отсылать определённое сообщение. В итоге у меня получается два варината: либо через send_after мутить, либо в крон поставить вызов простенького скриптика с get запросом в контроллер феникса. Как правильно?

Мне GenServer + send_after нравится больше

есть ещё такое: https://github.com/erlware/erlcron

например так https://github.com/Kr00lIX/gen_worker

вау

Всем привет! А подскажите как лучше сделать. Надо один раз в день в заданное время отсылать определённое сообщение. В итоге у меня получается два варината: либо через send_after мутить, либо в крон поставить вызов простенького скриптика с get запросом в контроллер феникса. Как правильно?

Если нужно отправить ровно один раз в день, никто не гарантирует что твоё приложение проживёт день без рестартов и send_after сохранится.

это учтено в gen_worker

Если нужно отправить ровно один раз в день, никто не гарантирует что твоё приложение проживёт день без рестартов и send_after сохранится.

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

это учтено в gen_worker

Как решено?

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

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

во внешние источники историю запусков писать, проверять что был вызов *Костылинг*

не думаю что за этим должен следить сам механизм воркера

Скажите, а пихать в структуры поля, которые не предусмотрены в defstruct это моветон или обычное дело?

не думаю что за этим должен следить сам механизм воркера

Ну т.е. там это не может быть учтено