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

как показывает практика в скорости разработки не особо выиграваешь даже разрабатывая простенькие сайты на том же ruby вместо elixir

Выигрываешь, если ты можешь взять готовый wordpress и склепать все из плагинов или писать всё с нуля на Elixir-е.

ну это уже совсем другое программирование

Но вот что касается maintaining-а, я один такой сайт вначале склепал на каком-то готовом Ruby фреймворке билдере, но вовремя мейнтенинга, он, как оказалось, долго грузился и почему-то отваливался раз в месяц-полтора без понятной причины, так как некоторые функции оказались не нужны, я потом чисто чтобы было проще мейнтейнить переписал всё на Elixir-е. Это было дольше в плане разработчки(даже с учётом того, что я Ruby не знаю, а Elixir мой профессиональный язык), с потерей функциональности(которую и так никто не использовал), но сайт стал раз в десять грузиться быстрее, а о мейнтейнинге я и забыл - просто работает.

@kr00lix А простенькие сайты обычно и попадают под такую категорию, где можно сделать из какого-нибудь билдера, просто где нужно понаставляв своих php/ruby/(что ещё популярно?) скриптов.

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

кто может обьяснить суть umbrella проекта

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

apps app 1 app 2 запускаю mix phx.server из общей папки

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

да

допустим я делаю app1 API а app2 client запускаю из общей папки, они оба запускаются?

да

по сути просто удобное разделение на папочки?

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

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

можешь это представть как кучку микросервисов, которые запускаешь разом

хорошо

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

или все это будет собираться в один release (ERTS)

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

надо поднять

Ребят, кто шарит в RabbitMW

Можно подписаться на топик по шаблону?

Типа users.#

Чтобы получать от любого юзера

сообщения

Да, в манах RabbitMQ надо найти про типы exchange и про биндинги к очередям

Можно подписаться на топик по шаблону?

да, они для этого и придуманы там в доке есть примеры, правда для эликсира нет примеров нормальных https://www.rabbitmq.com/tutorials/tutorial-five-python.html

Это не то

Мне надо не послать в любую очередь

А забрать из любой

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

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

А не чтобы продьюсер пушил во все очереди по шаблону

Вот в том то и дело, что походу нельзя

Но как сделать тогда

Ну. Создается exchange, вроде с типом topic. Туда шлются сообщения с routing keys типа user.regular, user.admin. Создается очередь, куда биндятся все сообщения user.* из exchange

В манах ищите routing. Все можно

Еще рез прочитай что я написал

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

Вооот

может быть эту информацию дополнительную передавать в заголовках и гнать в одну очередь?

Обрабатывать будет пул консьюмеров

Но я хочу каждую очередь по очереди

В rabbitmq понятия очереди и routing key - это разные вещи. Чтобы связать очереди и exchange используются биндинги. Конфигурации могут быть разные. Это называется routing.

непонятно что значит «каждую очередь по очереди»? асинхронная же обработка

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

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

тут же из условия ясно

И в один тред :)

Честно говоря, когда очереди разные не очень понятно как это сделать,

Но каогда очереь одна - совсем не понятно

а зачем они разные? если туда только заливается информация, а для чтения нужна одна?

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

Ну и если пихать в одну очередь - то как проверять что предыдущее сообщение не обработалось - совсем не понятно

Потому что они в одной куче

одним консумером обрабатывать

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

Так вот в том то и беда

Может мне не rabbit нужен

Хз

Мне нужно все наоборот

Чем сделано в rabbit

ну похоже надо то что тебе не совсем брокеры очередей нужны

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

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

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

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

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

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

Мне по сути нужна "обратная связь"

опять же за слоем сложных консумеров можно уже мелких с RPC насовать

Т.е. мне нужно лочить очередь

А сделать все в одной не получается по этой же причине

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

дай пример из нескольких действий

и как хочешь обрабатывать

Ну вот 5 юзеров 10 воркеров пул У каждого юзера - по 10 сообщений Сперва 3 первого, потом по очереди чередуясь все остальные Я хочу чтобы на первые 5 воркеров попали сообщения от юзеров - от каждого на свой воркер. А вторые 5 воркеров стояли и ждали, потому что я не сказал,что закончил с первыми сообщениями. Как только я закончу работу - очереди анлочатся, и приходит следующее сообщение от юзера на любой свободный воркер

НО! Если я запихну все в одну очереь, то первые 3 сообщения заблочат все, потому что они относятся к одному юзеру

И я за ними не увижу, что могу параллельно обрабатывать 4 других юзеров

Ну и ясно, что юзеров может быть не 5 а 5к

И все это как-то по roundrobin должно разгребаться на тех же 10 воркерах

нене, вот смотри как я вижу: надо обработать юзера, например, там 3 действия: 1. обработать фото 2. сохранить в БД 3. отправить о регистрации сообщение кому-то я вижу что ты сразу шлёшь эти задачи в разные очереди и хочешь чтобы они сработали все вместе или ни одно?

Причем из 5к юзеров активными могут быть только 5 последних

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

и если они не сработали - зафейлит работы

тогда параллелизация будет на уровне больших задач вида «добавить юзера"

не?

У меня это и так большие задачи

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

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

Тогда она одна единственная и большая

и растянута по времени

Вот он по ссылкам переходит - я генерирую события

Мне важен порядок переходов

А сколько он на странице провел - 10 минут или секунду

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

И вот к примеру я хочу мини нейронку пересчитать

На каждое действие