А, Вы имеете в виду операции непосредственно с тегами, а не присваивание тега продукту? Так как присваивается обычно один за раз.
Я в примере рассматривал только API присваивания

Ясно тогда

+1

Объявлю тут

+1

Я юзаю. Норм тема.

Здравствуйте, а как на них можно записатся?

Колеги привіт
Питання по Node.js+MQ
Чи є "бест пректіс" по обробці повідомлень?
Чи використовуєте додаткові бібліотеки для зручної обробки? RxJS чи щось інше?
Дякую

А какую книгу порекомендовали? (Название)

Для БД:
Database Design for Mere Mortals (Michael J. Hernandez ),
Pro Sql server Relational Database Design and Implementation (Louis Davidson),
SQL Cookbook: Query Solutions and Techniques for All SQL Users (2020)
Автор: Anthony Molinaro, Robert de Graaf

Для Node:
Node.js Design Patterns (Mario Casciaro, Luciano Mammino)

Спасибо

Кто-то использует какой-то меседж брокер? Типа кафки, реббита? или что-нибудь еще?

Скажем, у вас есть система нотификаций (предположим, по типу уведомлений в фейсбуке - где они могут прилетать вам на мобильный клиент, на открытый браузер, и, скажем, в СМС).

Использовали ли бы вы какой-нибудь меседж брокер для этого? И есть ли определенные бенефиты с этого?

В моей картине мира я могу просто добавлять в основную БД в так называемую таблицу очереди нотификации (с соответствующей destination point), ну и отдельным микро сервисом “подписаться” на новые поступления ивентов в очередь и просто рассылать их. Ну и в общем схема проста как фанера.

ну и БД (та же PSQL) может выдержать нууу… миллионы записей в день в БД.

Но интересен свежий взгляд со стороны

используем EMQ X - mqtt брокер. Профит есть - удобно горизонтально масштабировать, есть retained и QOS.

подписаться на таблицу в БД - это имеете в виду дергать ее каждые N секунд и смотреть нет ли мессаджей? Или используя LISTEN/NOTIFY постгреса?

Первое плохо тем, что вы дергаете таблицу даже тогда когда нет новых мессаджей.
А listen/notify - могу ошибаться, но кажется если пришло сообщение, а сервер в этот момент перезапускался и не «услышал» его - то сообщение потеряно.
В очередях (rabbitmq) сообщение хранится пока сервер не поднимется и не обработает, т.e. не теряется если слушатель down

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

Благодарю, почитаю о EMQ X

Вопрос по НодСтартерКит, исходя из того что я увидел в коде, там показан пример «запрос-ответ», а что если клиент хочет подписаться на постоянный поток. Я допустим использую редис, там есть паб/саб. И допустим таких желающих будет скажем 200 из 1000. Остальные делают просто запрос ответ. А вот 200 человек сделали запрос на получение данных. Я так понимаю под них надо выделить отдельного воркера и чтобы он постоянно делал сенд в сокет. И получается что для этого надо сделать хранилище с роутом и клиентами? и как только будет событие, перебрать мап с соединениями и сделать сенд?

Может не в ту сторону, но если скейлить нужно, то смотрел в сторону aws sqs?
Можно добавить триггер, чтобы лямбда поднималась при новом ивенте и делала свою работу

у нас на этом пол проекта построено )