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.

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.

1. We are close to an object database, but with some subtle distinctions from the mainline expectations I believe — data is serialized in a language-independent binary format, that is actually column-oriented. We also have full indexing available of all fields. It’s not that object databases can’t do that, it’s just that most people probably don’t expect that level of access. And to be honest, there are marketing considerations too, in the OODBMS feels very dated as a term.

2. We don’t support JavaScript in general at the moment, only JavaScript that runs inside JavaScriptCore inside React Native. Otherwise, we lack the C++ APIs that we rely on to power the underlying storage engine. We are trying to add support for more JavaScript runtimes though.

3. Python support is doable, but we are focusing 100% on mobile front-ends right now. We don’t even support using Realm from Java outside of Android, for example. Eventually we do want to add support for Python, Ruby, node.js, etc.

VP Product at Realm here. Thanks to everyone on HN for the support over the years! We came out of YC in Summer 11 and it’s been a fantastic ride growing over the past few years. Would love to hear y’alls thoughts on what we should add next. Is there any reason why you’d still use SQLite?

You can add any object as a property of another object, and access them via dot notation: https://realm.io/docs/react-native/latest/#object-properties

You can probably find some more advanced examples in our Swift docs https://realm.io/docs/swift/latest/#relationships

We’re barely scratching the surface of this in our query language, which is heavily NSPredicate-inspired, but we might add more OpenCypher-ish features in the future. (And we’d greatly appreciate concrete use-cases or anything else you can share in a GitHub issue to help us prioritize development) https://github.com/realm/realm-js/issues

Last month, about 60% of our iOS users already used Swift, and the gap in favor of Swift is growing very quickly (it was 50/50 in November 2015). Some of our Swift users you’d probably expect: apps from Vimeo, Digg, Hipmunk or Misfit wearables. But in the past 1-2 months we’ve seen Swift + Realm apps from some real large companies like Cisco, the NFL, NBC Universal, GoDaddy and 7-Eleven. I hope this helps!

Probably of interest as well: a list from CocoaPods of the top SDKs sorted by number of unique apps that have installed them https://gist.github.com/orta/1c607a2c46545244ab16

Same offer as CognitiveLens: my apologies for the bad experience, and would love to figure out what’s blocking you if you don’t mind emailing me the URL, country, browser you’re using to [redacted] so I can work that out with Wistia.

Yeah, I’m actually surprised Apple hasn’t made a play for this from day 1 since developing iOS/OS X often leads to writing/maintaining a bunch of home-made or 3rd-party scripts (usually in Ruby), making app development require not only knowing Objective-C & Cocoa but also some scripting language. After all if Swift is all about making it easier for more people to build apps more easily, this seems like a worthwhile use-case to go after.

Quick update, we actually spent some time optimizing the APK size, and we got it down from 3MB to 800KB, trying to get this down even further. You should see the improvement starting with realm-java 0.79

We’ll be publishing a few blogposts about our users this week or the next. Otherwise you can meet some & ask questions on https://groups.google.com/forum/#!forum/realm-cocoa or https://groups.google.com/forum/#!forum/realm-java

Absolutely. We’re good friends with Unity, know lots of people at Microsoft and have a ton of respect for what Xamarin is doing, so we’d love to support the whole .Net ecosystem soon. We’re a small team with limited resources so we have to prioritize this vs. sync vs. core work vs. improving iOS & Android but we’ll try to all of these things as quickly as possible. Thanks for being a user and thanks for the kind words :)

With those numbers that's an understandable assumption on your part, but as it turns out the dev team did learn its lesson from your helpful pointers around the time we launched for iOS…

I just checked our Android code and we are reusing compiled statements in our benchmarks (Inserts only since compiled statements are not available for multi-column queries, afawk). Here’s the code we use for inserts:

    public void testBatchInserts() throws PerformanceTestException {
        SQLiteStatement stmt = db.compileStatement("INSERT INTO "
                + EmployeeDatabaseHelper.TABLE_EMPLOYEES + " VALUES(?1, ?2, ?3, ?4)");

        db.beginTransaction();
        for (int row = 0; row < getNumInserts(); row++) {
            stmt.clearBindings();
            stmt.bindString(2, getEmployeeName(row));
            stmt.bindLong(3, getEmployeeAge(row));
            stmt.bindLong(4, getEmployeeHiredStatus(row));
            stmt.executeInsert();
        }
        db.setTransactionSuccessful();
        db.endTransaction();
    }

So there you go: no intention to mislead. Us overlooking prepared statements when we originally benched iOS was definitely a regrettable error but we do try to improve. Thanks for helping us along the way.

That was a totally 100% fair point you made when we launched for iOS, and something we had completely overlooked. Your comment immediately prompted us to update our bench code to reuse compiled statements and, we’ve been using updated charts to document our iOS performance since then (e.g.: https://speakerdeck.com/timanglade/realm-overview-at-the-sil...). See other comment (https://news.ycombinator.com/item?id=8390541) regarding our performance on Android — we do reuse compiled statements.

EDIT: typos.

EDIT 2: clearly referencing that this message was about iOS and pointing to the other comment for Android.

Technically yes, you could write your own JavaScript wrappers using the bridge (and alias the API differences between iOS and Android) but that’s probably cumbersome at this point. We do hope to make a version of Realm for Phonegap soon.

This is good feedback — we definitely expect to be polishing the API quite a bit in the weeks to come, just like we did on iOS>

You have to use Realm.createObject because objects are strongly tied to one Realm at a time. We could introduce standalone objects you can create with regular constructors but you’d be a really heft performance hit there.

RealmLists are mostly used to model relationships at this point, so you could add them to a another model like (http://realm.io/docs/java/0.70.1/#relationships) although eventually we do want to introduce standalone RealmLists.

What would you expect to use multiple RealmObjects in a single RealmList for? (Just so we can learn from your use-case.)

Thanks for the heads-up! We’ll get that fixed shortly.

We do support JSON (and GSON) — you can see it at work in our gridViewExample (https://github.com/realm/realm-java/tree/master/examples/gri...)

Hi, I wrote that tagline so maybe I can explain the rationale. We initially called ourselves “a database that runs directly inside phones, tablets & wearables” but received some ridicule for that as it sounded like we didn’t expect our readers/users to know what a mobile/embedded database was. We iterated a few times until we found this description, where we explain that we replace both low-level DBs like SQLite and high-level abstractions like ORMs or Core Data (because we have our own object-interface built in), while highlighting the two solutions we replace most often on Android & iOS respectively. I agree it’s still somewhat confusing and your analysis is spot on. We’ll try to iterate on this tagline a bit more!

Ritual sacrifices, mostly. Just kidding ;) For the “faster” and “less disk space” parts, we use a lot of standard techniques like bitpacking, compactionless b-trees and other things that have been designed in the past 10 years — we’ll blog more about that stuff very soon. The “understandable code” part can probably be explained by the fact we focused on that extensively during implementation: we did lot of API revisions, gathered lots of feedback in private beta — and we still have a long way to go!

Hi orta! The estimate is calculated from a mix of indicators: # of downloads, # of forks on Github, traffic to our docs, apps on GitHub, apps on the App Store and a few other things, using the same kind of math MongoDB and others have been using to publish this sort of stats in the past (it’s not cumulative at all, and there’s a healthy safety ratio built into the math to provide a very conservative estimate). Of course, this calculation leaves out important sources for which we do not have stats, such as Dash docs visits, people downloading from the same company/proxy — and CocoaPod downloads ;)

Thanks, that actually means a lot! We’ve been heads-down trying to build for this new platform through the highs & lows, and it give us devs a lot of moral support to know that people on the outside are excited about what we’re trying to build too!

I don’t think anyone at Realm has ever tried, but I doubt it would work at this point. We do a lot of things specific to each language in the implementation, so we’d have to support RubyMotion explicitly for it work.

The framework in our release zip only works for iOS but if you build from source[0] it will actually generate an OSX framework as well!

[0] https://github.com/realm/realm-cocoa#building-realm

Android is coming! We have an internal build that’s almost at parity with iOS but still needs a bit of tuning and is missing a few key features like Migrations. We’ll work to release & open-source it soon. You can register to be notified of that [0].

[0] http://realm.us5.list-manage1.com/subscribe?u=2aab5198c2f56b...

Thanks for the kind words! Regarding wiring this to a TableViewController, we have some code samples already for Swift[0] and Objective-C[1]. Right now you get notified of changes and refresh, but we’re very interested in exposing a reactive-style binding mechanism as well. The storage engine underneath supports that very well actually, so stay tuned…

  [0] https://github.com/realm/realm-cocoa/tree/master/examples/swift/RealmSwiftTableViewExample
  [1] https://github.com/realm/realm-cocoa/tree/master/examples/objc/RealmTableViewExample

CloudFront is giving us a lot of issues at the moment, but I implemented + deployed that feature for you! Hopefully it will be live very soon. (btw, thanks for creating & running SoSoSwift!)

Yes, that’s the spirit, although I’m sure others would tell you that using Core Data across threads and at high throughput it much easier said than done :) You can achieve anything with almost any storage technology — we just try to let you do it well, easily and in a very performant & maintainable way.

Absolutely. There’s a lot more details in our launch blogpost [0], but you got the right impression: it’s a custom C++ storage engine underneath (not SQLite), that is tightly integrated with the object layer. Not an ORM per se, because the engine isn’t relational, and because there’s not copying/mapping/translation going on — the data on disk is the same data you manipulate in your language.

The big problems we try to solve are really ease of use & performance. We heard from many developers dissatisfied with the current options on mobile, and the relative complexity to accomplish tasks like accessing data across threads, JSON handling, performance on graph queries, etc. — which the reactions on Twitter seem to confirm. We’ll write a lot more about the tradeoffs in coming weeks, but we’ve really grabbed a lot of perf cycles just by taking advantage of modern techniques such as zero-copy architectures, bitpacking and vectorization. Of course the big implicit tradeoff is that you give up a bit of the relational paradigm in exchange for that speed, although we do maintain ACID transactions, immediate disk persistence by default and schemas.

Completely hear you on wanting plain objects — I personally feel that way too! Unfortunately, there’s no way to achieve what we do without making you inherit from RLMObject, although we do try to make those behave as close as possible to NSObject.

[0] http://realm.io/news/introducing-realm/

Yup, offline mode is definitely a big area of focus for us. Regarding the tag, I’m not sure what the protocol is for these things, but since it wasn’t used for a clear product/project/topic, we figured it was as good a destination as any, since we’d prefer to let everybody benefit from answers we may give to support questions, via SO.

I’m drafting something to dive deeper into the video now; anything in particular you’d like us to dive into?

Absolutely. We didn’t get a chance to clean up the codebase for this app before the launch (it’s actually using an old version of our API that would be confusingly different than what our docs detail) but we’ll try to set up a blogpost about that since I may not be able to do the topic justice in a comment here :)

The short version is that most apps tend to do a query on click, fetch from an API and then cache the results in memory. The Realm version fetches from the API asynchronously in the back, pre-fetching results and writing them form the DB on one thread and reading & displaying them on the map from another. This has a few benefits (& drawbacks). On one hand, you do hit your servers a bit more often at first, and you may actually get so much data in the map that the UI component will start to lag. On the plus side, your data points are cached so you can do a lot less API queries over time (especially for something like Foursquare where users tend to stay in the same area and the dataset of venues doesn’t change that often). You also get better control as a designer or developer, and you can trim down & display relevant datasets on the fly.

To sum up, I’d say the key difference is the availability of a local, concurrent data structure that can easily be updated & read from multiple places (i.e. in a few lines of code if you look at the samples on http://realm.io)