How Google Will Use Firebase to Supercharge Its Cloud Computing | Hacker News Reader

How Google Will Use Firebase to Supercharge Its Cloud Computing

wired.com

64 pointsghosh13 comments

In most Hackathons I have encountered, client/server interactions have become increasingly essential to woo a jury. The best way to quickly get a result over a weekend is to use Parse or Firebase. And hobbyists with some base knowledge can use it to build prototypes quickly.

Want to achieve the same result with Cloud Endpoints and an Android Client? You will need a couple of hours just to get the dev environment and skeleton code up and working to get started. Google has so many clever engineers, but the barrier of entry to their solutions isn't as low. I think this is where the Firebase acquisition comes into play. It's a much lower barrier to entry to use the Google Cloud environment and is probably mostly a play against Facebook's acquisition of Parse than against Amazon.

I feel like Firebase has a great hackathon demo, but still find it hard to believe that people might actually be using this for their actual backend. The lock-in is extremely high, and migrating to something else would be extremely challenging.

Certainly you realize that most startups don't care about that? They expect they'll spend the time to rearchitect it later on (rightly or wrongly)

As someone who is currently building out some products with Firebase I don't think the cost to swap platform would be too high as long as you isolating your data layer properly.

I'm writing it with om/clojurescript; however, the same would be true for reactjs or any declarative setup. The only code I would need to rewrite would be the read and write hookups to the server.

And, you know, the real-time data backend itself.

I think it really depends on what kind of data is stored. For something like a chat it is a really nice solution in my opionion. If you have to apply complex queries and need full control over your data I would recommend a "real" backend.

For instance, we use Firebase for our community feed on http://spotpot.co but I would not use it to store user accounts there. In the end it is always a trade off but consider that for heavy real time applications a service like firebase can not only be convenient but also save you load on your infrastructure.

100% agreed. Consider this to prevent the lock-in: https://news.ycombinator.com/item?id=8563103

Agreed.

I've used Firebase for a couple internal company projects (right after they left beta) and I was able to quell any misgivings our AMs and PMs had about relying on 3rd party startup services by explaining the sheer amount of time saved by not building their functionality ourselves.

I've been holding back on using it for client work as the same people can't get past "only a year old service so not ready for production", but now with Google's backing and them making it clear it's not just an acquire-then-abandon startup I have more ammunition to sway pessimistic minds when a Firebase backend is warranted.

The sheer amount of time saved won't help you if it goes away, and it could go away in many ways: canceled, poorly maintained until it eventually becomes unreliable, price raised until you can't live with it but can no longer live without it, etc.

It's quite a risk building your business on a single-source product from a vendor whose business wouldn't be significantly different whether that product succeeded or failed.

I hope Google will resolve this by open sourcing Firebase, making it safe to commit to, while providing great paid hosting for it, making it a better choice to pay them for the "sheer amount of time saved", the maintenance, backup, etc., without having to bet the survival of your company on how committed Google ends up being to this minor product over the years to come.

Somebody really needs to write an open source Firebase clone. There's a gaping void in the market for something that doesn't lock users in and supports on-premise installs. This could be a pure open source project or open source business like MongoDB.

It doesn't need to be exactly Firebase. But Firebase sets a high bar. To my knowledge, there is no production-grade datastore that supports realtime sync, range queries, and eventual consistency in the face of intermittent connections.

Email tristan@sense.io if interested trial customer / sponsor.

It's not a data store, but doesn't Meteor's functionality set get you pretty close to the same thing? You can essentially build the same type of behaviors on top of Meteor as you can with Firebase.

Independently, without seeing this thread, I had already posted this today: https://news.ycombinator.com/item?id=8563103

I would definitely participate as a contributer, if it's open-source. I'll email you.

By the way, I have already tried Meteor which relies on MongoDB. However, Firebase allows you to read and write data at any arbitrary location. MongoDB, on the contrary, expects you to have some basic "collections" and write complete documents in there. Anything that is on a deeper level inside is called "embedded document" and the support for common operations is much worse.

I wonder what percentage of real world deployments could be resolved through judicious use of rsync and possibly filesystem-level snapshots in combination with sqlite? I suspect a great many, depending upon ACID requirements and complexity of write loads.

Reply on news.ycombinator.com