TGViewer
There will be no singularity There will be no singularity @nosingularity · 1.95K subscribers
Post #206 241
​​В @ctodaily обещал рассказать про микросервисные фреймворки на nodejs.

Как-то давно у меня был опыт использования фрейморка поверх rabbitmq и это было довольно удобно. Оказалось, есть еще более интересные решения и это - микросервисные фреймворки.
Точкой входа послужил вот этот benchmark: https://github.com/icebob/microservices-benchmark
Естественно, мне захотелось побыстрее и я взял cote ) Да и seneca c moleculer показались более мудреными.

Казалось бы - зачем они нужны? Берешь express и делаешь что хочешь. Но микросервисные фреймворки берут на себя довольно много рутины.
1. Discovery Service. Несколько запущенных микросервисов должны уметь находить друг-друга
2. Message Queuing. Передача сообщений в режиме многие-ко-многим. Если запущенно несколько инстансов сервиса, который получает задачи на выполнение, в большинстве случаев нам хотелось бы, чтоб каждый инстанс получал свое собственное задание и только один раз.

Для реализации этих функций фреймфорки могут использовать redis и nats, но самое интересное что cote умеет обходится без этого. Он основан на библиотеке https://github.com/tj/axon и умеет решать все проблемы по UDP и через мультикаст.

Стартануть на cote можно буквально за 5 минут и это подкупает.
В одном репозитории можно создать 2 части сервиса - http интерфейс и worker’ы. Например, мы хотим по запросу в апи спарсить данные из нескольких источников. В одном репозитории мы имеем и express и парсеры, сделанные как cote.Responder, но при запуске контейнера указываем роль с которой он запускается - http-сервер или парсер и если парсер, то парсер чего именно. В итоге парсеров мы можем поднять нужное нам количество, контролируя это через k8s, а точкой входа будет обычный express роутер.
Так очень удобно разрабатывать. Все типы и классы лежат в одном месте, а логика скейлинга лежит на k8s.
Кроме того, проблемы с роутингом и очередью сообщений нас больше не волнуют.
И да, он очень ООП-френдли и собственные Requester и Responder удобно наследовать от cote-классов.

Тестировать, кстати, оказалось тоже очень удобно. Локально, без всяких микрокубов можно протестить и отдельные Responder’ы и работу всей цепочки микросервисов, запущенной раздельно.

UDP и мультикаст имеют свои темные стороны )
1. можно забыть про service mesh.
2. можно забыть про реализацию микросервисов на других языках с использованием cote. Все внешние взаимодействия придется делать через express.
3. с повтором отправки придется все-таки разбираться самостоятельно.
4. статистику взаимодействий тоже придется пилить самостоятельно. Но для этого есть инструменты.
5. SRE будут вас слегка ненавидеть, когда будут впиливать это в k8s )

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

Для одной конференции я готовил доклад про микросервисы в nodejs, но доклад не случился ( Оформлю и выложу его лонгридом.
More from @nosingularity
  1. Sep 19, 2026fixupx.com/KaiLentit/status/2100629518784328013/video/1
  2. Sep 18, 2026fixupx.com/iam_zachi/status/2100679300756435135
  3. Aug 30, 2026photo post
  4. Aug 25, 2026fixupx.com/meganreyno/status/2091918430374957416
  5. Aug 3, 2026Вышла новость, что Andy Pavlo приняли на борт Clickhouse Inc. Энди довольно известная фигу…
  6. Jul 23, 2026fixupx.com/unclebobmartin/status/2080257779395154409
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →