Р
Разработка Riseonly
@nicsbar345 подп.
250просмотров
72.5%от подписчиков
15 февраля 2026 г.
stats📷 ФотоScore: 275
День 616 | Разработка социальной сети Хай всем, чет реально долго не было поста, лан сейчас быстренько расскажу по обновам что было сделано, могу что то пропустить так как реально много мелких фич и тд но лучше скажу самое главное ================ Backend: Реакции: Завел message_reactions в Scylla, кто какую эмодзи на какое сообщение поставил. Отдельные таблицы под непрочитанные реакции для автора, чтобы при заходе в чат он видел всё и мог отметить прочитанным в дальнейшем. Чтобы не джойнить при каждой загрузке сообщений, агрегируем реакции по сообщению и денормализуем прямо в само сообщение, при get_messages уже всё прилетает готовое. add_reaction и remove_reaction пишут в таблицы, инвалидируют кэш, шлют событие в Nats, notify-service подхватывает и пушит автору. В каналах непрочитанные реакции не делаем, там другая логика. В общем теперь всё как надо. --------- Упоминания: Только в групповых чатах. Когда юзер кого-то тегает через @ник, надо это вытащить, записать кому непрочитанное упоминание, и чтобы при отметке прочитанным не лазить по всей базе. Два способа вытащить кого упомянули: либо клиент присылает разметку entities с user_id, либо парсим текст по @ и резолвим ник через user_service. Пишем в message_mentions связь сообщение–юзер, в user_unread_mentions_by_chat список непрочитанных с пагинацией, в user_unread_mention_lookup быстрый лукап при mark as read. При удалении сообщения чистим всё по всем упомянутым. События user_mentioned летят в Nats, в notify уже заготовлены тексты под пуш "тебя упомянули", осталось только подписаться --------- Загрузка изображений и видео по кускам: Думаю видели уже ролик выше постом, теперь файл не шлём одним куском, а на клиенте режем на слабы по 64 КБ (ChunkedUploadManager.SLAB_SIZE) и шлём последовательно с Upload-Id и Part-Number. Сначала initiate через POST /api/file/upload/initiate получаем upload_id и chunk_size с бэка. Дальше в цикле uploadSlab каждый кусок уходит на PUT, на бэке это копится и собирается в S3. onProgress вызывается после каждого успешного куска с percentage и stage (initiating, uploading, completing), по ним рисуем прогресс в оптимистике в том же месте где создаётся сообщение или пост. В конце complete upload, с бэка прилетает upload.completed с file_url, подставляем в темповые данные и всё. Если загрузка в рамках optimistic update (например сообщение с медиа), прогресс файлов как раз pathInTempData и показываем по очереди кто сколько уже загрузил. Удобно и стабильно по плохому интернету. На мобилке видео/изображение сжимается само, и только потом уже отправляется кусками на сервер, но мы всё равно, когда получаем фулл изображение или видео, делаем внутреннее серверное сжатие, потому что могут быть дауны, которые захотят обойти эту систему и начать загрузку уже без мобилки, тоесть без клиента, но они отсосут, потому что будет не только клиентское, но и серверное сжатие :)) При получении уже сжатой медии, серверное сжатие не сильно делает его хуже, поэтому всё норм
250
просмотров
2992
символов
Нет
эмодзи
Да
медиа

Другие посты @nicsbar

Все посты канала →
День 616 | Разработка социальной сети Хай всем, чет реально — @nicsbar | PostSniper