This looks great. Realm has been a game changer at our workplace, but we have not yet ventured to use the platform features as it still seemed a bit too early to rely on. I will definitely take another look now that it is out of beta.
Hey, Sebastian from Realm here. Team lead on the object server.
Definitely happy to hear that. We've poured a lot into this, and we still have so much to implement and do. Looking forward to improving your workflow even further in the future!
As Adam said - stay tuned. The Xamarin version of RealmDraw is included in the same repo as the others so you can see the source code but you can't build it with the public NuGet components just yet. (I am on the Xamarin team and built the Draw app.)
It's an internal dispatcher, that understands how the load balancing works. We're working on maybe having this natively done through HAproxy or the likes.
The protocol is just WebSocket, so any WebSocket enabled load balancer will do. It's just the session stickiness that needs to be understood.
I'll trot out my standard question whenever Realm hits HN: when are you going to have a Browser Javascript client? Our clients want iOS, Android & web apps, so we can't use Realm until we can hit all three.
We don't need the full disconnected functionality that your mobile databases have, I believe that a thin layer on top of your object storage would be sufficient -- we could assume full connectivity when the app loads and when it exits (by hooking onbeforeunload).
Realm looks awesome, I'd love to dive into it more.
Sorry about this, but creating a dedicated web framework hasn't been a priority for us. The good news is that we recently released a Node.js SDK, where you could build a REST API off of it. I know this isn't really what you want but it's a start. We are looking into a more out of the box REST or even GraphQL API with the server for a future update.
We have been experimenting with using Realm as the backing database for our Express based website. Not something we have been ready to put into production yet, but the dev experience of having direct access to all your objects right there in node with no networking overhead has sure been amazing.
That is really cool! We definitely see a lot of potential in this use-case, especially at scale. For example, you could use the Realm Object Server to synchronize the Realms used in the web server. If you need several servers, all the state coordination is then handled for you. Could be quite helpful, especially if the web servers are wrapped in containers.
One "issue" with Realm React Native client is that the data model and Realm server sync is orthogonal to Redux, which has its own data flow pattern. Is there any work to make Realm client compatible with Redux?
The Node.js SDK provided with the pro/enterprise license supports working with synchronized Realms. The open-source version only works with standalone Realms. We realize there is a pain-point here with pricing for smaller teams/startups and we are exploring how we could expose server event handling and data access in the developer edition or a lower price point. One option would be to expose this in the dashboard. Would love feedback, feel free to email at af@realm.io if necessary.
Cool! We know it is a balance, and we are trying as best as possible to straddle making it easy for everyone and also building the business for the long-term.
How does the speed compare to Firebase? I have friends who are on the Drawft team (https://drawft.com) that uses Firebase and they claim firebase is not fast enough for them.
I can't claim specific numbers since like all benchmarks it depends on usage, but I am quite confident our speeds will impress based on how we handle sync. We do not send the object state, but the specific operations instead. In addition, we send in binary format and compress with zlib, so all in all we are very optimized.
This seems great and is attacking a super irritating problem when developing mobile apps. However, it doesn't seem like it would be that practical to use on a real app without server side access, something that seems to cost several thousand dollars a month? Unless I'm missing something, I don't see how you'd do something like send a notification based on a data change (post is liked, comment posted, etc).
Happy to be proven wrong but this has always been the sticking point for me trying this out.
Sorry that this is a limitation for you. Currently event handling is only available in the commercial editions, but we do plan to gradually make more and more of this functionality available in the free developer edition as well.
Is there a way I'm missing to generate things like notifications based on changes in data with the open source edition? Or would you have to send a separate request to the server to let it know to send out the notification, something like that?
Again, I'm not trying to say that you shouldn't be able to charge for your product, but it has kept me from trying it out so far. Thanks!
Right now the only way to listen for changes on the server is through the Node.js SDK provided in the professional/enterprise editions. The open-source Node.js SDK does not support opening/writing/listening to synchronized Realms.
This is extremely helpful feedback, as we have been exploring how to expose this functionality at lower prices or in the free developer edition. One option would be to include the ability to register listeners through the dashboard similar to AWS Lambda. Would that help?
I think my ideal scenario would be to have a Java API similar to what android has, but running on the server with a sort of global view of the data. Then it could listen to whatever it wanted to and issue notifications, send emails, etc. That seems like it would be killer since it leaves all the error prone sync and data update code to realm, but still lets the server do whatever it needs to once it sees a change.
A server-side Java SDK is on our roadmap. The current version makes use of Android functionality, like the looper, so we need to transition it.
Already, the Node.js SDK has an API where you can register callbacks across Realms, giving you the global view you are talking about. You just pass it a regex pattern of the Realms you want to listen to.
This functionality lives in the shared C++ codebase so once we have Java on the server, it would also have it (we also plan to migrate our .Net SDK as well for server-side use).
I have used the Dropbox Datastore (deprecated), Parse, SQLite, CloudKit, FireBase, and probably others, and nothing has compared to how elegant Realm is.
- The code is intuitive and beautiful
- The sync platform is crazy-fast and reliable
- Offline-first is exactly what I need
- Queries are mind-blowingly quick (even with tens of thousands of records)
- Sync listeners are very simple to set up
- Setting up the Realm Object Server on a Digital Ocean Ubuntu VPS takes less than five minutes
I really couldn't be more impressed. I love Realm to bits (heh).
29 comments
[ 2.9 ms ] story [ 80.7 ms ] threadDefinitely happy to hear that. We've poured a lot into this, and we still have so much to implement and do. Looking forward to improving your workflow even further in the future!
The protocol is just WebSocket, so any WebSocket enabled load balancer will do. It's just the session stickiness that needs to be understood.
We don't need the full disconnected functionality that your mobile databases have, I believe that a thin layer on top of your object storage would be sufficient -- we could assume full connectivity when the app loads and when it exits (by hooking onbeforeunload).
Realm looks awesome, I'd love to dive into it more.
The Node.js server access is only for pro/enterprise license or not?
I'm reading this post[1] and this doc[2] and I'm not really sure.
[1] https://realm.io/news/first-object-database-realm-node-js-se...
[2] https://realm.io/docs/realm-object-server/#data-access
Thank you!
Happy to be proven wrong but this has always been the sticking point for me trying this out.
Again, I'm not trying to say that you shouldn't be able to charge for your product, but it has kept me from trying it out so far. Thanks!
This is extremely helpful feedback, as we have been exploring how to expose this functionality at lower prices or in the free developer edition. One option would be to include the ability to register listeners through the dashboard similar to AWS Lambda. Would that help?
Already, the Node.js SDK has an API where you can register callbacks across Realms, giving you the global view you are talking about. You just pass it a regex pattern of the Realms you want to listen to.
This functionality lives in the shared C++ codebase so once we have Java on the server, it would also have it (we also plan to migrate our .Net SDK as well for server-side use).
- The code is intuitive and beautiful
- The sync platform is crazy-fast and reliable
- Offline-first is exactly what I need
- Queries are mind-blowingly quick (even with tens of thousands of records)
- Sync listeners are very simple to set up
- Setting up the Realm Object Server on a Digital Ocean Ubuntu VPS takes less than five minutes
I really couldn't be more impressed. I love Realm to bits (heh).