Comment by Eridrus | Hacker News Reader

Comment by Eridrus | Hacker News Reader

I spent a little bit of time examining different options in this space a few weeks back, I found these options:

Firebase

Couchbase Mobile Sync Gateway

CouchDB

PouchDB

Amazon Cognito

Azure Mobile Data Sync

Cloudant

My main issues with Firebase (in order of importance) were:

a) Uncontrollable sync. It seems to always use a web sockets/long poll, and count how many connections you have. Which is not appropriate when data changes infrequently and you're concerned about your users battery life. Mainly, I wanted to be able to do push using GCM/etc.

b) Single unmodifiable conflict resolution strategy

c) SaaS-only

It seems very polished and easy to get started with, but since there was no upgrade path to anything else, the fact that it really wasn't a good fit for my sync needs made it seem like a bad option.

I'm not a huge fan of these systems in general since they have you connecting to a dedicated database that you plug code into (eg as a sync function), rather than exposing building blocks for you to build a sync service.

But I'm still using pouchdb on the client for the moment, and I haven't fully figured out what the backend will be, but at least I have a few options in pouchdb-server/couchbase/couchdb/cloudant.

regarding b) conflict resolution

Firebase presents a last write wins sync on an unsecured database, however, because the security language rules are dynamically evaluated every write (with strong consistency), you are able to add other types of synchronization. For example, firechat[1] implements operational transforms, and this post[2] adds 2 phase commits. You have to figure it out yourself though which can be a fair bit of work.

[1] https://www.firebase.com/blog/2013-04-09-firepad-open-source... [2] https://www.firebase.com/blog/2014-02-04-firesafe-complex-se...

regarding a) different types of sync, we recently added offline persistence, and there is also the REST API, but yeah, GCM sync would be nice to have and something we have been thinking about.

(I am a Firebase dev)

Thanks, I'll have a read over those two posts, I couldn't really find much discussion of conflicts when I looked.

If GCM/etc sync were available, I'd be very interested in using firebase, since I essentially want things to be offline-first with push messages when things get written to.

(Full disclosure, ex-Firebase employee and I make my living building Firebase powered apps)

In response to your issues...

A) If you really wanted, you could make HTTP requests to the REST API (https://www.firebase.com/docs/rest/api/) and that would not force you to use any long standing connection or any more battery life than other options.

B) I think this is a matter of preference. Firebase chooses simplicity over power in this case. The vast majority of developers and applications don't call for custom conflict resolution strategies. Firebase lets you focus on your app, not on these fine-grained details.

C) The SaaS-only argument is valid if you have a huge ops team who you can dedicate to running a complicated, stateful, realtime system like Firebase. However, 99% of the time, we don't have this luxury, so we pay the Firebase team to do it. I look at the SaaS-only aspect as a big plus. I know they're running Firebase in an ideal situation on ideal machines and I don't have to think farther than that. Once again, it just lets me focus on my app, not the details.

I can't disagree, if you have very low-level / complex sync needs, Firebase probably isn't a good fit for that app, but in terms of upgrade path, it doesn't have one because it is unique and exceptional. It's a little crummy that there aren't competitors you could hop to if Firebase went away, but Firebase doesn't have many competitors because they do such a good job and blow others out of the water when they pop up.

Regardless, I don't know your app, so it could very well not be a great fit, but it definitely has legions of benefits over Pouchdb/etc/etc in a huge number of situations.

If I were making straight HTTP requests I don't see what benefit I would be getting from Firebase at all.

I'm not necessarily thinking of a wildly different conflict resolution scheme, but the fact that it is fixed means that if the behaviour is not quite what I want, I either have to just deal with it, or move to another system. In particular, when there are two conflicting writes to a string field, in scenarios where data loss is not acceptable, I would prefer to tell the user about it than just have the last write win.

I haven't run a sync service before, but I'm not really clear on what makes it require a huge ops team compared to any other high scale system.

Obviously piles of people are using it and are happy with it, it just seems like a pretty narrow solution atm.

What are some of your Firebase-powered apps? I'd be interested in trying them.

We've started on one of the missing building blocks here: https://github.com/fanout/liveresource

It's a JS library and sync protocol between client and server. However, there is no official server implementation and as a result the library isn't tied to any particular database nor data model. We're hoping others will fill in the gaps on the server side.

I don't see rethinkdb in that list, admittedly you'd have to roll your own layer between database and user, but I think it might be a good option for a roll your own firebase clone.

Reply on news.ycombinator.com