felangel
feat(hydrated_bloc): Isar instead of Hive for storage
Description
Hive has an issue with high RAM usage, no support for queries and less than desirable performance for complex data [1], which in my opinion fits the purpose of hydrated_bloc. Recently a complementing library to solve these issues from the same author (@leisim) got released into stable, and it's called Isar [2]. For now, it comes with two primary downsides: it is still quite young, the web support is to (soon™).
Desired Solution
Hive is replaced with Isar as the main means of dealing with cached storage within hydrated_bloc.
Alternatives Considered
Hive alternative Objectbox [3] is not written in Rust (unlike Isar), thus any memory, undefined behaviour and concurrency related bugs will be present in higher amounts and will be harder to spot even for experts since it's inherently harder to setup for safe reliable code. However, it comes with a variety of interfaces to other languages, e.g. Kotlin and Swift.
Additional Context
[1] https://github.com/hivedb/hive/issues/246 [2] https://github.com/isar/isar [3] https://github.com/objectbox/objectbox-dart
Hi @ac130kz 👋 Thanks for opening an issue!
I'll take a closer look at Isar now that it's stable to evaluate if it makes sense to make this transition.
My initial reaction is to compare performance between Hive and Isar (are you aware of any official benchmarks?) and to create a small p.o.c.
My main concern is it looks like Isar doesn't support web whereas Hive does. Also, Isar relies on code generation so hydrated_bloc would likely also require developers to run build_runner which is a disadvantage when compared to Hive in my opinion.
I'll drop some more thoughts/comments once I've taken a closer look at Isar and the level of effort to migrate to it but feel free to add your thoughts in the meantime, thanks! 🙏
@felangel I guess as a temporary performance measurement Objectbox's benchmarking suite can be updated to support the latest version of Isar [1]. As for the build_runner, I think it might not be such an issue, fingers crossed static metaprogramming in Dart will help in this regard within a couple of months [2].
UPD: found a mention of preliminary benchmarks by @leisim on Reddit [3].
[1] https://github.com/objectbox/objectbox-dart-performance [2] https://github.com/dart-lang/language/issues/1482 [3] https://www.reddit.com/r/FlutterDev/comments/rti7sk/stable_version_of_isar_database/hqt6geg/
@felangel I guess as a temporary performance measurement Objectbox's benchmarking suite can be updated to support the latest version of Isar [1]. As for the build_runner, I think it might not be such an issue, fingers crossed static metaprogramming in Dart will help in this regard within a couple of months [2].
UPD: found a mention of preliminary benchmarks by @leisim on Reddit [3].
[1] https://github.com/objectbox/objectbox-dart-performance [2] dart-lang/language#1482 [3] https://www.reddit.com/r/FlutterDev/comments/rti7sk/stable_version_of_isar_database/hqt6geg/
That still doesn't address the lack of web support and I agree that static metaprogramming will likely help with codegen; however, it feels premature to make this change given the current state of things. I think it'd be nice to revisit this in a few months.
Isar now supports Web https://pub.dev/packages/isar/changelog#220 but I also think it's still too early 😛
Isar vs Hive
The answer is easy: Isar was started as a replacement for Hive and is now at a state where I recommend always using Isar over Hive.
Isar vs Hive
The answer is easy: Isar was started as a replacement for Hive and is now at a state where I recommend always using Isar over Hive.
Which contridicts with
(src https://github.com/hivedb/hive/issues/246#issuecomment-997182092)
Isar, having it's core implemented in Rust needs to bundle a priori a non dart binary.
This makes the whole dependency chain much more complex, which may fit heavy lifting cases however I would aruge does not fit the general purpose library use case of bloc.
IMHO switching would be a bad call.
As an alternative, either staying with Hive or using shared_preferences seem like viable options.
needs to bundle a priori a non dart binary
Given the size of Flutter libs alone, it is not an issue.
using shared_preferences
It's not a performance oriented approach, while Hive itself is barely maintained.
I believe it's the time to move with isar or SQLite via drift.
What about removing all storage implementations from hydrated_bloc itself and just offering different options as separate packages?
I don't think that there is a one-size-fits-all approach to this.
What about removing all storage implementations from
hydrated_blocitself and just offering different options as separate packages?I don't think that there is a one-size-fits-all approach to this.
How would that be an improvement over the current version? You can already create your own custom storage implementation and we'd likely still want a default implementation that is generally a good fit for the most common use-cases.
My worry is that I don't want to ship the full hive package just for hydrated_bloc. However, maybe I'm just victim to my ignorance whether the tree shaking algorithm is good enough to get rid of it if I use my own custom storage implementation instead.
My worry is that I don't want to ship the full hive package just for hydrated_bloc. However, maybe I'm just victim to my ignorance whether the tree shaking algorithm is good enough to get rid of it if I use my own custom storage implementation instead.
I believe tree-shaking should take care of it but feel free to open a separate issue if that's inconsistent with what you're observing.
Is there any update on this?
Otherwise, I'll try something. I'm diving deep into this storage rabbit hole.
