Hacker News Reader

Comment by julianpye | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com