HabrКак я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге
Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат. Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой. Я разбирался с этим несколько месяцев. В итоге пришёл к трёхуровневой архитектуре кэша, которую и хочу разобрать. Это не теория — это код, который сейчас работает в продакшне. Покажу как реализовано, какие были тупики и какие решения оказались критичными.
https://habr.com/ru/articles/1033502/
#react_native #sqlite #кэширование #expo #мессенджер #drizzle_orm #мобильная_разработка #производительность #архитектура #telegram
Как я сделал трёхуровневый кэш сообщений в мессенджере на React Native — и что узнал по дороге
Уровень: middle/senior мобильная разработка, React Native, SQLite Стек: Expo SDK 54, React Native, expo-sqlite, drizzle-orm, AsyncStorage, TypeScript Что внутри: архитектура, код из продакшна, грабли,...
