[equark]

Firebase has a much nicer API. It's organized around a realtime, ordered, tree datastore. This makes it much more akin to very granular database than a message bus. Spire is just an authentication service + channels. There is no state beyond the historical list of messages in a channel. That makes it a really thin layer over Socket.IO. Firebase solves a much harder problem of state synchronization.

Firebase allows you can listen to any part of the subtree and query particular children of a node. Data is synchronized in realtime, optimistically, and the events that fire allow you to easily tie your UI or Backbone model to the datastore. It also has critical features like transactions. This is much more flexible than what Spire.IO currently provides.

[cortesoft]

I am not sure what makes you say it is a thin layer over Socket.IO... or even the comparison to Firebase. I would say Firebase solves a different problem, not really a harder one.

Firebase doesn't have an identity service, does it? Firebase doesn't seem to address the issue of security or privacy at all, which seems to me to be fairly important to a web application.

[dyoder]

Also, you can implement data synchronization over a messaging layer but not the other way around. So I'd say our approach is actually more flexible. And we do plan to introduce APIs to make data synchronization easier.

[equark]

Implementing the Firebase API is nontrivial. It's an entire datastore with fine-grained monitoring and optimistic, distributed, data synchronization. Messaging falls automatically out of their API -- all you do is push child messages. And it's better messaging protocol than pub/sub since you get windowed queries into the channel history for free.

[dyoder]

You get 'windowed queries into the channel history for free' on spire.io as well.