-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Демон для обработки очереди
- Автор темы grigori
- Дата начала
В npm допустили все ошибки, какие только можно допустить, проектируя репозиторий, это да. Но уже лучше намного.
Yarn ок, почти нормальный, им бы еще их дурацкую эвристику на нормальный SAT solver заменить, и будет прям composer. (Удивительно, что сразу его не сделали, фейсбук же, зря что ли на собеседованиях по алгоритмам всех гоняют?
)
Yarn ок, почти нормальный, им бы еще их дурацкую эвристику на нормальный SAT solver заменить, и будет прям composer. (Удивительно, что сразу его не сделали, фейсбук же, зря что ли на собеседованиях по алгоритмам всех гоняют?
)
Ну он у нас не лишний — у нас клиенты с разными протоколами (tcp/zmq) сводятся к одному общему обмену по хттп.
Мне честно говоря, полная асинхронность кажется лукавством, просто потому что бизнес-логика более-менее сложного процесса обычно довольно линейная. Да, можно какие-то простые вещи готовить и отдавать клиенту асинхронно, какие-то независящие друг от друга операции паралеллить, но в конечном итоге на более-менее сложной бизнес-логике в тру-асинхронном подходе ты просто получишь unmaintainable callback hell. Поэтому асинхронным мы стараемся делать то, от асинхронности чего есть явный понятный профит — как например, сетевые соединения обслуживать, или большие наборы данных отдавать. В случае с бизнес-логикой поддерживаемость и понятность кода куда важнее. (И тестируемость! вы пробовали тестировать асинхронщину?))
PHP:
$foo->myevent( function($val) use ($unit) {
$unit->assertEqual(42, $val)
});
$bar->trigger('myevent', [42]);Смотря что понимать под асинхронщиной.
Если говорить о классическом libevent style коде с пачкой колбэков, то, конечно, сложность его поддержки должна быть оправдана. Это действительно адок.
А если язык/библиотеки/фреймворк позволяют с ней работать так же легко, как и с синхронным кодом, то не вижу вообще никакой разницы - при этом имеется весь профит от мультиплексирования.
Если брать за пример современный JS или Typescript, то вся асинхронщина изолируется в асинхронных функциях, на уровне инфраструктуры и http-слоя. Работа с асинхронным кодом в асинхронных функциях выглядит ровно так же, как и с синхронным - просто добавляется "магическое" ключевое слово await. Ну и, конечно, там где-то есть return new Promise, но это все в 99% случаев исходит изнутри библиотек (датамаппера, сетевого клиента итд), вручную почти никогда не надо писать. При этом если в каком-то месте надо действительно распараллелить - именно в этом месте уже можно поработать с пачкой promise-ов и опять же свести к return promise, на который выше будет await. В общем, в том же nestjs код практически не отличается от обычного синхронного - просто добавь async / await. (UPD: с тестами - ровно так же. async ... expect(await foo()).toBe(bar)).
Слой domain model при этом, разумеется, синхронный - в нем ведь нет никакого io, зачем это там? Проблемы тут будут, только если использовать паттерн ActiveRecord, или иным образом смешивать domain layer с инфраструктурой. А не надо так делать.
Еще может быть проблема с интенсивными cpu операциями, с тяжелыми вычислениями. Но это крайне редкий случай, тут с любым подходом будут свои проблемы, которые сами по себе не решаются вне зависимости от.
Последнее редактирование:
интенсивные по CPU операции выносятся в backend и решаются или через map/reduce, или очередью, или уменьшением точности, но это уже совсем не про ноду
а вот для чего нода лучше - пока вижу только websocket-ы
в middleware получается классический tradeoff: сложнее деплой, сложнее дебаг, сложнее управление памятью, нет overhead на инициализацию приложения на каждый запуск
а вот для чего нода лучше - пока вижу только websocket-ы
в middleware получается классический tradeoff: сложнее деплой, сложнее дебаг, сложнее управление памятью, нет overhead на инициализацию приложения на каждый запуск
Последнее редактирование:
возвращаясь к теме фоновой обработки, https://12factor.net/concurrency
HTTP requests may be handled by a web process, and long-running background tasks handled by a worker process
я просто не понимаю как в ноде устроить взаимодействие между web process и background workers
в php - тоже не очень понимаю,
в golang и python - понимаю
HTTP requests may be handled by a web process, and long-running background tasks handled by a worker process
я просто не понимаю как в ноде устроить взаимодействие между web process и background workers
в php - тоже не очень понимаю,
в golang и python - понимаю
Ну у тебя в любом случае это будет +1 слой в архитектуру, так или иначе.
Вариантов в принципе, не так уж много, и они в основном такие же, как в других языках.
1. Полноценная очередь c ack пакетов: ZMQ, Gearman, RabbitMQ, Aws SQS, Redis pub-sub, pure-database и тд. Дополнительным бонусом тут language-agnostic исполнители — надо на питоне обработчик написать, или на го — взял и написал.
2. Асинхронщина с евенлупом создающая задачи, и отдающая их, и синхронщина спрятанная по http, где мультиплексацией занят нджинкс. Плюсы — за хттп стоит знакомый стек и программисты по писят рублей ведро. WEB SCALABLE!1
3. Форкаемся прям в пхп, обмениваемся данными через tcp-/unix-сокеты, shm, или кем-то из 1 пункта. Плюсы — кодовая база вся в одном месте.
4. Ваш вариант.
Gearman не течет. Redis не течет.
Да вроде для всего перечисленного есть поддержка всего подряд. Насчет всякой экзотики типа винды не знаю, конечно, но вряд ли тебя это волнует.
гугл ничего не находит по "rabita php", что такое рабита?
https://www.rabbitmq.com/ извини за сленг )