в чем вопрос?
вопросы есть по ней 1) потянет ли высоконагруженный чат? 2) хранит ли кэш в памяти? 3) есть ли выборочная синхронизация, например истории отдельных чатов и списка чатов, а не всего сразу? 4) если память на диске кончится продолжит ли работать приложение? 5) Подписчики получают изменение до записи в базу или уже после? 6) Работает через бридж или JSI?
1 - что значит потянет? 2 - не помню 3 - нет, идет синхронизация через pull & push, но вся логика в твоих руках, можешь во время синхронизации что то откидывать 4 - не знаю что и написать 🙂 5 - если ты имеешь в виду реактвиность, то да, через идет подписка на изменея в базе и реакция UI 6 - JSI
1 - значит если у меня 1к чатов и приходит по 100 сообщений в секунду приложение не *бнется все это в базу писать? 5 - имею ввиду там медленно приходят обновления подписчикам (уже после записи в базу) или быстро (как только изменение мсержилось с кэшем в памяти например, до записи в базу)
1 - если нативная sqlite база не сможет справится, то не знаю что тут сможет с этим справится 5 - я так понимаю идут обнлвения UI после записи в базу
1 - можно например работать с оперативкой, тогда точно нет проблем. а в базу писать уже после
тут не скажу, я в такие подробности не лез, тебе лучше посомтреть их документацию, как оно внутри работает
так вот документация у них не отвечает на эти вопросы к сожалению
тогда остается путь в исходники ))
если вдруг узнаешь подробности, то отпиши плиз - самому интересно
как и обещал https://github.com/Nozbe/WatermelonDB/issues/1351 но болото свое они защищают знатно)
Да вроде ответы по делу, кеш для offline-first приложения и база данных (изначально и только офлайн) - это разные слои, у них разные задачи, и совсем не обязательно они будут в одном и том же решении. Как, например, redux и redux-persist, два отдельных модуля, причём последний в принципе абстракция над разными хранилищами, реализующими один и тот же интерфейс/api (localstorage) То что это как-то реализовано у firebase - в целом логично, потому что они изначально предоставляют не только локальную базу данных, но и онлайн-хранилище, с которым эти данные должны синхронизироваться, поэтому какой-то вариант реализации подобного функционала они нашли.
«просто база» это sqlite, а они строят целый фреймворк с подписками на изменение прямо из компонент, но без глобального кэша в памяти
у них там firestore вообще монстровый монстр с кешем и реалтаймом из коробки)
так так и надо делать) а не базу дисковую с подпиской
каждый будет охранять свое болото)) так к какому ты решению пришел?
redux + redux persist на первом этапе, далее оптимизация redux-persist (он неэффективный) либо своя реализация, в идеале на sqlite + jsi
Вопрос спустя год. В итоге ты выбрал watermelondb? Если да, то 1) справилась ли с твоими кейсами? 2) какие еще альтернативы рассматривал?
а я отвечал дальше почему это фуфло полное
Обсуждают сегодня