У меня настроен API appsyn c, где пользователи могут просматривать информацию о продукте и добавлять их в «коллекции». При желании они могут настроить эти коллекции, чтобы уведомлять их об изменении информации о продукте в коллекции. На бэкэнде продукты хранятся в таблице DynamodB и регулярно обновляются службой, работающей на экземпляре EC2. Эти обновления выполняются с помощью прямых операций DynamodB, а не мутации appsyn c.
Я могу настроить лямбда-функцию, подключенную к потоку базы данных, которая будет запускать мутацию appsyn c, если необходимо инициировать подписку. Затем пользователь может подписаться на получение этих обновлений. Но затем я сталкиваюсь с проблемой:
Пользователь может иметь большое количество товаров в каждой коллекции, что делает нецелесообразным и дорогостоящим подписку на КАЖДЫЙ предмет в коллекции. Предпочтительным методом будет подписка на уровне коллекции или пользователя. Однако существует разрыв, поскольку мутации инициируются для каждого продукта, а не для каждого сбора.
Каков наилучший способ устранить этот пробел? Есть ли способ сделать так, чтобы подписка запрашивала коллекцию пользователя и представляла список идентификаторов продукта, частью которых должен быть результат мутации, чтобы уведомить? Должен ли я запросить все коллекции от всех пользователей, частью которых является продукт на стороне мутации, и вернуть их в виде списка? И то, и другое кажется неэффективным и может привести к проблемам с нумерацией страниц.
Любой вклад приветствуется.