

Spire.io: A New Platform For Serverless Apps That Work On Web & Mobile - airnomad
http://techcrunch.com/2012/05/09/spire-io-a-new-platform-for-serverless-apps-that-work-on-web-mobile/

======
jtchang
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).

~~~
rohansingh
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.

~~~
spladow
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.

------
pbnjay
I love how using the term "serverless" for a backend provider immediately
confuses me about the actual product. Win?

~~~
Void_
They want you to build server-less apps, so they provide the server. It makes
sense.

~~~
samtp
But the apps aren't "server-less". The server is just controlled by a
different party.

~~~
rohansingh
Agreed. These apps are "serverless" in the same sense that outsourcing
development makes your application codeless.

------
akrymski
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).

~~~
DenisM
RPC is an anti-pattern.

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>

~~~
dyoder
FWIW, we use HTTP as intended, not to tunnel RPCs.

------
amirmc
_"And then, the realization: 'let’s build the picks and shovels, instead of
panning for gold.'"_

Something about this line really irked me. Not really the kind of thing I'd
want to read as a potential customer.

~~~
augustl
It's exactly the thing I would want to read. I'm the expert in gold panning,
damnit, just give me the tools I need.

~~~
newobj
You're an expert in gold panning yet you need tools?

------
equark
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...

------
hnf0r3v3r
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.

Anyone interested in this sort of project?

------
g0su
What is the difference between this and Firebase?

~~~
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.

------
newobj
For god's sake at LEAST put a towel over your head when recording a voice-
over.

------
maybird
Sounds like Firebase.

~~~
jxson
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.

------
wavephorm
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)

~~~
cortesoft
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.

