How is this library different from another mmkv?

[Kiura]

How is this library different from another mmkv react-native library?

https://github.com/ammarahm-ed/react-native-mmkv-storage

[azeeka]

As far as I know, react-native-mmkv-storage supports encryption:

Full encryption support
The library supports full encryption on Android and iOS. You can choose to store your encryption key securely for continuious usage. The library uses Keychain on iOS and Android Keystore on android (API 23 and above). On android for lower api levels (API 22 and below), it uses secure prefrences which provides not perfect but incremental security on older Android APIs.

[mrousavy]

Originally there was only react-native-mmkv-storage by ammarahm-ed, which was a legacy bridge module (slow). At that time, I was experimenting with JSI and decided to create a new MMKV library for React Native which was way faster and synchronous by using JSI. So that's what I did, it was a lot faster and you could access all functions synchronously, so no await.
After a few weeks, ammarahm-ed apparently saw that, and also decided to migrate his library to JSI, so now the performance difference might be smaller. I noticed that a lot of his code looks similar to mine, but I don't want to make any accusations here. I do however have a way simpler interface, so to get a value you just do:

const storage = new MMKV()
const name = storage.getString('name')

Whereas with his library you kinda have this loader interface, I don't really know how this works so here's just the code taken from his docs:

const MMKV = new MMKVStorage.Loader().initialize(); // Returns an MMKV Instance 

// Then make are read/write requests

let string = await MMKV.getStringAsync("string");

So mine has a cleaner and more lightweight interface.

It's a matter of personal preference whether you would like to use my library or his.

Also:

• My library automatically installs itself, fast and lazily! The library by ammarahm-ed has a two page installation guide, with my library you don't need any of that! No need to edit native files! 🎉
• My library supports Expo :)
• My codebase is way smaller and oversee-able (matter of personal preference again).
• My library has on-value-changed listeners
• My library has Reactive-styled hooks for easy integration in function components :)
• My library is being used in lots of production apps, from my clients at Margelo, as well as in my apps. So it is also in my interest to keep this library up to date and have it working properly :)

Edit

My library now also supports

1. multiple instances
2. encryption
3. custom IDs
4. custom paths

So:

const storage = new MMKV({
  id: 'some-user-storage',
  path: ...,
  encryptionKey: ...
})

[Kiura]

Alright, now it is clear, I thought there were fundamental differences. Thank you for making this clear.

[mrousavy]

let's leave this open for future reference

[mtroskot]

I think in the best interest of RN community would be that your mmkv library and react-native-mmkv-storage merge into 1 library, since they wrap the same storage and have the same functionalities.
The end result would be a more stable library.

[Raymond-Cox]

I think in the best interest of RN community would be that your mmkv library and react-native-mmkv-storage merge into 1 library, since they wrap the same storage and have the same functionalities. The end result would be a more stable library.

Currently we get to coin-flip which one will stop maintaining their project first 😄

[mrousavy]

Well if you know my libraries, you know that I don't stop maintaining them. All of them work with the latest RN version.

Also, since I am running an app development agency, I use react-native-mmkv (and VisionCamera and others) in multiple production apps, so they work there and it's in my (and my clients') best interested to keep the maintained.

If you are missing some features or need advanced support/help, or just want to show appreciation, you can always sponsor this project. :)

[mrousavy]

Also, I'm not merging my library into his, I like my code, it's very clean and minimal. I also like my API more. And my library was using JSI first 😄

But it's always a matter of preference, you wouldn't prefer someone else's baby over yours would you?

[Raymond-Cox]

I meant no offense mate. I ended up digging through the implementation/code thoroughly before choosing your library. I've spent the last hour implementing your migration script (#52 (comment)), and refactoring the codebase (no more await for storage, yay 🎉 ). So far it's been painless and I'm thoroughly impressed with this library. Thanks for your efforts @mrousavy ! I'll consider sponsoring. 💯

[mrousavy]

Thank you Raymond, and no offense taken!

[raven619claw]

hi, first of all thanks for this great library!

I wanted to know is there any difference or security risk in providing the encryption key in JS code vs generating a random key and storing in keychain(which react-native-mmkv-storage does https://github.com/ammarahm-ed/react-native-mmkv-storage#full-encryption-support)?

[mrousavy]

Hi! Storing the encryption key in keychain seems to be a good idea, you can either manually do that or shoot me a PR so I can add it to MMKV :)

[pke]

Storing in the key chain should not be part of this library, there are other libraries out there already handling this I think.

[Aman1706]

@mrousavy Hey I have a question, I am currently using the react-native-mmkv-storage package but want to shift to your package, can I do so without breaking my app?
My app is live on the app and play store so will it be a problem for users if I push an update with your package?

[mrousavy]

@Aman1706 do you want users to keep their data? I would recommend to wipe all of the data and set up a new storage. This means that your users will probably need to log in again. This would be the simplest approach, if you have critical data stored in MMKV that you can't wipe, it will still be possible (we both use the same MMKV lib under the hood), but you need to test it carefully.

[Aman1706]

@mrousavy Yeah ideally I would like the users to not have to logout, but there is nothing critical per say
Will try it and see what happens if I add your package without clearing the data otherwise will clear the data as you mentioned
thanks!

[fukemy]

other difference: this owner was handsome more than mmkv-storage owner ✌️

[thoth-seshat]

I would love to see this working out of the box with keychain ❤️

[wezter96]

Has it been discussed having a similar API for the encryption as react-native-mmkv-storage?

const storage = new MMKVLoader()
.withEncryption() // Generates a random key and stores it securely in Keychain
.initialize();

What is the currently recommended approach if you want to store something somewhat securely with this library?

If I keep the encryption key on the client I assume it could easily be found and used by someone with malicious intent
export const storage = new MMKV({
id: user-${userId}-storage,
path: ${USER_DIRECTORY}/storage,
encryptionKey: 'hunter2' // This or anything else set from the client point of view would be insecure right?
})

[mrousavy]

This is how react-native-mmkv-storage generates an encryption key.

It's just a random string that changes on every call.

[wezter96]

@mrousavy but they store that encryption key on the keychain right?

To get similar level of security with this lib I would have to implement the storing of the encryption key on the keychain myself I guess?

Or maybe I am misunderstanding something.
If I set an encryptionkey in my app when creating my storage:

export const storage = new MMKV({
id: user-${userId}-storage,
path: ${USER_DIRECTORY}/storage,
encryptionKey: 'hunter2'
})
Someone with malicious intent could easily find this encryptionkey and use it to decode what I have stored on any device with react-native-mmkv I guess?

With the react-native-mmkv-storage solution I would have to get their individual encryption key from their keychain in order to decrypt what has been stored with it right?

Would be so amazing if this library offered similar security level as one of the libraries mentioned here so it could be the first sync secure library endorsed by React Native.
https://reactnative.dev/docs/security#secure-storage

[tyson90]

I think in the best interest of RN community would be that your mmkv library and react-native-mmkv-storage merge into 1 library, since they wrap the same storage and have the same functionalities. The end result would be a more stable library.

Currently we get to coin-flip which one will stop maintaining their project first 😄

And we have a winner I think 🎉