vs Akaveche

[Mithgroth]

Hey,
since I'm already developing with MauiReactor, I'm thinking of switching to ReactorData too. Currently I'm working with Akaveche to store my local data, but I'm manually managing the initial loading. Loading during app build is a good selling point for me. Also since Akaveche is heavily async-focused, it leads to awkward situations to use it during OnMounted() and I'm not super fond of doing async voids all over.

A few points I'd like to ask:

1. Akaveche can target LocalMachine, UserAccount, Secure, InMemory locations of the device, so I don't really need to set a target location. This is pretty handy, and in many cases helps you organize what you are storing. I like having tokens and user information in UserAccount, sensitive information in Secure so I don't need to worry about it and my app's own data in LocalMachine as transient storage. Could ReactorData implement this pattern?
2. Does ReactorData get removed by linker? I suppose AddReactorData takes care of that?
3. The most important point for me: Is it possible to implement AbsoluteExpirationDate for entities? I suppose calling VACUUM on SQLite on app start should do the trick, not entirely sure though.
4. Although I'm currently not using it, Akaveche's GetAndFetchLatest sounds like a good addition on paper. I suppose ideally it should work with a delegate to a some fetch call with Refit / HttpClient / gRPC call?

Hoping to see more of MauiReactor stuff,
Cheers man.

[adospace]

Hi, first of thanks for your interest in MauiReactor and ReactorData.

MauiReactor is battle-tested and I used it (including the Xamarin Forms version) in the last 4/5 years and works great IMHO.

ReactorData is pretty new: I created it in the last few weeks, I've used it in some sample applications built in MauiReactor but never so far in a production app this is why is still in beta.

Said that I want ReactorData to succeed because it's so beautiful to work with it: everything flows naturally that I almost forgot how/where/when to save data: I just put entities in the container and I'm notified when entities are loaded/changed and only for those entities that are relevant to the current view.

This is why just this week I'm starting a new big project for my client that will use MauiReactor+ReactorData (EF Core) with a complex database.

I never used Akaveche before but from what I see is more like key-value cache storage while ReactorData aims to handle full-blow entities with related entities that can be queried (like SwiftData).

Back to your questions:

1. Right now in ReactorData you have only one IModelContext for the entire app registered as singleton this means you have to decide only one location to store your data. This is going to change shortly because I'm going to allow you to define more than one context each with its storage. This way one could define different IModelContext with different purposes and levels of security in the storage: the overall process could be similar to Akaveche approach.

2. To avoid this I think it would be enough to call SQLitePCL.Batteries_V2.Init() somewhere before access sqlite (I believe that when using ef core->sqlite it automatically does that under the hood) and yes AddReactorData should take care of that.

3. Reactor data doesn't have the concept of AbsoluteExpirationDate: right now entities are always kept in memory inside the context after they are loaded.
   You'll have 3 options to avoid to keep entities in memory for longer than what you actually need:

   1. Using a scoped context. Already implemented and shown for example here https://github.com/adospace/kee-mind/blob/main/src/KeeMind/Pages/EditCardPage.cs
   2. Creating a new context with its storage. As said above it will be possible to create contexts at runtime, entities loaded inside it will be freed as the contested is recycled.
      Of course, the storage could optimize the space occupied. For example, the sqlite storage could execute a VACUUM after deleting a lot of records.
   3. Create a background service that regarly on background removes expired entities from the context.

4. Ok this is something I thought to realize differently in ReactorData (given I've understood correctly the GetAndFetchLatest).
   The idea in ReactorData is that you could use whatever you want/need to fetch entities (for example an HTTP call etc) and load the entities in the container using the method IModelContext.Load<T>(...).

   For example, in the app I'm working on I've a background thread/service that with a custom logic (every 10 minutes, or when the network is online again or after receiving a command from the UI) calls a few remote endpoints in REST, download the entities and just call the IModelContext.Load() with them: the UI will receive the updated entities according to the query it has defined.

   Consider another example, an email client.

   1. The app creates an IQuery over the Message entities, defining the order and the limit (for example take only the most recent 50 messages).
   2. Messages are shown in a CollectionView linking it to the IQuery
   3. A background task fetches all the latest messages from the server and loads them in the IModelContext
   4. The CollectionView is automatically updated.

[tonyyip1969]

@adospace , I really like how the ReactorData works, hopefully it will be released from beta soon.

[adospace]

Hi thank you for your interest, consider that it is still in beta for a couple of reasons:

1. the API surface could change a bit during the beta stage
2. still need some feedbacks for iOS/Mac platforms

Apart from that it's in production now for 2 of my clients since June, so it's pretty stable.