Item — HN Reader

(firebase founder here) I’m thrilled to finally be able to show everyone what we’ve been working on over the last 18 months! When I said “big things are coming” in the HN comments back when our acquisition was announced, I was talking about today : )

We’re really excited about these new products. There are some big advances on the development side, with a new storage solution, integrated push messaging, remote configuration, updates to auth, etc. Perhaps more important though are the new solutions for later in your app’s lifecycle. We’ve added analytics, crash reporting, dynamic linking, and a bunch more so that we can continue to support you after you’ve built and launched your app too.

I'd suggest reading the blog post for more info: https://firebase.googleblog.com/2016/05/firebase-expands-to-...

This is the first cut of a lot of new features, and we’re eager to hear what the Hacker News community thinks. I look forward to your comments!

19 comments

Is there an Open Source version of Firebase which we can use on our own hardware if we wish to? Vendor lock-in is the biggest fear I have with Firebase.

Like Facebook (Parse), if Google also decides that Firebase is not profitable and decides to close down, how do we run our applications without rewriting?

How do we protect ourselves, if Google decides to increase the price of Firebase 3-4 times in a single day?

Even just a public pledge from Google saying that they will open source the full featured Firebase if they decide to close down the devision will go a long way to alleviate this fear.

Horizon[0] was announced yesterday; it's basically an open-source Firebase built on RethinkDB.

[0]: https://github.com/rethinkdb/horizon

This seems quite interesting. Hope they chose MIT or Apache for license as said in the ReadMe.

Horizon is only the "realtime db" portion of Firebase and it's only for Javascript, not Android or iOS. The mobile app realtime network connection tech is especially tricky to get right without draining a user's battery by doing things like constantly polling the backend. I have not seen anything from RethinkDB along those lines.

I was at ng-conf a couple weeks ago. Talking to the Firebase guy at their booth, he goes "You should talk to the RethinkDB guys, it's the same thing but open source." I got a kick out of it.

What about the new "Firebase Cloud Messaging", formerly GCM?

Overview of open source alternatives: https://deepstream.io/blog/realtime-framework-overview/

I'd second Horizon. I've been working with RethinkDB for over a year, and really believe in their commitment to RethinkDb's core technology, and their deep understanding of what is needed to build reactive web apps.

https://deepstream.io is an open source server that's basically a self hosted firebase. It supports data-sync, pub/sub and rpcs and can scale horizontally to millions of connections.

Self hosted 'firebase' from RethinkDB team http://horizon.io/

I think it's less likely to happen here because Google is investing heavily in building a business around developer services.

I cannot agree with that. Google Cloud services are way too small comparing to AWS or Azure and they don't make a lot of money with it. They can discontinue it easily.

http://ramses.tech (shameless plug)

It's not exactly the same thing but it achieves the same goal and is opensource.

API services are generated from RAML files (yaml) No code required for simple crud, biz logic can be hooked using http event handlers. Uses Elasticsearch for reads and Mongodb or Postgres for writes. Other DB can be hooked by writing the proper Db engines, it's all documented.

We were also looking for an open source Firebase a while ago, packed with some extra features like multiple db support and push notifications. Ended up building http://telepat.io.

Docs & specifications at http://docs.telepat.io/. Hope this helps you.

Of course we always need to balance open source 'FREE as in beer' with no-maintenance commercial solutions. Opensource is extremely important but it can also be 'FREE as in puppies' adding an extra maintenance burden (self hosting, security updates etc.).

Horizon.io ticks both boxes by offering a cloud SaaS :) one could say that is the ideal product!

[Architect from Couchbase]

Couchbase Mobile is open-sourced under Apache 2 and has all of the database and sync functionality of Firebase. From a database perspective it is more complete than Firebase. It also has enterprise level security, REST/Stream/Batch APIs, etc. Take a look and see if it meets your needs.

http://www.couchbase.com/mobile

There's also Meteor

Another: http://gun.js.org/ & https://github.com/amark/gun

Realtime, Peer-to-Peer, Offline-First, Graph.

A podcast on its performance (25+M ops/sec) just happened on http://readthesource.io/ an hour or so ago, hangouts link: http://youtu.be/70dn1oZQFCk?a .

MIT / ZLIB / Apache 2 license - do whatever you want with it.

"Like Facebook (Parse), if Google also decides that Firebase is not profitable and decides to close down, how do we run our applications without rewriting?"

You can architect your app sequester these 3rd party services on the edge, making any rewrite much easier.

You should never use products like this where you are completely vendor-locked and will be unable to switch easily to another provider. I did this mistake before and we used SQL Azure Federations (cool & cheap autosharding for SQL Server), then Microsoft decided to discontinue it and provide only very expensive up-scale version of SQL Server instead. We spend months to migrate our product to PostgreSQL... and this is just an example, Google also love to discontinue products, probably even more than Microsoft.

I did this mistake with Parse. The open source version released doesn't have full features and we have run into a few bugs which created a lot of issues.

It's better to stick with open source stack. I like what Amazon is doing with AWS with services like RDS and ElastiCache. If one carefully selects the services on AWS, there is almost zero vendor lock in.

Google also had hiked the AppEngine price in Sept. 2011 which caused a lot of problems to early adopters.

> We spend months to migrate our product to PostgreSQL

Which means you presumably saved months initially by using Azure, and got your product to market sooner. Everyone should be aware of the dangers of lock-in, and should carefully consider the value of it vs. the liability they're taking on. But I wouldn't say never use products like this. The value-add can be significant, even taking into account the fact that you may have to migrate off of it someday.

This is good news for me. File storage and push messaging are particularly nice.

As a user of the Firebase iOS SDK, I was wondering why the SDK was getting so stale. The Quickstart guide used deprecated Swift, didn't offer Carthage support, etc.

I looked at the new docs, and I guess they ditched the old Quickstart format in favor of a bunch of examples. At least the code seems to be up to date, which is somewhat encouraging. I still wish for Carthage support, though.

I see a lot of people worrying about reliance on proprietary BaaS. I had services running on Parse when it announced the shutdown, and it really wasn't that hard to migrate. Firebase should be even easier to leave if necessary, since it's basically just a NoSQL data model. If you abstract your queries and avoid some bells and whistles, you can keep everything in one place for a relatively painless move that hopefully will never become necessary.

Firebase iOS engineer here:

First off, I'm glad you like the new feature additions. We'd love to hear your feedback on Storage and FCM :)

Secondly, I'd love Carthage support as well, but there are a few things (built into Carthage) that prevent us from adding this: 1. Carthage requires iOS 8+ (dynamic frameworks only). Firebase supports 7+, and we build static "frameworks", so we'd lose that (which is still relevant in a lot of our developers). 2. Carthage is designed for open source (git based origins only), and while we'd love to get there, we currently ship everything as a pre-built framework.

Hello there. I love Firebase. Use it every day.

The one big request I've always had was to be able to grab the client's IP address on request. Is that possible with this new Firebase and GCE integration?

I have many Firebase apps. Most of them have an intermediate server solely for this one reason.

That's a feature I would also really like.

I also use an intermediate server (ipify.org) to get the IP address. The only reason I need the IP address is to throttle users. If adjustable throttling was baked into the platform and not require me to write logic to handle it, that would be sweet too.

This isn't something we support out of the box yet, but I'll definitely discuss this with the team. Thanks for the feedback!

New dashboard look & feel is awesome. Lots to digest from that short keynote, but I'm excited to see Google double-down on its investment (Hi, Facebook).

Looks like https://console.firebase.google.com is getting slammed. All of my attempted imports are failing.

Yeah, sorry about that! We're working to get more capacity ASAP. The response has been incredible.

Thanks so much, I love your product and am developing on it right now. When Parse got shut down, I got a bit nervous, but the Firebase updates give me reassurance that it is here to stay.

For Authentication, it will be cool to have something like Twitter Digits(https://get.digits.com/) or Facebook Account Kit(https://developers.facebook.com/docs/accountkit), which is basically SMS authentication without password.

I was on the fence about using Firebase for my new project...I'm no in the fence anymore! Congrats, this looks awesome!

We changed the URL to that blog post from https://firebase.google.com/, since it gives the background.

Would love, love for Firebase to have a service similar to AWS Lambda to manipulate and transform data without having to maintain persistent servers.

You can use any Google Cloud product with Firebase so you have access to Cloud Functions. https://cloud.google.com/functions/

Firebase is awesome! Realtime has become a great selling point with my clients (and a necessity for things like chat apps). However, after doing over 20 apps with Firebase I've had to combine with other PAAS due to some features missing/lacking: server-side code (event-driven like Parse had or like AWS Lambda) and better/easier search features. In the second case for instance, let's imagine a support app, it makes more sense to use a traditional SQL DB for objects like tickets, customers, etc while using Firebase for a realtime chat inside a ticket. Even a hosted Non-SQL with some good collection search feature is a better fit rather than using Firebase.

Google PM here. You might want to look at Google Cloud's storage offerings (both SQL and non-SQL based), as well as its compute offerings (including Cloud Functions, which is event driven). One note: Cloud Functions was just announced and is still in alpha.

Huge feature set, thanks.

Any news on deeper/more complex queries (chaining, or something like joins without rewriting our data in multiple places)

Or faster queries (server side I've seen some very slow .once calls taking hundreds of ms)?

Also I'd love some tips on how to better scale listener/trigger functions. I have many listeners (server side) and am migrating them to explicit client endpoint point functions to handle it horizontally (more api workers).

As a mobile (web) developer. How well does it work with React Native, and compare with Realm JS and the new Horizon from RethinkDB?

For React Native, we're working on updating our libraries as soon as possible. I haven't worked with Horizon, so I can't provide thoughts there.

Looks great! It will certainly be filling the void that Parse's departue left.

Google already offered a lot more more than other platforms (ios) in terms of analytics and this just makes that gap even bigger.

Congratulations on the release! It'll tale a while to digest the truck-load of new stuff you've got :D

Nice job with Firebase! I've got a friend who is an entry-level front-end developer, and he was able to develop this grocery list app with Firebase on his own: https://collaboralist.github.io/ (source code: https://github.com/KidIcarus1337/collaboralist), attesting to Firebase's claim of providing a Backend-as-a-Service.

This is amazing, I'll probably be using Firebase for my next mobile app. I had a great experience with Parse, and I think their shutdown has left a big void. It looks like Firebase is filling that void, and then some.

I'm wondering if you might be able to speak candidly about this whole acquire => shutdown pattern? Why will Google choose to keep running Firebase, instead of shuttering it and getting you guys to work on something else? And do you have any thoughts on why Facebook might have wanted to shut down Parse?

Congrats on the launch. What about hybrid (ionic/cordova/phonegap) apps? Any chance you'll be adding support via an official plugin?

Firebase has been a popular choice for backend, but now there's no clear way (at least as reflected in the current docs) to take advantage of all the offer (FCM, testing, etc).

will user be able to opt out of tracking? Like Do-Not-Track