Although I agree with your point, it didn't confused me at all. I've clearly understood that it was "serverless" in the sense that I don't have to build the server.
My point is that I had to read way too much to figure out that they meant they provide the server, for what is actually a "serverfull" application.
Just reading the headline, it makes me think that they've somehow built a P2P "serverless" framework for hosting a mobile app. Which does sound intriguing to me, but it's not what they're offering.
We get compared to other messaging services quite a bit, the big difference is that real-time messaging will not be our only service.
We are already working on other services that will cover the most common needs of developing apps (data store, cdn). The new Identity service combined with real-time messaging and our upcoming services will allow developers to very quickly develop really powerful applications. I don't think that is something businesses exclusively in the real-time messaging space (like firebase) are working towards.
My feeling is that both wants to solve the exact same problem but they decided of a different route to get there. I feel the Firebase way started more as marketting and hype, while Spire.IO is a more traditional minimalistic version of what the real thing could be. (For instance, I could write a real app on spire while it'd be impossible on firebase as there's no authentication system.)
I think Firebase will eventually figure out how to pull off their service. After all, they aren't planning on leaving beta until the end of the year (according to their support rep). It is frustrating though. I really dislike when companies promise solutions to problems they haven't even figured out yet.
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.
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.
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.
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.
I have no problem with these new backend as a service providers. Parse, FireBase, Spire.io, etc. The problem I have is what happens when you have all your data hosted with them and they go away. You are stuck either rebuilding the same API they had or migrating to another provider.
That said I have used Parse and it is amazing at how fast you can get up and running. I will definitely be giving Parse a good look when I spin up my next app (whether it be at a hackathon or otherwise). For now though my attitude is cautious optimism.
And what really is the end game in all this? A lot of these have similar APIs. What's to prevent you from just copying the API (hope that they are deemed uncopyrightable).
What could happen is a great open source library that you could host yourself on a linode. So, it's "backend-less" in the sense that you don't have to do backend stuff, but you still have control over your databases. Seems like it's the way that spire took.. where you can use their services if you want, but you'll be able to host everything yourself because they open source mostly everything. Their challenge, a little bit like Github, is to make their service so awesome that you don't want to do everything yourself. I.e. On github you have visibility, issues, wiki, easy creation, multi-users, etc. out of the box.
One thing I like about Parse is that they explicitly support data portability. Of course, that is only the data you're getting, so you are correct in that you would have to reimplement the API if you wanted to move away seamlessly.
That's not the end of the world, though it does influence which of these providers I choose. For example, I feel more comfortable building on Parse because I'm fairly confident that they won't disappear without some warning. I think it's a trust barrier you have to break through to become successful in this particular market.
You are correct on all points here. Stability and trust are very important in this market. Obviously, we are planning on being around for a long time, but it may take a little while for everyone to gain confidence in us. The best thing we can do is to keep iterating and prove that we are building something that's meant to last.
As far as building trust goes, we plan to automate the process of exporting your data soon, but until then we will provide it upon request at any point.
We also stick to open standards and open source software wherever possible so that your code is not dependent on any proprietary technology from us or anyone else. Our own server code is based completely on widely supported open source projects, ranging from Node to Redis.
Finally, we are open sourcing our own stack as aggressively as we can and already offer limited licenses to firms that are concerned about being dependent on our code.
In short, we're doing everything we can to ensure that you are never "locked in" to our technology or any one else's. Our goal is keep innovating so that you don't want to use another solutions.
There is a real need for an open source clone of one of these realtime datastores. I'd lean towards Firebase since it has the best API I've seen so far.
If anybody wants an open source sprint, I'd be willing to donate to such a project...
You want me to hand over my entire backend infrastruture to your company and be entirely limited by your capabilites and rewrite my app specifically for your system? Seriously? Are there people actually interested this? Who's the target audience? (I hope you don't say backend developers)
I think spire.io is more geared towards people making new applications. If you already have a working backend, keep using it. However, if you are making a new web application, you need to pick your battles; do you spend your time writing server code and setting up a server, or do you spend your time writing the actual application? It is a reinventing the wheel thing. You want to spend your time writing the parts of your app that are DIFFERENT and actually core to your application.
From giving Spire and Freebase a quick glance, none of these services seem to be designed to work in offline mode. What I'd love to see is a different kind of architecture: a server-less app with its local database (websql or indexedDB) which syncs with a server-side database instead of making RPC style calls. ie disconnected mode of operation with syncing when online.
This is how Meteor works from what I understand, and we've had to build this ourselves on top of Backbone for Post.fm. Perhaps we're a special case, but something tells me that the infrastructure of the future is not RPC calls but data-sync. (I guess MS Exchange is one of the first large examples of this).
I'm working on something similar that I want to open source. The idea is to be able to build apps quickly on the front end, and only have to mess with the back when necessary.
37 comments
[ 3.0 ms ] story [ 112 ms ] threadJust reading the headline, it makes me think that they've somehow built a P2P "serverless" framework for hosting a mobile app. Which does sound intriguing to me, but it's not what they're offering.
It's basically like calling a taxi a "driverless" form of transport, just because you don't do the driving.
We are already working on other services that will cover the most common needs of developing apps (data store, cdn). The new Identity service combined with real-time messaging and our upcoming services will allow developers to very quickly develop really powerful applications. I don't think that is something businesses exclusively in the real-time messaging space (like firebase) are working towards.
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.
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.
That said I have used Parse and it is amazing at how fast you can get up and running. I will definitely be giving Parse a good look when I spin up my next app (whether it be at a hackathon or otherwise). For now though my attitude is cautious optimism.
And what really is the end game in all this? A lot of these have similar APIs. What's to prevent you from just copying the API (hope that they are deemed uncopyrightable).
That's not the end of the world, though it does influence which of these providers I choose. For example, I feel more comfortable building on Parse because I'm fairly confident that they won't disappear without some warning. I think it's a trust barrier you have to break through to become successful in this particular market.
As far as building trust goes, we plan to automate the process of exporting your data soon, but until then we will provide it upon request at any point.
We also stick to open standards and open source software wherever possible so that your code is not dependent on any proprietary technology from us or anyone else. Our own server code is based completely on widely supported open source projects, ranging from Node to Redis.
Finally, we are open sourcing our own stack as aggressively as we can and already offer limited licenses to firms that are concerned about being dependent on our code.
In short, we're doing everything we can to ensure that you are never "locked in" to our technology or any one else's. Our goal is keep innovating so that you don't want to use another solutions.
If anybody wants an open source sprint, I'd be willing to donate to such a project...
Something about this line really irked me. Not really the kind of thing I'd want to read as a potential customer.
They're for "incidental" data, rather than "valuable" data.
But I agree with you: you're setting yourself up for massive failure relying on any of these things.
This is how Meteor works from what I understand, and we've had to build this ourselves on top of Backbone for Post.fm. Perhaps we're a special case, but something tells me that the infrastructure of the future is not RPC calls but data-sync. (I guess MS Exchange is one of the first large examples of this).
I've been beating this drum for years, but it feels awfully lonely...
http://news.ycombinator.com/item?id=2317568
http://news.ycombinator.com/item?id=2972345
Anyone interested in this sort of project?