
Realm Mobile Platform – Realtime Sync Plus Fully Open Source Database - mlschmitt23
https://realm.io/news/introducing-realm-mobile-platform/
======
rikkimaru
Switched from CoreData to Realm for a database-heavy communications iOS app.
Been using it for about 6 months, so not an expert, but I've done some
interesting stuff with it :)

Main benefits I saw:

    
    
      * faster performance
      * simpler multi-threading
      * built-in encryption based on ios' commoncrypto (fips 140-2 module)
      * fast response time to questions on github (in 3 cases)
    

Main drawbacks:

    
    
      * no icloud syncing. I need to check out the new syncing stuff...
      * new-ish database so does not have ALL features (e.g., multi-process encrypted access). They appear to work quickly to implement features the community cares about.
      * performance is fairly "magical". I understand normal database query performance, realm is different...
      * No in-place VACCUUM-type functionality. I've had issues with the realm database file growing unexpectedly large.

~~~
TimOliver
Hi! Tim from Realm here. Glad to hear that Realm's been working out well for
you in place of Core Data. :)

In response to your drawbacks there: * Definitely try out the Realm Mobile
Platform. We're also looking at leveraging CloudKit to seamlessly authenticate
all devices belonging to a user. * Multi-process encryption wasn't possible
until relatively recently (Issue #1845 on our newly open-sourced realm-core
project!), so we'll definitely be looking at it from now. Please do thumbs-up
any of our GitHub issues for features that you would like. * We've published
articles on how the Realm Core works in the past, but now that it's open-
source, you can go and see the code for yourself! * It's possible to generate
compacted copies of Realm files, so you can implement this functionality
yourself if you need it. We've had long discussions about whether this should
be an automatic feature, but we feel in most cases it would be premature
optimization.

------
timanglade
Former Realm employee here.

So glad to see the team finally launch this. I've seen them work their asses
for years (literally!) to launch something I know Realm’s 100k+ dev community
was clamoring for from day one but was really hard to build.

I'm biased of course but honestly I think they have soft-key shipped one of
the most transformational mobile technologies ever: real-time, conflict-free
sync that works as well offline as online. There was a lot of literature on
this of course but bringing it all together in one product was something else!

From engineering to marketing, product & founders I know they've sweated to
get here and I'm just so, so happy for them.

I know they will make a lot of developers and customers happy, and for that I
say: bravo.

~~~
marknadal
@timanglade, congrats to you and your former team! Always awesome to launch,
good job.

Full disclosure, I work on a competing product (MIT licensed,
[https://github.com/amark/gun](https://github.com/amark/gun) ) and do a lot of
testing on distributed systems.

You guys say it is offline-first with conflict-resolution. However your
documentation ( [https://realm.io/docs/realm-object-server/#conflict-
resoluti...](https://realm.io/docs/realm-object-server/#conflict-resolution) )
states the "Last update wins". This is contradictory for two reasons:

A) Either you mean last write wins relative to the server. But an offline
update is going to get sent late (on reconnect), which would make it "last"
and lead to weird problems.

B) Or you mean last write wins relative to the time stamp of the client. But
this does not account for wall clock drift. What happens if the client's clock
is intentionally set 2 years in the future? In a distributed system, everybody
has a different "last".

The demo video, while very well done, uses a drawing app which does not really
demonstrate real conflict (ie, if 2 users draw over the same space, it becomes
a z-index rendering issue, which could be solved with conflict resolution but
isn't a good example of conflict).

~~~
timanglade
See the full answer from Realm’s founder/CEO here:
[https://news.ycombinator.com/item?id=12590753](https://news.ycombinator.com/item?id=12590753)

~~~
marknadal
Thanks, did not see that. Not all vector clocks provide conflict resolution
though - actually, they can very much lack in this regard. For instance, you
are much more likely to get two clients that increment to the same vector
while offline than two clients getting the exact same millisecond timestamp.

Which would make the problem worse, not resolved. What type of vector are you
using?

~~~
simonask
Simon from Realm here - just wanted to chime in and clarify some details on
this. It would be more correct to say that we are using Lamport timestamps,
with the addition of a globally unique ID for each client and some tracking of
changeset ancestry. No two identical [timestamp, id] tuples will ever be
produced in our system, so there is always an unambiguous way to decide which
side "came first" in case of a causally unrelated conflict.

It's important to understand that most "conflicts" in our system are resolved
without resorting to timestamps at all, which is possible due to the way we
encode our changesets on the wire and the fact that we track their ancestry.
It is only used in cases where we absolutely have to, i.e. when there is no
causal relationship between two updates of the same property (in which case,
the "later" timestamp wins).

Hope that answered your question. :-)

~~~
eloff
Is this documented somewhere? Understanding how sync works here and under what
circumstances the timestamp is required to resolve conflicts is critical to
understanding how to design correct applications based on this.

------
aeharding
Or, you know, support an open source alternative like PouchDB/CouchDB. Sync,
conflict resolution, offline-first, and data push are all supported. Not to
mention it's a very stable, mature ecosystem.

There are even enterprise-ready setups using CouchDB (like Cloudant) for those
that want it.

~~~
timanglade
Hi, former Apache CouchDB guy, former Cloudant employee, and former Realm
employee here… I (still) love CouchDB but at the end of the day I think its
sync is a better fit for server-to-server or web client-to-server use-cases,
not mobile-to-server.

There’s tons of stuff CouchDB sync doesn’t support that end up being a huge
problem with mobile apps… Here are the top 3 things Realm adds in my opinion:
great client-side performance, native models that are extremely easy to use,
and conflict-free sync (not conflict resolution!). With my own eyes I’ve seen
a generation of developers try CouchDB for mobile apps and then abandon it
because of the limitation of its approach. Personally I’m glad to see someone
try to bring more options to developers. I think this is the first general-
case true sync (à la Google Docs) for mobile, and I hope it will continue to
spur more iterations & innovation in other open-source projects as well.

~~~
ramses0
Can you explain this statement: "There’s tons of stuff CouchDB sync doesn’t
support that end up being a huge problem with mobile apps"

You lay it out there and then talk about what Realm adds, but never what Couch
lacks. And are you including PouchDB in your evaluation of CouchDB for
"Client-Side Performance"?

As I understand PouchDB is performant, uses JSON (pretty much the definition
of "Native Models"), and allows server-arbitrated conflict resolution with
stored revisions, making the simplest conflict resolution "last-in-wins" with
user UI for "undo" (or any JS-object merge library).

Thanks!

~~~
andkon
I think you're misunderstanding what "Native Models" means in the context of
iOS work. Saying that a database uses JSON immediately, to many ios devs,
recalls years of writing very fragile json serialization code. Looking through
CouchDB's iOS example apps confirms that yes, basically everything that isn't
a string or int has to be serialized into JSON. That's a pretty enormous
annoyance, and incorporates a lot of additional cognitive overhead when
dealing with data that Realm simply handles properly for iOS from the
beginning.

I'm deeply relieved to see that they're launching something that does
something about the fragile ios architectures built around JSON. It's similar
to what they did with their mobile database: they actually listened to what
mobile devs found annoying, and then they built something that completely
sidestepped all the fragility problems that emerge when you wrap sqlite with
an ORM. Instead, they made an approach that fit within our workflow, as
opposed to taking us further from it.

~~~
janl
CouchDB doesn't have any iOS code, are you perhaps referring to Couchbase?

~~~
andkon
Ohhh my god, you're totally right. I was looking at this:
[https://github.com/couchbase/couchbase-lite-
ios](https://github.com/couchbase/couchbase-lite-ios)

------
yla92
Congrats on the big release.

I remember I was using very early version of Realm in the one of the Android
apps I was working on at that time. It was not working properly for me,
unfortunately. Random Segmentation faults and limitations that one have to use
the POJO extended from the RealmObject. So, I eventually switched back to
SQLite (plus ORMLite).

I have seen a lot of changes and now I think I would definitely consider
giving it a try.

One question that I have is even though it's nice to have self-hosted Realm
Object Server, are there any plans or timeline that it's going to be open-
sourced ?

~~~
pkopacki
Paul from Realm here: The Developer Edition of Realm Object Server is free
forever, and we're committed to adding new features and making it more
powerful over time, but at the moment we haven't made any decisions about
making it open source. We do have a strong history of open sourcing the things
we build, so it's definitely something we're thinking about.

------
antoniuschan99
I found Realm to be very easy to use with React Native. I had trouble using
the other tools to save data inside my React Native apps. Anyone else been in
the same situation?

~~~
ak1394
I'm using it in my React Native app. Pretty happy with it so far. Haven't
tried anything else, as Realm looked like the best choice at when I was
selecting the data store for the app.

------
1474295912
Any updates on the C++ API and lib? It's been pending since a year[1] and
there are no updates :-(

[1] [https://github.com/realm/realm-
cocoa/issues/2198](https://github.com/realm/realm-cocoa/issues/2198)

~~~
bigfish24
We open-sourced our core which is written in C++, though different API. This
now makes it easier and we would love to build it alongside the community:
[https://github.com/realm/realm-core](https://github.com/realm/realm-core)

~~~
1474295912
Kudos!

This is great news for us Mobile C++ developers who don't have alternative to
SQLite.

You just made my day :-)

------
sanderpick
Definitely going to try this out. However, I don't feel great about not
having...

\- any concept of clustering for reliability and failover \- any easy/clear
way to distribute load to the object server \- an easy way to run backups

I may just be blind in the docs. I really don't want to go back to running my
own database server. Services like compose.io are soooo nice. Clustering,
automatic failover, backups...

------
chrisballinger
Another Core Data alternative to try is YapDatabase:
[https://github.com/yapstudios/YapDatabase](https://github.com/yapstudios/YapDatabase)

It is similar to Realm in a lot of ways, with a simple concurrency model, and
native objects (key/value/collection). It's built on top of SQLite so you can
use extensions like secondary indexes, full text search, RTree. You can also
use SQLCipher for full database encryption, and there's another extension to
do automatic syncing via CloudKit.

Caveats are it only runs on Apple platforms, doesn't have cross platform sync,
and isn't backed by VC funding. If you need those things then Realm is
definitely your best choice.

~~~
programmarchy
Bump for Yap. I've successfully shipped an app that used this with the
CloudKit sync extension.

Have to say the mappings / view paradigm was not very intuitive starting out,
but once that clicked things worked very well.

Glad to hear Realm is providing an alternative for syncing and will have to
try it out.

------
wiradikusuma
So this is like alternative to Firebase? How different is their offering?

~~~
ChrMelchior
Christian from Realm here. Main differentiators are probably:

\- Realm is self-hosted compared to Firebase which is an MBass.

\- Native objects all the way down vs. a JSON structure

------
creager
Congrats!

Realm and React Native is now my go-to, keep up the solid work :)

------
gaara87
Congrats! This is a major step forward which we will be supporting in our
product. Its right now being used by close to 500k users :)

Question - TLDR - Is p2p synchronization possible?

Two databases in two different devices in the same network, is it possible to
achieve synchronization without having access to a server?

------
mamcx
I wanna build a POS app and need a solid sync experience. I'm building my own
but obviously prefer to use something else ;)

This could support multiple users against a master database editing and
getting up-to-date(as possible) data? And sync reliable?

~~~
bigfish24
Yes it would be possible to support. This version doesn't expose adjusting
Realm permissions such that multiple users can have read/write permissions to
the same Realm. This will be coming during the beta and exposed as client APIs
for users to manage permissions to Realms under their control.

------
themihai
It says the database is open source but I can't find any link to the source
code. Is both the client and server open source?

~~~
bigfish24
The core database that powers all the versions of Realm was open-sourced today
here:

[https://github.com/realm/realm-core](https://github.com/realm/realm-core)

The various SDKs that use the core for each mobile platform have always been
open source, such as realm-cocoa:

[https://github.com/realm/realm-cocoa](https://github.com/realm/realm-cocoa)

~~~
themihai
> The core database that powers all the versions of Realm was open-sourced
> today here:

Ok, what about the server database?

~~~
astigsen
The server runs the exact same database. It is only the sync part that is
proprietary.

~~~
themihai
> It is only the sync part that is proprietary.

Any reason for that? It's also doesn't look very straightforward how exactly
the database is deployed and accessed on the server. As it stands now only the
'client' is open sourced but if someone wants to hosts its own `realm`
database it still has a lot of work to do. I really find this misleading when
various SAAS vendors claim they are open source when in fact they just provide
you just a client to access their service. Nobody(almost) would use a `binary`
client anyway.

------
wehadfun
Can someone explain why use Realm, or CouchDB, over SQLite?

~~~
bigfish24
Speaking from Realm's side, the primary benefits most developers give are:

\- Object-based: not an ORM

\- Speed: Realm is quite fast and in some cases faster than SQLite

\- Ease-of-use: a lot less boilerplate code and a simple threading model make
it easy to get going with.

------
bryanlarsen
Any plans for a browser version?

~~~
bigfish24
It is something we want to do but right now we are just focused on mobile.
Would love to learn more about what you might like in a web framework:
af@realm.io

------
sctb
We've updated the link from [https://realm.io/products/realm-mobile-
platform/](https://realm.io/products/realm-mobile-platform/) to this
introductory page.

------
nbevans
These guys seem to be copying the Parse business model. Which as we all know
worked out very nicely for the founders and investors. But very badly for
anyone that adopted the Parse framework.

~~~
emdowling
Very legitimate concern. I use the Realm database in production and it has
proven to be a very good decision. Huge advantage over Parse is that the
database is open source. If something did happen, the open source community
would probably be enough to carry it. If not, it is just a local persistence
store, so not hugely difficult to swap out for something else.

This new mobile platform is not (as far as I can tell) open source and has
completely unknown pricing beyond the free tier. I certainly wouldn't go near
it, even though it looks great.

~~~
div
Well, I'm not sure about the pricing, but according to this page
([https://realm.io/products/realm-mobile-
platform/](https://realm.io/products/realm-mobile-platform/)) you can host the
mobile platform on-premises.

