Firebase expands to become a unified app platform | Hacker News Reader

Firebase expands to become a unified app platform

firebase.googleblog.com

530 pointsNemant204 comments

(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!

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.

MIT: https://github.com/rethinkdb/horizon/commit/79304a56fbcd57a6...

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.

> by doing things like constantly polling the backend

RethinkDB doesn't require polling. It's like their #1 feature and differentiator from other non-sql databases.

What do they do?

We use websockets in our realtime platform.

The Horizon client uses websockets to connect to the Horizon server. The Horizon server uses RethinkDB's protocol[1] to connect to the database.

[1] http://rethinkdb.com/docs/writing-drivers/

Websockets cannot be as efficient as native network management code.

What does this even mean? WebSockets can be used natively. In fact the Firebase client uses WebSockets, same as Horizon.

Sorry I was confused about terms, what I was thinking of was Javascript vs native. Native code can do more than a browser sandboxed client can.

Horizon uses push architecture by default so there is no need to pool.

> is especially tricky to get right without draining a user's battery by doing things like constantly polling the backend

One simple solution is giving each state a defined name, and keeping a socket open from mobile. If the connection is restarted, each side can name their current state, and the delta can also be easily synced.

Later on, changes can be directly transmitted via the socket.

(I am working on something like that currently myself).

I presume you can still use it with any mobile App wrapped as native e.g. via React Native or Ionic.

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.

GCS is relatively small today, but it's growing fast, and Google is investing a ton of money and resources into it right now. They've added a bunch of new systems and promised more coming soon. They also just signed a huge deal to host all of Spotify's data. Cloud Services aren't going anywhere, in fact my perception is that Google would like them to replace advertising as their #1 moneymaker.

Google Cloud is way more advanced than both AWS and Azure in many ways and just as big in capacity, if not customers yet. Cloud computing will likely be more profitable than ads in the future for them and they announced billions in new investment just a few months ago to build out the platform further.

It's not going anywhere.

Microsoft put billions into Windows Phone and many (including me) think it's superior to iOS and Android, but what's its market share now? What I mean is, even if it is technically better, will Google Cloud get customers? AWS has a huge head start with significant mindshare, and Microsoft has its pre-existing enterprise customers sewed up. With tech funding drying up, where will Google find its customers?

You're vastly underestimating the computing market. Startups/tech funding are a microscopic part of the industry. There are millions of small businesses and thousands of major corporations that are slowly moving into the cloud which are all new customers for the taking.

AWS has a head start and a great product catalog, Azure has the windows/office/server ecosystem, but Google has been doing scaled computing for a very long time and has contributed to many of the innovations in the industry. Although they're newer with less features, what they do have is more advanced and the Google name carries a lot of weight and reputation.

Most corporations are still focused on just moving over to IaaS with compliance and security first and Google has done a great job building a solid foundation for this which should pay dividends in the future.

> Most corporations are still focused on just moving over to IaaS with compliance and security first

Yes but my point is AWS has more mindshare and MS has more leverageable pre-existing business inroads with a huge number of these corporations.

> and Google has done a great job building a solid foundation for this which should pay dividends in the future

That seems rational, but the countless examples of "worse is better" in life indicate that that outcome is far from guaranteed.

Yeah, the challenge is that it seems to rely on Google services (not just libraries) at the app layer in a way that screams lock-in.

Downvote? Is it not reliant on Google services?

HN crowd is pro-Google, I feel. I get pounded with downvotes, the moment I speak against the darling of the Bay Area (?)

That would definitely explain it.

Never liked the downvoting idea, but if it must be, then it would be nice if people were at least required to comment while downvoting and open themselves to downvotes for their whacked, baseless downvotes.

> Google Cloud is way more advanced than both AWS and Azure in many ways

I see this being thrown around here a lot. Buying into Google's PR is what this is. If you've valid points apart from BigQuery vs RedShift, I'd request you to enumerate them for me.

I have personally interacted with Googlers who lament the fact that 'no one internally bothers using most of GCP' and hence not being able to 'iterate/innovate as fast as AWS' is a key disadvantage despite their 'superior offerings', whatever that means.

> Buying into Google's PR is what this is

Really? Have you actually used it or done any research?

1. Container Engine = built on kubernetes, faster and easier than the others

2. Compute Engine = VMs start faster, customizable rather than set sizes, live migration when the host has maintenance or starts to fail, NVME SSDs available with < 1ms latency

3. Networking = faster and more consistent performance, all the regions are connected which makes cross-regional/global deployments easier and more secure

4. Load balancing = actually routes the traffic automatically to the closest region and spills over based on capacity, not just DNS junk like the rest, no warmup or latency issues

5. CDN interconnects = cheaper bandwidth and lower latency using their partner CDN networks

6. Pub/Sub = great message system that doesnt need shards or anything to deal with for scaling, supports multiple subscribers and acks

7. gcloud = best shell access available to interact with pretty much everything, no keys or passwords to worry about

8. grpc APIs, fast storage/nearline, bigtable/datastore/cloud sql, Vision API, etc

Yes it's still new and there are a few frustrating issues, and AWS and Azure do have lots of products and their own special offerings, but the core Google platform is the amazing at running a bunch of servers/containers for a globally distributed app with high performance. We've tried them all and GCP has been the best so far.

And all of it nicely accessible to the US. What a great idea.

Amazon and Microsoft are both also US-based companies.

And not any better – at least you don’t get vendor lock-in with them.

What are you talking about? VMs are the same across any cloud if you just want IaaS.

They all have their own proprietary services which are valuable but it's completely your choice to use them.

But amazon doesn't use aws too, right ?

+1 -- Sometimes Google does embrace open source in building services that I can trust longterm, e.g., Kubernetes. I wish Firebase (which I won't use) were being built and marketed in a similar way to Kubernetes (which I will use).

This is sarcasm, right? Here's some more equivalent sarcasm: Gmail and Google Search could discontinue easily.

Search, hardly. But Gmail? What happens when Google decides they're not monetizing Gmail sufficiently and force everyone to Inbox? What then!

You're comparing their mature businesses to their nascent cloud business. Their market share in the latter is still a fraction of the leaders'. It's very possible that Google may "lose the cloud".

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.

> It's better to stick with open source stack.

This is a hard lesson each person learns on their own.

The difference is actually between a product and a service. A service is something that another party provides, and that may - actually, they most definitely will - at some point stop providing, for various reasons. You want to minimize your dependence on any services - especially ones that are not trivially replaceable or that don't come with contractual agreements to cover your costs in case of the service being shut down.

That's why I hate the whole SaaS idea - it turns products into services; something that should be permanent (as long as you can maintain the hardware it runs) into something that is ephemeral and ever changing. It's great for the service provider, but it totally sucks for the customers. SaaS drives entropy in the computing universe.

I totally respect your perspective, but SaaS is gaining popularity because software customers are making an informed decision about the tradeoffs of product vs service as a delivery model, not because service providers are forcing the SaaS model on them. Many customers see value in shifting the operations and support burden to the software vendor. I think it's ultimately good that users have more choice in how they consume software. Diversity is positive for the computing universe.

The key though is that you want to use open source software that some company has provided as a service so you get all the benefits of SaaS without the lockin. Heroku Postgres for example. If Heroku shuts down or is no longer an option, you just spin up with a different PostgreSQL service provider, or run it yourself with no code changes.

Software customers are sometimes making informed decisions, and sometimes basing their decision on building a platform that has a time horizon of "until we get a lot of funding" or "when we get bought by a larger company". In both cases, that is long enough to not worry about whether the SaaS that forms an integral part of the product will last.

I'm not making a value judgement; I'm pointing out that SaaS is often picked for only its short-term benefits.

That's why we need SaaSaaS. That'll fix it.

Check out my upcoming talk "Migrate to Firebase", today at 3. I specifically cover how to use new Firebase features to add all the missing Parse product lines back to ParseServer

Link: https://events.google.com/io2016/schedule?sid=b4641ff7-0bef-...

And when will Firebase become a product we can self-host? Because until that is the case – or unless people do an SLA regarding Firebase – it has to be considered as reliable as a 2$ VPS.

> or unless people do an SLA regarding Firebase

https://www.firebase.com/terms/service-level-agreement.html

Though I think what you are looking for is Firebase being covered by a Deprecation Policy.

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

That MIGHT be true, but it's not apparent from their statement. Just because it costs N to build a product on technology X and costs M to migrate an existing product to technology Y does not mean that it would have cost N + M to implement the product on technology Y in the first place.

I think the point made above is that it's enough for implementation(X) < implementation(Y) in order to sway some people to technology X. Rapid prototyping is an example of this, since the time-value of feedback is higher before the product is well defined.

You are correct of course, my point is that even if cost(implementing Y originally) < cost(implementing X and later migrating to Y) it may still be worth it, because the cost has been deferred. Time is often a lot more valuable in early stages of a startup.

From experience, changing databases on a product in flight is not trivial. Even moving our production database from an external vendor to an in-house location (exact same database engine and version) was a decent-size task, and would have been much, much easier with greenfields or a chunk of downtime.

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.

Understood. Dependency management for iOS is generally pretty terrible, in my experience. I suppose Apple will step in soon, and I hope they do a nice job of it.

Anyway, I continue to use (and enjoy using) Firebase for iOS and web.

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.

Is there anything you'd like to use the IP address for beyond throttling?

Not in my use cases.

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.

I assume you just pulled a comically-large lever in your office, because it just worked!

Thanks, and congrats.

I'm actually not seeing my current projects at https://console.firebase.google.com/ and I have two (one sandbox, one prod). Is this due to the over-capacity?

They're just not listed under "Projects using Firebase".

Can you email me at andrew at firebase dot com and we'll take a look?

just did. please look for an email from vineet at ekcoffee dot com. we literally submitted our new apps for app store review this morning. i'd like to understand better how this impacts us.

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/

The blaze plan does state full google cloud integration. But I dont think google cloud functions can be directly triggered with firebase

I've been eyeing this. Can we kick off a Cloud Function via Firebase Cloud Messaging?

Hey.. PM for Cloud Functions here.

Short answer is no (well.. not without an intermediate proxy of some sort), but we're in the process of providing direct integration with Cloud Functions across many of the services that fall under the Firebase umbrella. So stay tuned!

That will be awesome! We're running background jobs on a VPS right now and figured we could change that to a Firebase Queue -> Self hosted Director / Proxy service -> Google Pub / Sub -> Google Cloud Functions. Obviously the more direct route would save us some complexity!

Sorry, I don't know. I don't really use Firebase.

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.

I am aware of the suggested services; however, the ideal would be to have them seamlessly integrated to Firebase.

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

Firebase is an incredibly powerful tool, and in a sense is a "democratizing force" in web development. Now anyone can build a complete web application without needing to know anything about setting up servers, content delivery networks, AWS (which is still quite difficult to use), and scaling. I teach kids as young as 10 years old to build iOS apps and websites with Firebase - they can develop locally and push to Firebase hosting with a single command. After exploring this new update, I can say with confidence that literally everything is easy-to-use now.

Whenever there is a Firebase announcement there are many replies along the lines of "this won't work for me because it's owned by Google, may be discontinued, doesn't have on-premise solution, etc". If these are your thoughts then you are missing the point of Firebase. It enables small web development shops like mine to focus on building beautiful web applications without having to give up manpower toward backend engineering. The cost of using Firebase is peanuts compared to the savings in employee hours.

Perhaps some day we will have to migrate elsewhere, but I find that possibility extremely unlikely because the clear amount of effort it took to create the Google-y version means this is a long-term play.

We are not missing the point. Some of us just happen to value other things more than convenience.

There's no shortage of discontinued products that were cancelled even though a lot of effort and money was poured into them. Amount previously invested is a sunk cost and shouldn't even matter when deciding if continue a service/product or not. Just because you have already dig a hole doesn't mean you should keep digging even though you can't profit from it.

This is a good point. However, products are usually discontinued because they no longer fit in with the core business of the acquirer. In this case, Google is making a clear statement that Firebase will be an integral part of the Google Cloud experience for everyone (hobbyists all the way to apps at scale).

> sunk cost and shouldn't even matter

Shouldn't but does. It has it's own fallacy section:

https://en.wikipedia.org/wiki/Sunk_costs#Loss_aversion_and_t...

Also, not falling for the fallacy means admitting defeat. And the higher up one is in an organization, the worse admitting defeat is for your career. Having a product dead-ended by keeping on working on it forever is much better for manager/government official careers. So sadly, the fact that other people (above you) fall for the fallacy makes falling for it yourself rational in a lot of cases. Instead just systematically lower the priority, but never to zero.

In anything but a startup, I would treat any sunk cost above a minimal level as a firm commitment to continue at any cost. I would never have done so 5 years ago, but ...

Why not put a minimum service life on Firebase similar to an LTS release? I imagine uptake would increase by an order of magnitude.

yea, anyone can build a web application this way... but how well will it scale?

> Perhaps some day we will have to migrate elsewhere, but I find that possibility extremely unlikely because the clear amount of effort it took to create the Google-y version means this is a long-term play.

Hahahahahaha. Aight. Whatever you need to tell yourself. This is even sillier than Parse; FB doesn't have anywhere near the track record of killing projects that Google does.

We were part of the Early Access Program for the expanded Firebase and used it to build our music collaboration app Kwaver. With the new features, they did a nice job of collecting a bunch of related mobile products (Analytics, Push Notifications, Storage, Authentication, Database, Deep Linking, etc) into a pretty cohesive platform, and it's saved us a bunch of time.

With Firebase Analytics we can track events, segment audiences (according to user properties; active, dormant, inactive) and take action according to the user segment. We are able to send push notifications (also using Firebase) to dormant male users who play the piano for example. Another cool feature is Remote Config, which gives you the option to ship a number of separate experiences and track the user interaction. Like A/B Testing but way more flexible.

For us, the best product is the existing database product they had, as it really improves our user experience to ditch the 'pull to refresh' button' and have our app respond to changes live.

We have been waiting for Google to provide developers a more complete mobile solution for a while now, and they’ve done it superbly through Firebase!

Feedback; It would be really cool if Firebase could implement UTM codes to be able to track user acquisition and be able to automate actions according to User Properties.

Shameless plug: if you're a musician (or a music fan), we'd really appreciate if you could download our music collaboration app, try it out and give us feedback. It’s available for free on the app store; The following link will re-direct you there later today. http://kwaver.com

I love Firebase, but the Swift code in the iOS guide is of really low quality. For example (https://firebase.google.com/docs/database/ios/save-data#dele...):

    if currentData.value != nil, let uid = FIRAuth.auth()?.currentUser?.uid {
        var post = currentData.value as! [String : AnyObject]
        var stars : Dictionary<String, Bool>
        stars = post["stars"] as? Dictionary<String, Bool> ?? [:]
        // ...
    }

What this should really be:

    guard let post = currentData.value as? [String : AnyObject],
    uid = FIRAuth.auth()?.currentUser?.uid else { return FIRTransactionResult.successWithValue(currentData) }

        let stars = post["stars"] as? [String : Bool] ?? [:]
        // ...
    }

Great suggestion! Pull requests welcome as well if you have time: https://github.com/firebase/quickstart-ios/blob/master/datab...

Oh cool, I already sent feedback through the Firebase website but I'll do this as well.

Interesting that Google is doubling down where Facebook divested. The obvious difference is that Google has a cloud platform and Firebase is a funnel into it, whereas Facebook had nothing to funnel Parse users into.

I wonder if Facebook will ever launch a cloud platform. They've got the computing resources for it.

Your first hint that Google was very serious about cloud, was when we hired Diane Greene:

http://www.businessinsider.com/google-hires-diane-greene-to-...

Also when Urs publically states he wants Google Cloud revenue to be bigger than adwords, that ain't nothing:

http://www.businessinsider.com/urs-holze-talks-google-cloud-...

I know it's popular to be cynical about Google and how we'll deprecate everything just as it's popular, but that kind of cynicism isn't really good for your health.

They probably won't.

We've been using the Firebase platform for a while now. It's pretty cool to see them expand from 3 products to ~15 overnight. I'm most excited about their analytics and crash reporting. I must say that their system has been one of the best we have used in a longtime, I am really excited to see other aspects like analytics and ads being housed under this same umbrella, as I think it is going to help with development time overall. One area that I'd like to see improved though is a deeper querying language for database, or even better would be a way to automatically export the system in realtime to a postgres database for better SQL type analytics.

The concern I've always had with Firebase is the lack of a business logic layer between clients and the database. This tends to force the business logic into the clients themselves.

Trying to change the schema if you have Firebase clients deployed that can't be instantly upgraded via a browser refresh (i.e. iOS and Android mobile apps) seems an extremely challenging task.

> Trying to change the schema

That's the biggest question I have after looking over the site. Coming from the Mongo/Mongoose world what happens in this case?

There used to be a thread in the Firebase Google group about this which is gone now. It still lives on here:

http://grokbase.com/t/gg/firebase-talk/154mr25k86/firebase-m...

That thread is not encouraging.

Edit - found the original thread here:

https://groups.google.com/forum/#!topic/firebase-talk/LjHATl...

I worked for a company that relied solely on Firebase for their backend... I ended up writing a lot of Node scripts to munge our Firebase db's data and JSON structure.

We used the original Firebase database product to build http://socrates.io/ 3.5 years ago, and I remember getting Socrates running in a few hours. I’m looking forward to seeing them up the bar on speed of development / ease for their next 10 products :) Nice work team!

way too risky to use it for startups. Google may discontinue this project at any time and you have to spend months to rewrite everything for another database. IF google open source it and we will be able to install it on premise and patch without Google, that would be ok. So, I would recommend to use PostgreSQL instead.

Way to risky not to use for startups, IMO. What would you prefer, spending half your time doing backend development to get a system that might be 80% as reliable as Firebase on the off chance that your startup will survive long enough for your custom engineered solution to bare fruit, or spending all your time actually building your product and launching quickly so you can determine whether or not your startup is even viable?

Recommend looking at Rethinkdb :) They just announced Horizon too.

Yes, this may be a good option. I just never tried it or worked with it, so I can't say anything about it.

Google is dogfooding this in it's other companies, like Nest, fwiw.

They always say that. Google's internal customers also get to continue access after a product has "been retired" (eg. Chrome Web Store still using Google Wallet's web payments) and are in a different position than Google's external customers when it comes to negotiability and notification period.

Well, yes, but if they decide to discontinue the service, or increase the price, this is no guarantee that all other users will get the same treatment as Alphabet companies.

Same argument for enterprises can be had here. Way too risky to let the existing house of cards (stack) to perch atop a product that can be discontinued at anytime (I'm looking at you, Microsoft!). Google needs more revenues since ad money is shrinking so they would make sure that you get vendor-locked. Once shit happens, you are provided with a more expensive alternative, or consultancy services provided by certified vendors (again, looking at you, Microsoft!).

When will it support a count query? now to be able to count number of children I have to download all the data. Count is such an important feature for me.

You could run your writes as transactions that increments a count wherever you need one.

I have build apps with firebase in the past and the feature I missed the most was performing scheduled tasks on the database. Now we are getting this BIG app platform update and this feature is still not in there. AWS Lambda with Scheduled Events for a long time to come :sad-panda:

Do Google Cloud Functions (referenced above) not fit that bill? https://cloud.google.com/functions/

I'm also keen to use Firebase without having to run a separate server to handle logic for payments, email alerts on search terms, etc.

Last time I checked it was impossible to do scheduled tasks. But it's in alpha stage, so maybe that's coming.

Big +1 from me, as I'm working on a large Web app with Firebase and continually hit blocks where I need server logic/events. Read the announcement full of hope, then felt let down.

What's the point of BaaS if you still need another B to power it?

I remember walking into Firebase's offices about 4 years ago when it was 4 people on Townsend St in SOMA in a 300 square foot share office space. It's amazing to see how far they've come; Congrats to the whole team.

Thanks Joe! : ) I remember that day.

Even if you don't want to use any Firebase service you might still want to use it only for Analytics. Drop the firebase SDK in the App and you are done. Free, unlimited and unsampled Analytics reports for your App.

https://firebase.google.com/docs/analytics/#implementation_p...

https://support.google.com/firebase/answer/6317517?hl=en&ref...

As a current Firebase customer, I'm pretty thrilled about all this (especially since I was afraid Google would pull a Facebook here). However, there's quite a bunch of API changes and absolutely no info about how long the old JS library, endpoints, etc etc are to keep working. Should I get stressed out?

(Firebase engineer here)

The old SDKs will continue to work! We worked extremely hard to make sure everything was backwards compatible with them. We most certainly do not want to break any existing customer apps. Check out the migration guides [1] to get your app updated to the new SDKs.

We understand migrating is not easy or always convenient. If you run into issues or something that used to work seems to be no longer work, please let us know. We will be giving you advanced warning if and when things get turned off.

[1] http://firebase.google.com/support/guides

Great! I found the guides but I couldn't find this info in there.

I like the new features and also the new JS API so I think that's plenty of incentive to migrate. Thanks!

We are using "Custom" authentication where we issue tokens based on a stored application secret. Is this still supported? I cannot find it in the documentation.

Thanks for the info! Hopping on this thread to ask one more question: does the JS API now support syncing even through going offline, like the iOS and Android SDKs do?

This may be a stupid question, but: What do you use it for? Cannot everyone basically edit the client code and do whatever with your data? I've only used Firebase for prototyping.

That's what the Database Security Rules [1] are for. If you want to learn more, check out my I/O talk tomorrow called "The key to Firebase security" [2].

[1] http://firebase.google.com/docs/database/security [2] https://events.google.com/io2016/schedule?sid=af641ff7-0bef-...

I use it for its main selling point: a realtime backend.

With Firebase, Vue-Fire (Firebase bindings for Vue.js), crossfilter and chart.js, you can whip up a functional and sweet analytics dashboard or [insert pet project here] in a weekend.

It gets the headache of a backend (and user auth) out of the way.

As for security - the Firebase security rules and server side authentication allow you to lock things down.

> With Firebase, Vue-Fire (Firebase bindings for Vue.js), crossfilter and chart.js, you can whip up a functional and sweet analytics dashboard or [insert pet project here] in a weekend.

> It gets the headache of a backend (and user auth) out of the way.

You can get the same if you use other tools.

The realtime stuff is the only big thing they do most other projects don’t, and even for that there are currently several quite well working implementations out there.

Sure. But now I have all this in one service. And when that pet project moves from web to a native app, Firebase has all the trappings to make it easy.

A lot of eggs in one basket admittedly, but that basket looks pretty robust for now.

The realtime database is IMO very cool and it's definitely worth it just for that, but integrated analytics and cloud notifications takes it to the next level.

We hope you'll give the new features a try and let us know what you think!

Authentication is built-in. You can authenticate users and give them specific access with a JSON-like file that lives on the server. It actually works wonderfully.

So if someone were switching from Mongo/Mongoose to Firebase, what's the biggest difference?

I use Firebase in lieu of running my own NodeJS server. I can use a backend PHP web server but still provide realtime capabilities to my app users by using Firebase as a pub/sub system.

The thought of reliable, managed hosting is interesting.

But how does one extend an app outside storing and fetching data? What if you want to run a background job to send emails, parse a complex csv or create a custom pdf and write to firebase storage?

Firebase projects are deeply integrated with Google Cloud, so you can spin up backend resources such as Google Cloud Functions, App Engine, and Compute Engine. Using the Node.js server SDK you can watch for changes in the Firebase Database and act on them. We're thoughtfully considering more holistic ways we can help here.

I'm in talks with a company regarding building an application for users in developing countries, where Android 2.0 is still the dominant OS version.

Firebase 2.0 looks like a great fit for their needs otherwise, but is the new sdk backward compatible to Android 2.0?

So how would one address server side logic?

Like for example doing something with the data before sending it to the client?

I think this is the biggest issue with firebase that I can't find an answer to. It seems everyone is ok with just doing everything on the client side. Schema changes, business logic, etc.

From what I've seen, all backend duties are implemented in a server acting as another client to Firebase. Usually a Node server since Firebase has provided a JS SDK from the start, but I've seen implementations in all major languages.

You either implement some cron task in that server that periodically makes stuff with Firebase, or you use an endpoint in Firebase and use it a task queue for the server.

I'd would be great if someone with more experience could provide more info on how these backend duties are performed.

Edit: see this for more info https://groups.google.com/forum/#!topic/firebase-talk/r4d5H7...

I think services like firebase are a very scary thing. Too much dependence on one vendor, too much black box magic, too much logic that is beyond control. And services like this contribute to general dumbing down of software developers. We're heading towards world of script kiddies where html and js rule and all complex logic is handled and controlled by service providers. Is it a good thing? You can deliver fast, but in the long term is it worth it?

From my experience with the new API, it's a little less intuitive and worse documentation. I think it's rad that Google invested a ton of resources into firebase.

we have been super successful with firebase, and are proponents of using it as a notification system and less of a datastore. That would be easy, but unwise. Use it to notify clients of changes so they can fetch data. Read from Firebase, write to your own server/DB.

I don't think it was explicitly mentioned in the keynote, but it looks like they updated pricing:

https://firebase.google.com/pricing/

Can't find the old pricing now, but it seems similar, but with less plan types.

Here is one third party link I found which still shows old pricing: https://www.g2crowd.com/products/firebase/pricing

If this link is correct the new plans have a changed a bit, but pricing per GB seems to be more or less the same. A few dollars here and there. But this shows that the plans can and will change.

Smaller services like Compose.io (https://www.compose.io/pricing/) and mLab (https://mlab.com/plans/pricing/) seem to be charging around USD 15-18 per GB of DB for MongoDB. So either Firebase is less resource hungry for Google or Google's scale is allowing them to reap better efficiency or Google is subsidising Firebase and giving it almost at cost.

Yes! We updated our pricing. We have fewer plan types (just 3 now), and now have a pay-as-you-go plan which is designed for maximum flexibility. This pricing is cheaper for almost every developer.

Oh sweet, I just noticed that under the new pricing, the free plan includes a custom domain and ssl cert. This was literally the only reason I updated one of my legacy hobby apps to the old Spark ($5 per month for the uninitiated).

It looks like it is here to stay... But that surprise Parse shutdown will leave me asking, what if...

As a server engineer already having trouble finding a new job, how worried should I be about this?

This appears to just be a way to limit the growth of third party tracking which threaten Google by encouraging user acquisition from many sources.

I say this because they dont specifically say they will postback events to advertising networks other than Google's.

For Firebase/Google Cloud Platform engineer: does it mean Google Cloud Endpoints is being phased out? if i'm already using Google Cloud Endpoints, should i move to Firebase? what's the advantage?

Hi -- PM for Endpoints here.

Endpoints is going strong and will have a release later this year that adds support for hosting APIs on more of our compute offerings (Compute Engine, Container Engine, App Engine Flexible Environments). We'll also be adding features, reporting, etc.

thanks! I just feel Endpoints doesn't get enough love from Google. It works nicely, but with minimum feature compared to Firebase (which I don't mind, let it be boring as long as it's not deprecated)

I've had only good experiences with firebase. They added an HTTP api, web hosting, multiple security rule preprocessors (pain point), and got faster and cheaper. Yeah only good things.

The biggest problem with any Google cloud services nowadays is you don't know if it was/will blocked in China, of course it is okay if you don't care the users in China.

I intend to use Firebase as at least a temporary backend while developing my app. Maybe I'll move to a real server later, but during development it's really easy to just have some place you can shoot json at. And I can always add interaction later by having some other application listen to it.

I don't really need the actual realtime communication stuff all that much (though it might turn out to be useful), but just a lightweight place to store json is really useful.

Not expressly mentioned anywhere that I've seen: the Free plan now includes custom domains + SSL cert. Under the previous firebase.com, that was $5 a month.

Sounds good to me!

Is there a tutorial that explains how to setup a backend for user-taken videos? for an IOS app

one thing I liked about Parse was that it's documentation was newbie-friendly.

I've used firebase for other apps but not video storage. From what I've read about how it works, its better to store the media in some 3rd party system such as S3 and keep the link to the file in firebase. Here is one good thread I found with a little searching: https://groups.google.com/forum/#!msg/firebase-angular/xb2be...

Firebase Storage launched today and is perfect for things like storing video! https://firebase.google.com/docs/storage/

Can somebody explain the new Firebase reframing towards GCP? Maybe with another provider analogy? (e.g.,Firebase is to GCP like Parse is(was) to Facebook)

I cover this briefly in my talk today: "Migrate to Firebase" [1]. Google Cloud Platform gives you massively scalable & robust building blocks at the IaaS and PaaS level. You can use these to do just about anything as long as you have the time and expertise. Combining building blocks to follow best practices isn't always trivial, so Firebase offers the next layer higher in the stack. With Firebase you can mix and match pieces that integrate together to be a turn-key backend. We also offer additional services to help you make your app successful once it's been built.

Firebase and Google Cloud Platform play nicely together and we've made sure you can mix and match the pieces you need. E.g. Firebase Storage lets you use Firebase Rules to secure Google Cloud Storage. The new server-side APIs for Firebase are authenticated with the Google's IAM policies.

The two teams are partners and we're excited to be working together.

1. https://events.google.com/io2016/schedule?sid=b4641ff7-0bef-...

This is great! thank you!

Question: Would Firebase be a good option where the desktop/web app is the main access point, mobile been secondary (around 3:1) ?

Most likely, yes. Everything we have for mobile web works just as well for desktop web too.

FYI, new docs on data structure mention rooms, which was an example in the old docs. Should read messages or conversations: https://firebase.google.com/docs/database/web/structure-data...

I'm building a simple web app where I want signed in users to be able to add a JSON object to a database and then list all JSON objects publicly. Only the user who created the object should be able to edit it. Is this a good use-case for Firebase or should I look into something else?

yes, Firebase allows you to isolate user data, and it has built-in auth API.

Feel like the new Wordpress/Drupal/CMS, just in App space.

What is the state of AngularFire library, there are no guides for angular in the new documentation? And when will the angularfire for angular2 be ready to use?

We launched AngularFire2 into beta at ng-conf earlier this month:

https://github.com/angular/angularfire2

Is user email confirmation finally supported by Firebase? Last time I checked it wasn't.

Hi dmitriz! Yes. We have it (currently in iOS and Web, soon on Android), and we're eager to get feedback and work to improve it!

If you try it out, ping me at alfongj at google dot com and let me know what you think!

"... and earn more money." Is this really necessary on the homepage? Sounds like a old misleading spam page

for all of you looking for a real-time api platform that's open source and not owned by a cloud giant come join us build telepat.io

So, Still no offline persistence for JS. What a huge disappointment.

Check out my I/O talk on Friday (Progressive Web Apps on Firebase). While the Firebase Web SDK doesn't support persistent offline just yet, we do have some new ways to get the job done.

https://events.google.com/io2016/schedule?filters=Firebase&s...

Um... what about this?

https://firebase.google.com/docs/database/web/offline-capabi...

The Firebase JS SDK currently supports non-persistent offline. So long as you keep the tab open, Firebase works great offline!

However, if you go offline and then try to refresh the content, none of it will be persistently stored or accessible until you go back online.

Thanks for the clarification.

I was hoping to use Firebase on a React Native app but I do need persistence. Do you have or plan to make some wrapper of the native iOS/Android SDKs for React Native?

Are you sure? They seem to advertise offline persistence for both mobile and web.

https://firebase.google.com/docs/database/#key_functions

Yep, no way close to PouchDB.

Provide a self hosting option or GTFO.

https://github.com/rethinkdb/horizon

Reply on news.ycombinator.com