Make Hermes engine to work with Realm. Hermes comes from react-native 0.60.2 and significantly improves app performance on Android.
Following https://facebook.github.io/react-native/docs/hermes. if enableHermes: true, you will get the following:
java.lang.UnsatisfiedLinkError: couldn't find DSO to load: librealmreact.so caused by: dlopen failed: library "libjsc.so" not found
at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:738)
at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:591)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:529)
at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:484)
at io.realm.react.RealmReactModule.<clinit>(RealmReactModule.java:56)
at io.realm.react.RealmReactPackage.createNativeModules(RealmReactPackage.java:31)
With enableHermes: false, everything works as expected.
I'm having the same issue. I'm wondering if there is something looking for "libjsc.so" that can't find it because hermes replaces "libjsc.so" with "libhermes.so". I've been looking through the SoLoader documentation and the Realm documentation to see if I can find anything.
realm-js uses JavaScriptCore APIs directly on React Native to implement its JS API so right now it cannot run on Hermes. We're planning on migrating to the new API in the coming months.
Yeah I was pretty sure this was not an easy change. Glad to hear it is planned to happen @fealebenpae. Thank you!
+1
Spent over 48hours debugging this issue. When I disabled hermes, it started working.
can't wait to implement realm with hermes...
We got stuck migrating project to hermes :((
@fealebenpae firstly, thank you for all the hard work creating this amazing software.
Do you have any rough idea as to when Hermes support might arrive?
I have an app that is stuck in a difficult predicament, the latest JSCore engine has a very high crash rate on certain devices, we can't rollback to earlier RN as it would drop 64bit support, and we can't move to Hermes as we store most of our data in Realm.
We are exploring some dire options at the moment and it would really help us to know if a Realm version might arrive in the next 2 weeks or if we are definitely going to have to wait until October or later.
Again thank you for the hard work. I would love to be able to submit a PR with this functionality, unfortunately this area is totally out of my depth.
Unfortunately we won’t be able to add support for the new Hermes APIs in the next couple of weeks. Because we need to swap out a large part of our C++ codebase to do that it’s likely it’ll take our team months to pull this off.
Would Hermes support help at all with this issue the chrome debugging issue? That's been a thorn in our side. https://github.com/realm/realm-js/issues/491
@raphaeleidus you do not need to downgrade RN. You can use the latest RN with Realm. Just disable Hermes for now. Realm is fully compatible with RN 64 bits.
@ferrannp RN is not my problem it is the JSC in 0.59.10 (not hermes). For 64bit support on android we had to upgrade to 0.59.10 but the JSCore at that version has a high crash rate. I am not running Hermes at all but the people experiencing this issue: https://github.com/facebook/react-native/issues/25494 and trying to resolve or mitigate it have suggested that moving to Hermes would resolve the issue. I cannot move to Hermes though because I am using Realm. This is the problem. Can't move forward to Hermes because of Realm and can't move back to only 32 bit support because of Google. It is a difficult situation and nobody's fault on any side but I and many others are caught in the middle.
I had a similar issue @raphaeleidus. Unrelated, but what solved mine were
-keep class io.realm.react.**After that I stopped getting any issue. I'm using the latest version of React Native (0.60.5). App works fine
@paschaldev were you able to reenable hermes after that?
No... Realm with Hermes gives the JSC error whatever... We'll have to wait unfortunately for Realm before we can use Hermes.
@fealebenpae You mentioned that it will take "months to pull this off". Can you tell whether or not this is something that gets attention in the coming months? In other words, is it planned?
We would like to make use of realm-js and disabling Hermes would be acceptable for now but it will be good to know whether or not support for Hermes can be expected.
Also curious about the roadmap for Hermes. Would it be easier to patch Hermes so it can provide some compatibility to w/e Realm needs?
@mattijsf It is something I expect us to prioritize in Q4 (this year), although we haven't done that planning just yet, but will in the coming weeks.
Has anyone tested Realm with JS v8 on Android?
https://github.com/Kudo/react-native-v8
Perhaps it's a good alternative.
@cristianoccazinsp yeah, I have, it is the same problem. Realm very specifically requires the jscore JS engine and doesn't work with other engines
Bummer! I was reading about the high crash rate of JSCore on Android and started to look at alternatives, but looks like Realm is a blocker for any JS alternative.
@bmunkholm Obviously we hope it gets picked up soon. Thanks for the update 👍
I suggest using this build script for the moment:
Is it ant better?
El mié., 28 de agosto de 2019 06:56, tatiesmars notifications@github.com
escribiĂł:
I suggest using this build script for the moment:
- https://github.com/react-native-community/jsc-android-buildscripts
It allows to use updated version of javascript core on Android instead
of the nov 2014 version...—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/realm/realm-js/issues/2455?email_source=notifications&email_token=ALU263FRRASER2IQ2MO4T43QGZDT3A5CNFSM4ICRE4Y2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5KR62A#issuecomment-525672296,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALU263EU2EC5N4AX4NLGO4DQGZDT3ANCNFSM4ICRE4YQ
.
+1
+1
++++1
+1
In fact, I have 3 apps using Realm and lot of 64bit users complain about crashes. There is any plan to support hermes by now?
We will support Hermes, but unfortunately we can't share a specific timeline yet.
Doing the +1 is best at the top comment with the 👍 - thanks.
Please, we look forward to it.
@tatiesmars Were you able to use that? I'm curious since RN 59 already uses an updated JSC and it contained crashes fixed only by using Hermes or react-native-v8, which is what we cannot do at the moment when using Realm.
+1 Please do it!
Realm is my go-to option for data storage in mobile apps and Hermes brings some major performance improvements to RN.
Those two should be best friends.
+1 Please , we look forward to increase our app performance :)
+1
My work around to work with Hermes and Realm was to implement a native module to use a JAVA version for Realm in Android.
My work around to work with Hermes and Realm was to implement a native module to use a JAVA version for Realm in Android.
Would you care to share this implementation?
+1 please do it !, i waiting, and i hope can boost perform react native well
+1 please do it !
@tatiesmars Were you able to use that? I'm curious since RN 59 already uses an updated JSC and it contained crashes fixed only by using Hermes or react-native-v8, which is what we cannot do at the moment when using Realm.
@The0racle So far our app is using this version of JSC on android with RN 60 and realm, work like good for us.
@tatiesmars Were you able to use that? I'm curious since RN 59 already uses an updated JSC and it contained crashes fixed only by using Hermes or react-native-v8, which is what we cannot do at the moment when using Realm.
@The0racle So far our app is using this version of JSC on android with RN 60 and realm, work like good for us.
Is there any real advantage of using that version of JSC over RN's one? There also seems to be a few "big" issues still open (https://github.com/react-native-community/jsc-android-buildscripts/issues/84 and https://github.com/react-native-community/jsc-android-buildscripts/issues/82) which I wonder if they would actually make things worse.
Update: Correct me if I'm wrong, but RN >= 59 already uses the latest JSC for Android.
@tatiesmars Were you able to use that? I'm curious since RN 59 already uses an updated JSC and it contained crashes fixed only by using Hermes or react-native-v8, which is what we cannot do at the moment when using Realm.
@The0racle So far our app is using this version of JSC on android with RN 60 and realm, work like good for us.
The app build with this version works, but it also crashes on several devices. That's the bigger issue here. Add to that Hermes or V8 improves the apps performance as well.
My work around to work with Hermes and Realm was to implement a native module to use a JAVA version for Realm in Android.
Could you share what you did?
+1
+1
+1
+1
@ferrannp Maybe you could update the issue to support other JS engines. I specifically am looking into implementing react-native-v8 instead of Hermes as we prioritize performance/memory usage over start up speed.
So @kneth you guys a working on it?
@fealebenpae could you maybe publish some rough timeline? Will it take another couple of month?
My project is stuck until this is fixed. :(
@RenanSanguinete @Rob-Dre We haven't started on this yet. Until we do it's hard to share a timeline. We hope to identify resources during this year.
+1
+1
Here, and in general, please add your +1 at the top description. This helps show a summary of how popular an issue is, whereas a comment sends a lot of notifications to many people :-)
+1
+1111111111111
++++ 1
Seriously folks, this is how you get issues closed, so people with meaningful contributions can't speak. Just stop.
Guys, please let us know re your plans..
ReactNative is a huge community and Realm is one of the best & performant DB,
we can miss the chance to marry them together...
We don't have much news to share since this. We do intend to add support for Hermes. But it has to wait until we have implemented #2516. Likely this will land sometime in Q1.
Please do it.
I've locked the issue now as it seems to spam everyone with not so helpful encouragement to do this. We really can't be more explicit about our plans than this. We will update once there is actual news to share.
We'd like to keep this group up to date as Q1 was a bit overly optimistic on our part. We've been working hard to release MongoDB Realm, but are still looking at Hermes support for the future. While we don't have a specific date planned at this time we're watching Hermes develop and continually discussing when the right time for us to support is.
I've unlocked the issue as it appears you can't even update the issue at the top when it's locked.
But PLEASE, upvote at the top comment instead of making another comment with +1.
Status so far is that work hasn't started and there are no firm plans on when it will. We hope to be able to share more about our plans to support this later in Aug.
I've unlocked the issue as it appears you can't even update the issue at the top when it's locked.
But PLEASE, upvote at the top comment instead of making another comment with +1.
Status so far is that work hasn't started and there are no firm plans on when it will. We hope to be able to share more about our plans to support this later in Aug.
Thanks for the update @bmunkholm this will help others like myself make the decision to jump (or not in other cases) to another DB solution going forward.
Thanks for the update. Of course I was hoping for this to get more priority and agree with @flikQ that this update helps to consider alternatives. The reality is that Hermes has much needed performance and feature gains compared to JSC. Especially the highly anticipated Reanimated v2 increases the desire to switch to Hermes.
@mattijsf @flikQ could you share what are offline-first alternatives of Realm?
@sintylapse
https://www.simform.com/react-native-database-selection-guide/#3
Maybe this article could help you
News?
any updates ?
Hermes did not make it onto the Q3 plan - we will re-evaluate at the start of next quarter
Is v10 with MongoDB Realm Cloud really more important than Hermes support? Hermes is a requirement for new versions of some core libraries, so this issue is a huge blocker
@sintylapse Out of curiosity, could you list some of these core libraries?
@kneth react-native-reanimated V2, react-native-navigation V7
It's not just libraries. Hermes also cuts the app launch time in half which is really significant, a welcome boost, especially on older devices running a large app.
We have migrated from realm-js to sqlite by writing a custom native module that migrates the data. realm-java / realm-cocoa can be used to read the realm files generated by realm-js. This way we can immediately switch to Hermes while also migrate data for existing users.
Will keep an close eye on this issue, hoping it will get resolved at one point after we probably migrate back as realm-js and its API is a bliss to work with 👍
Is there any news on this issue?
This would now be even more useful, as React Native v0.64 will enable support for Hermes on iOS (previously it was only available on Android)
@minderov wow, thanks for the update, that looks extremely promising. Now more than ever more reasons to support hermes.
Hey All - Product from Realm here, we appreciate all of the community interest and we agree - Hermes is an important piece of the React Native platform and we want to build support for it - it's a top priority. However, the team and I have done an extensive review of the Hermes integration and the React Native options for embedding and we are unfortunately blocked by the Hermes and React Native architecture. Let me explain.
The Realm Database, at its core, is written in C++ - all of the things that make Realm great - an object database with automatic schema generation, live objects with queries and writes performed in an ACID compliant way, fine-grained notifications enabling a reactive UI, and sync - depend on our ability to expose APIs to the JavaScript VM on the same thread it runs on. Unfortunately, React Native does not provide a public API that allows us to talk to the JS VM. When we built our integration four years ago we wrote a workaround that intercepts the creation of the JS VM and allows us to inject our APIs and otherwise interact with the VM. You can see this here:
https://github.com/realm/realm-js/blob/master/src/android/jsc_override.cpp
If you haven't seen Assembly code in a long time, it's because you shouldn't. Our expectation, and I believe any developer's expectation, would be that if a platform wanted to support embedded libraries there would be stable public APIs for us to interface with. This workaround has led to all of the things you would predict - broken releases as new versions of RN are released and as they change the underlying private API implementation, writing new workarounds to fix the old ones, leading to reduced productivity and feature velocity.
The addition of the JavaScript Interface (JSI) API is an important step towards enabling C++ React Native modules which expose synchronous APIs on the JavaScript thread. But even though Hermes implements JSI, the crucial plumbing that lets C++ modules use JSI to implement JS APIs is still missing. This means that for Hermes we need to develop a new workaround that intercepts the JS VM. And while JavaScriptCore is relatively mature and stable and the private APIs we access for our workaround don’t change much anymore, Hermes is actively developed and any private APIs we might need to resort to for our workaround will most likely change often, and thus break our Hermes integration.
There are proposals from the RN community on how to solve this, we are not alone. One of them is Turbo Modules, which have been in progress for some time, but not enabled by default yet. This has been discussed here -
https://github.com/react-native-community/discussions-and-proposals/blob/master/proposals/0002
Our hope is that the combination of JSI and TurboModules will enable cross-platform C++ modules like Realm to target all React Native platforms - iOS, Android, macOS, and Windows, all with different JavaScript engines, without requiring app developers to perform any extra steps beyond installing a package from NPM.
There is an open issue to implement them here but it appears to be deprioritized -
https://github.com/facebook/react-native/issues/28128
I share this with you in the vein of full transparency but my ask to the community is can you help us getting this prioritized and delivered by the RN team? This would help us and countless other libraries out there that want to embed.
There is a clear need and use case. In fact, Microsoft, with a much newer platform, is already going in the direction we need with
https://github.com/microsoft/react-native-windows/pull/5085
https://github.com/microsoft/react-native-windows/pull/5461
Thank you,
Ian
I think you guys miss understood the role of TurboModules in the new architecture.
They don't provide any better access to the VM than JSI because they use JSI under the hood. They provide a better API for interacting with it, and also a way for the Codegen to generate most of the bindings.
The TurboModules are available right now and they are pretty much ready for production usage.
You can learn more about JSI, TurboModules and how react-native-reanimated uses them today (especially with Hermes, because they use Hermes on Android) from my comment on the dedicated discussion about JSI: https://github.com/react-native-community/discussions-and-proposals/issues/91#issuecomment-702589052
Also, here is the usage of JSI directly without TurboModules - I wrote a sync bridge for Reanimated a year ago:
https://github.com/terrysahaidak/reanimated-jsi/blob/master/jsi/android/ReanimatedJSI.cpp
All you need for that – a reference to the VM. After you have it and passed to JSI - you can do whatever you want. And JSI creates an abstraction over the VM so with that you can use both Hermes and JSC and even V8 as an engine.
The Hermes team currently maintains JSI, so if you find any problems – it's better to ask them.
Here is the JSI header file:
https://github.com/facebook/hermes/blob/master/API/jsi/jsi/jsi.h
So yeah, if you need access to VM - you can use JSI today. No need to wait for Turbo Modules.
Actually, React Native has been using JSI for years :)
If you have any questions about what's possible with JSI – feel free to ask. I'm not an expert, but I'll try to help.
Hey @terrysahaidak thank you for your post. We know that TurboModules uses JSI under the hood - and part of our migration to TurboModules has time budgeted for the JSI migration. We have watched the Re-Animated project closely because it is probably the closest library in terms of complexity to integrating Realm Database on RN. It looks like the installation instructions for re-animated - https://docs.swmansion.com/react-native-reanimated/docs/next/installation/
got cleaned up quite a bit to take advantage of some of the new iOS PRs that the RN Product team released.
In looking at the Re-Animated architecture, the magic happens in https://github.com/software-mansion/react-native-reanimated/commit/0f72749478ec2f0ab8ec9a8124b2244826cac398
The library is still doing weird stuff - in this case it is overriding the jsExecutorFactoryForBridge method from the React Native application template to inject Reanimated into the JavaScript context. This is pretty similar to what we do today on iOS, but using different APIs. Of course, this is a step up from our Assembly override, and this enabled a massive clean-up on the user experience for installing re-animated on iOS, but it’s still not using an official blessed mechanism from RN.
We still need the Android piece simplified for us to proceed. We have gotten in contact with the RN Product team, and they are working on cleaning up the Android build system, with this PR merged -
https://github.com/facebook/react-native/commit/5be44456f2f15b0dbc7343033854bbf77efbfbd2
and more future ones planned
https://github.com/react-native-community/discussions-and-proposals/projects/2
This one appears to be key to clean up the codegen for Android -
https://github.com/react-native-community/discussions-and-proposals/issues/273
I hope this helps
Hey @ianpward, it's really cool there is some progress on that and we all appreciate it.
For iOS, the Reanimated team is currently using a hack to inject the library into the array of libraries which are using TurboModules. Previous approach was enabling TurboModules for the whole ReactNative, but not all of the native modules ReactNative have right now are ready as well as not all the userland libraries are using them in a safe way. So basically now only Reanimated is in the TurboModule mode. IMO, that's a good choice for now. Also, it requires no interaction from the user to install it.
On Android they provide prebuild .aar with all the native code so no need for user to build anything. The installation requires only calling some "installJSI" method defined in C++, exposed to Java using JNI.
As far as I know, they didn't use Codegen at that moment because it wasn't ready on Android and wrote everything manually.
+1, Any update on this issue?
Can anyone recommend an alternative to Realm?
Is there any other DB thats supports Hermes/RN ? Any advice would be appreciated, thank you
@mattijsf @flikQ could you share what are offline-first alternatives of Realm?
Did you get any responses, please do share.
I think this makes not copying libjsc.so in NDK library.
When I checked the lib directory of my app in adb shell, there was not the file libjsc.so.
But, unfortunately there is no way to override or edit on my side.
I am going to post an issue with this, but there are still too many issuers on this repository so I am not sure if they have time to fix this. :(
Here is an issue link.
@HSReact FYI https://github.com/Nozbe/WatermelonDB/issues/755#issuecomment-684805636
@geragray @ianpward — why don't y'all just wrap your native wrappers to the C++ layer. Making synchronous calls on the JS thread is janky anyways and locks the UI for large transactions.
Edit your project/android/app/build.gradle from
if (enableHermes) {
def hermesPath = "../../node_modules/hermes-engine/android/";
debugImplementation files(hermesPath + "hermes-debug.aar")
releaseImplementation files(hermesPath + "hermes-release.aar")
} else {
implementation jscFlavor
}
to
if (enableHermes) {
def hermesPath = "../../node_modules/hermes-engine/android/";
debugImplementation files(hermesPath + "hermes-debug.aar")
releaseImplementation files(hermesPath + "hermes-release.aar")
implementation jscFlavor
} else {
implementation jscFlavor
}
@flyskywhy — did you try opening your app in release build? I'm pretty sure that's not a thing 🦆
@ZComwiz , you are right, release build ok but run fail, even though debug run ok.
Waiting https://github.com/facebook/react-native/issues/26930 to be solved.
@mattijsf — do you have any advice on how to migrate to Watermelon? Did you install Realm-Cocoa and Realm-Java locally and generate a pre-populated SQLite DB on the native side or did you pipe data through the bridge to migrate/ instantiate the new Watermelon SQLite instance?
I have a problem with that
moment.locale("en-ca");
moment("2021-01-13").add(1, 'days').calendar();
This print other date or give me an error
My version is: Moment.js 2.29.1
Please Help me
@Jonas299 you were in the wrong repo
@ianpward & @kneth, just FYI Hermes is coming to iOS in the next release https://github.com/facebook/react-native/releases/tag/v0.64.0-rc.2. I still did not try it but I guess enabling Hermes on iOS would also not work with Realm. I am hoping this raises a bit more awareness that we might end up into a point where is gonna be really hard to use Realm and keep React Native up to date.
@ferrannp Thank you!
Is it possible to make a statement if and in what time horizon we can expect this feature? I think this would help many in planning the further development of their projects. Thank you!
It is top on our backlog, and as soon as we can, we will work on it. I can't give an exact date.
https://github.com/software-mansion/react-native-reanimated jumped into the "hermes only" wagon as well, so I'm glad you guys have it at the top of your backlog. Reanimated is used by react-navigation and a variety of popular react-native libraries, so once those libraries also upgrade to v2, we will have a very serious upgrade issue if Realm stays behind.
We are currently migrating a complex app to mongodb realm...as if that wasn’t difficult enough....no support for Hermes is a deal-breaker, I would prioritise this as high-priority
@kneth FYI React Native 0.64 is out. And as you can read in their blogpost:
We plan to make Hermes the default JavaScript engine for Android in a coming release so we are working to resolve the remaining issues people have when using Hermes. Please open an issue on the Hermes GitHub repo if there are remaining issues holding back your app from adopting Hermes.
I am sure if you need help, Hermes team would help you.
@ferrannp Thank you for linking to the blog post. As mentioned last week, Hermes support is top on our backlog.
Hi @kneth, is there any update or a timeline that is taking shape for Hermes support?
Hi @kneth @alazier @tgoyne @appden @blagoev -
This is restricting us from upgrading react native , expo and so on... Is there any timeline available for this ? We might have to consider switching to other Local DB options, if the release is taking too long. Thanks :)
It is pretty disappointing that this is now approaching 3+ years, i'm in the same boat, thing is we can upgrade React Native but it doesn't seem worth it if we can't use Hermes, the performance boost would be worth it.
The whole reason we chose Realm was for the database encryption, sure i could use another database and sure i could encrypt every value 1 by 1 but that is not ideal in comparison.
There simply isn't any decent alternatives as far as i'm aware.
A road map would be nice.
@8BallBomBom we've stripped out Realm as we've not really had a choice for this. I've also had to recommend fellow devs to not use Realm if they want to gain the benefits of Hermes.
@flikQ Gotta do what ya gotta do, it will end up coming to that for us too if things don't move.
Just sad really.
@8BallBomBom we've stripped out Realm as we've not really had a choice for this. I've also had to recommend fellow devs to not use Realm if they want to gain the benefits of Hermes.
what did you pick as an alternative to realm? Just curious as we would need to evaluate as a backup strategy
How do you guys perform users migration from Realm to any other DB when you remove Realm from the project? How can you handle Realm data without Realm?
We migrated out of realm, two months ago, our app got faster, the UI is not stuck anymore when inserting new complex data(not just on the simulator).
@eladgel what database did you use instead and how did you migrate your users data?
Folks - we have begun the design of our Hermes support. The delay is simply a consequence of the underlying architecture of React Native - embedded libraries have not been a primary focus of RN as described here:
https://github.com/realm/realm-js/issues/2455#issuecomment-703760988
It appears that the RN product is now looking to ameliorate this and we hope that this work continues to make embedders a first class citizen in the React Native ecosystem.
@ianpward Hi Ian, would you be so kind as to share a timeline for achieving this...the folks on this group and all Realm users worldwide would like to know, thank you
Hi, can we expect to have Hermes support this year ? Just to know if I can be confident in choosing Realm on a new react native project. Thanks
@eladgel I start doing that to all apps I am maintaining them. It is sad news to see database like Realm didn't support RN as it appear in initial versions ...
My two years of waiting was not a correct decision, I admit.
@sintylapse I think the best choice to go with is SQLite since realm based on.
Cool thanks will check out for sure
Hermes on iOS made the app start ~40% faster than JSC.
@belal-mazlom Correct me if i'm wrong but i don't think Realm is based on SQLite.
SQLite is in some respects a nice alternative but not an ideal solution to be honest.
Realm is NOT based on top of SQLite.
As an alternative - there is https://github.com/Nozbe/WatermelonDB which is based on SQLite AFAIK and supports Hermes
@8BallBomBom we've stripped out Realm as we've not really had a choice for this. I've also had to recommend fellow devs to not use Realm if they want to gain the benefits of Hermes.
what did you pick as an alternative to realm? Just curious as we would need to evaluate as a backup strategy
We just stripped it out and didn't replace, our use case was for it to store template data (paths to images, names etc) that rarely changed in the API to cut down on repeat API calls.
Removing ha ironically improved app performance, altho increased the number of API calls, the trade off has been worth is given the capability of our API.

Hermes keeps getting better...
It is two years still didn't add the support Yay
Their direction is not aligned with 'our' kind of users. I can only suggest you replace or simply strip out Realm as we have.
Realm is NOT based on top of SQLite.
As an alternative - there is https://github.com/Nozbe/WatermelonDB which is based on SQLite AFAIK and supports Hermes
This is unfortunately the route that we've had to take. We're having to tear out each call one by one.
@8BallBomBom Yes, I was wrong, it's not based on SQLite, my thought built on a wrong old comment!
SQLite is good enough for my use, but in general it will depends on your situation.
My usage to RealmDb was a bit small, like caching some APIs content, and credentials related tokens.
In my position I got three options to switch for:
1 - Wait until Realm team upgrade it to support Hermes.
2 - Use native versions, Realm Objective‑C / Realm Java and create a wrapper for my used calls that I need.
3 - Just remove it and used AsyncStorage or other DB alternatives like WatermelonDB ...
@belal-mazlom so if you have native versions of Realm, you can use Hermes? That sounds like a good solution. What are disadvantages here?
I guess the native versions would just use a wrapper through the bridge/regular RN modules. The issue with that, is that queries would become slower.
On the other hand, for "simple usage", I think it's a massive win. Queries are now async (due to the bridge), and there's 0 C++ code causing random crashes and messing up other code stack traces. Plus Hermes, of course.
What does the Hermes team think of that alternative? Could that be a temporary option until the C++ code for Hermes is implemented? Like a "Lite" or "Slow" version of Realm that only uses native modules.
@cristianoccazinsp if you ever gonna create such a wrapper please share it with us, so we could build on top of it 🙏🏼
I'm not even sure if that would be possible, just following up on @belal-mazlom idea. The Realm team can probably provide some insight whether or not it would be feasible to do it.
Queries are now async (due to the bridge)
keeping in mind that this could be a major problem for write transactions and break consistency if not handled on the userland
@ianpward that would be great if someone from Realm team would confirm if this is a workable idea (Use native versions, Realm Objective‑C / Realm Java and create a wrapper for calls). This is at least sounds great for those, who want to migrate from Realm with saving users data
@ianpward Hello Ian, Could you please give the community an update about the likely rollout of Hermes Support by the Realm-Mongo team. This will help us in planning our UI updates/releases. Many thanks
Engineering is still writing the scope of work on what it would take to build the integration. Rest assured we are building Hermes support. Once the scope has been written and approved I will share an estimate with the community. I expect this scoping process to take another couple weeks.
Thank you Ian, we look forward to hearing from you soon.
need support hermes engine
Most helpful comment
Is v10 with MongoDB Realm Cloud really more important than Hermes support? Hermes is a requirement for new versions of some core libraries, so this issue is a huge blocker