Я создаю приложение с очень похожим пользовательским интерфейсом, таким как Twitter, с возможностью добавления / добавления избранных сообщений, используя реакцию для клиента и конечную точку API.
Сообщения приходят из разных источников, в том числе внешних, поэтому для целей этого вопроса, скажем, Youtube видео и статьи.
Поскольку сообщения поступают из разных источников, не обязательно хранятся в локальной базе данных, эти "лайки" хранятся в двух таблицах.
Таблица 1 представляет собой таблицу «Like Resource», в которой хранится тип сообщения, например, ' video ' и его идентификатор, например ' 2DFlghK1iuZz ', что-то вроде следующего:
TABLE `likes_resources` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`type` varchar(255),
`identifier` varchar(255)
)
Таблица 2 - это таблица фактических данных, которая хранится в отношении ресурса и пользователя, примерно следующее:
TABLE `likes` (
`like_resource_id` int(11),
`user_id` int(11)
)
Эта настройка отлично работает для лайков и лайков, а также для публикации лайков по почте или по пользователю.
То, с чем я борюсь, - это самый эффективный способ выделения сообщений, которые понравились пользователю при просмотре основного канала, который бесконечно прокручивается так же, как канал Твиттеров, без вытягивания потенциально огромного списка всех сообщений, которые понравились пользователя и сравнивая его с сообщениями, которые в данный момент отображаются в ленте.
Сначала я хочу опубликовать список видимых элементов канала в конечной точке API, которая затем возвращает список всех понравившихся элементов из этого списка, чтобы их можно было выделить как таковые.
Кажется ли это разумным способом достижения этой функциональности или есть лучший способ?