но в целом - идея очень крутая

джва года ждал что-то такое:)

А вы бы что предпочли, если не секрет?

Для общения есть же рэббит

1. возможность выбирать хранилище для общей очереди задач (naive js, redis). дополнительно к этому - какое-то api для отслеживания текущего статуса (список акторов, кто вызвал, что вызвало, где находится, в идеале - сколько ресурсов использовало). мне лично это очень нужно для прогнозирования и автоматического скейлинга (внешнее api, хуков или подписки какой-то достаточно): есть большое количество тяжелых вычислений (минуты, иногда часы), возможна резко возрастающая нагрузка, которую хотелось бы обрабатывать (развертывая/удаляя доп.сервера) за минуты простоя. Да, к сожалению, там нужны акторы, простой task queue не подходит.
2. api для автоматического добавления/удаления нод, в идеале - докер-контейнер, которому просто указываешь адрес сервера оркестрации, а дальше он сам в нем регистрируется, трекается, отваливается, респавнится и так далее. Но это идеальные условия, я понимаю
3. безопасный протокол общения между серверами (мастхэв, понятное дело)
4. возможность передавать structured clone (с автореферентными ссылками) и поддержкой классов для де/регидрации (условно, зарегистрировать класс User с методами toJSON/fromJSON). Но это уже хотелка, впрочем, ее сделать не очень сложно

Пока есть только пункт 4. Понял, спасибо!

structured clone тоже есть?

а, еще забыл. п.5 - хотелось бы задавать возможность раскидывать задачи по random/round-robin/least connections

настраивать

кстати, оффтоп: будете выбирать amqp-библиотеку то увидите что из существует всего 3 под ноду, и все со своими косяками

вообще я свое что-то такое думал в свое время писать, так что если будет время (увы, вряд ли), попробую подключиться к проекту

поэтому, если вдруг это поймете, приглядитесь к этому транспорту - он неплох :) https://github.com/microfleet/transport-amqp

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

Ага. В Comedy это называется  custom marshalling. Добавлю в доку в ближайшее время.

круто

> так а зачем aqmp, если на редисе можно накостылять то же самое с более внятным перформансом?
для продакшна redis pub/sub не подходит по определенным причинам:
1) там кластер сложнее создать, а single point of failure это моветон
2) нет кучи полезных вещей раббита: dead-letter-exchange, например
3) ну и вообще он заточен все таки на KV

то есть там таки негарантированный pubsub

окей, мне на кролика много кто жаловался

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

и говорили, что на list редиса все куда удобнее делать