Firebase gets better analytics, crash reporting and more | Hacker News Reader

Firebase gets better analytics, crash reporting and more

techcrunch.com

130 pointsjamest64 comments

This is great news. My last few web projects have all been based on Firebase because I focus on the front-end these days and I don't have to worry about scaling, databases, API endpoints and other nonsense which consumes a lot of my day. The pain of even getting a VPS deployed with support for Node.js, database and then figuring out some kind of redundancy to keep Node and my database running can also consume your day.

I used to favour Node.js for my REST API backend, but you can't beat the pricing for Firebase and generous free tier. One of the lesser known features is the cloud configuration service which gives you an SDK, it allows me to remotely turn settings on and off, syndicating them in realtime across all devices.

Oh, and the authentication functionality that Firebase offers with the painless SDK is absolutely fantastic. It's crazy easy to add Google/Facebook login functionality to my application and not worry about dealing with the pain of JSON Web Tokens, oAuth authentication and the other pain points of integrating social login. Implementing authentication used to be painful, fortunately services like Auth0 and Firebase are making it easier.

To those wondering who would use Firebase, I am a prime example. I am a front-end developer, but I come from a full-stack background. As I focus on the front-end, I've lost interest in configuring API's and backends, so Firebase handling this for me without needing to really do anything is a huge plus. I have no want, need or desire to ever touch a backend if I can avoid it.

For prototyping, you can't beat Firebase's cloud hosted database which utilises a JSON format to store data aka NoSQL without the scaling pain like MongoDB inflicted upon us. The rules engine that sits ontop of it allows you to configure it however you want, support for indexes and more.

Makes me happy to see that Google is doubling down on Firebase, it truly is a great product and I would be sad to see it discontinued.

Question: How do you deal with authorisation? I've still yet to come up with a solution I'm happy with unfortunately; I'm currently relying on a custom token generated server-side that grants given users particular claims that I then check in the database rules, but it feels... brittle, I guess.

Exact same thing that we are using for a realtime collaborative app. Generate token on server-side with access to certain keys.

However, we had to redo our json structure once we started thinking authorisation. It sucked and in retrospect should have thought about it earlier, but it seems to work.

Typically authorisation layers on top of existing data, but in this case, we had to redo data structure keeping auth in mind. Is that why you feel its brittle?

> Typically authorisation layers on top of existing data, but in this case, we had to redo data structure keeping auth in mind. Is that why you feel its brittle?

That's pretty much exactly it, I guess. It honestly just feels less "secure" than I'd like, even if it's not!

> I'm currently relying on a custom token generated server-side

I don't understand. Where's this server? I thought the point of Firebase was that you don't need a server.

For custom claims on tokens you need a server, unfortunately. I've not found a way around it yet, but I was hoping someone had an idea on how to get rid of it!

I also like firebase. Unfortunately the updates are all for mobile development and not for the web. Also there is no support for angular universal in angularfire?

> I don't have to worry about scaling, databases, API endpoints and other nonsense

You caused a lot of backend developers to shed a tear

detail: You don't have to worry about scaling up to 10-40k connections, which is great for small-medium apps (which is not scaling).

Once you go beyond that you have to manually shard and replicate data between shards and load balance your connections.

I developed my first SWA with angular 2 + firebase database/hosting. In one hand, the dev process is really easy and fast (firebase deploy to upload your website).

In the other end, if you want to be fully serverless it's start to getting more complicated. Using external service to manage form (form.io), page pre-rendering (prerender.io), notification...

I don't know why analytic, crash report are only available on Android/iOS because when you are able to do your sdk on 2 platforms. 1 more shouldn't be that hard.

Firebase needs to get a C++ SDK for Unreal Engine 4 so I can put it to use in the FPS I'm working on.

I would love to setup a master server browser list that updated in real time so that you can see by the moment the availability of servers and stats of current players in the server. I think Firebase would really make this electrifying! Right now the delay that Steam's master server browser list has is just so 1998.

After that I'd add realtime global chat to the main menu of the game and server administration without having to log into a server. Then maybe I'd play around with doing some funky stuff where I push player locations in real time to Firebase and use that to drive a webclient that just renders the map artwork and player location dots.

So many possibilities (!!!) but without a true C++ Firebase SDK I can't justify the time to develop these features or the SDK myself as I have a boatload of other tasks to complete for the game.

If anyone is interested in freelance C++ work and thinks they could create a true socketed Firebase SDK solution (not REST) in UE4 send me an email at contact@drivenarts.com

Hi, Stewart here from the Firebase team.

We released a C++ API for the Realtime Database earlier today targeting iOS and Android, you can get started with it here https://firebase.google.com/docs/database/cpp/start

Using the C++ API within Unreal (assuming you're targeting mobile) is a little tricky as we have dependencies upon Android resources (e.g AARs) that can be hard to integrate into Unreal's build system. You would probably need to list the set of transitive dependencies (see https://groups.google.com/d/msg/firebase-talk/15SdQA8xtnc/aw...).

It would be informative for us to understand which platforms you're targeting and which features of Firebase (we support more than the Realtime Database) you would consider using.

Cheers, Stewart

Thanks for the response Stewart! In my post I completely forgot to mention that the game is currently targeting PC.

Whats the outlook for a Firebase PC C++ SDK? (Right now I'd only be interested in the real time database.)

Given UE4's success I think the effort to support the platform would be worth it. The use cases I listed above are just the tip of the iceberg. Think about it? :P

Yep, thinking ... no commitments for desktop support at the moment I'm afraid :)

Excuse the tangent, but what problem does Firebase solve?

I was updating my app and AdMob and they want me to use Firebase now. https://firebase.google.com/docs/admob/ios/quick-start

I wanted to know why should I include it just to use AdMob so I checked the video on the page: https://youtu.be/9qCxo0D-Sak They promise to explain benefits for me but they only tell me how to use it. The docs also don't do it.

It seems to me that it solves more some problem Google has than the developers have.

Hi, Stewart here from the Firebase team.

https://firebase.google.com/docs/admob/admob-firebase has a pretty good explaination of the benefits. For example, using AdMob + Firebase you'll immediately be able to take advantage of Firebase Analytics to "measure sessions, user demographics, revenue from in-app products" and you'll have a relatively easy path to start utilize other Firebase features - if you want - in future.

Cheers, Stewart

Thanks for answering, I appreciate it.

I already use Google Analytics and it works really great. I don't need the other features and I don't want to include the whole framework just to display ads, it seems really overkill.

I'm glad we have an option to use AdMob separately, please don't take it away.

[Firebase Founder] The combination of the two is meant to help you maximize ad revenue.

Since Firebase has a free & unlimited analytics product, you can see your AdMob stats in the same place as your other analytics data.

From a conceptual point-of-view, the Firebase SDKs are now the place Google puts 'core mobile offerings', AdMob is one of those

With such a generous free tier, what are you guys doing to ensure you will be around in 5 years? Love your service, it just seems too good to be true.

Google bought Firebase back in 2014: https://techcrunch.com/2014/10/21/google-acquires-firebase-t...

Similarly, Google is pushing developers toward Firebase as a replacement for their identity toolkit[1]. However, while reading the provided documentation and tutorials, it's not clear how anything is better than the old toolkit except that the tutorials now assume you'd like to use Firebase to store your user DB (which I have no interest in). I also have trouble discerning where the free ends and usage starts costing money.

Compared to Facebook's acquisition of Parse, I'm happy that the Firebase team hasn't been shut down and has been shipping new stuff. However, it's disappointing that instead of continuing to build a great value-add, they seem to be consuming existing Google platforms and fairly often making the documentation for those things much more confusing.

1. https://developers.google.com/identity/toolkit/

[Firebase Founder/PM]

The Firebase Auth product existed before Firebase joined Google. We've upgraded it significantly, pulling in lots from Identity Toolkit. While we're not at full parity yet, I'd love to hear what's missing for you. There are lots of net-new features we've added [1]

The cost is free for unlimited users (same as Identity Toolkit) [2]

I'm sorry to hear you've had a poor experience with our docs, feel free to respond here or get in touch (james@firebase.com) and let me know how we can improve.

[1] https://developers.google.com/identity/toolkit/migrate-fireb...

[2] https://firebase.google.com/pricing/

What's missing for me is Migration Guide from using official Facebook Login SDK to Firebase's. Also, would be great if there's a list of drawbacks of migrating (e.g. no more FB analytics).

Thanks for sharing. I'll pass this on.

Hi James

Having read most of the login/signup/sign-in documentation from end to end over the past few months (paired with several different implementations), I have most of it sorted for myself.

Early on, what was missing was what the difference between Firebase, Google Identity Toolkit, Google Identity Platform and the various Google+ Identity APIs. I walked in knowing what I wanted: "I have users with email addresses, some of those email addresses are gmail.com, how do I allow them to login to my app with a single click on the Google button? Similarly, my signup only required a validated email address, surely a single click on the Google button is enough to allow that." What I was met with was a choice between what appears to be 5+ different methods of implementation, some of which are enabled by default on my exiting Google Cloud Console others require me to enable new things (Google+) and others still require me to create a new account (Firebase). Some enable me to easily allow me to easily create a user experience that all of my users will be familiar with if they've ever used Google login on a web/mobile application, others require me to implement major portions of the front end of that experience myself (a mobile friendly pop-up for the oauth dance and subsequent token handoff).

I ended up using Google Sign-In for Websites[1], which offered the best trade offs. It's easy to implement on the front end but allows self-management of users on the back end.

I've used Firebase and enjoyed the experience. My own confusion early on had little to do with Firebase or what it offers and more to do with the painfully obvious truth that Google is not of one mind (as any organization of it's size would struggle to be) when it comes to how outside entities should consume it's identity services.

1. https://developers.google.com/identity/sign-in/web/

I am a super happy Firebase user from day zero. I've built many production-ready apps with it and will continue to do so. So far the only features missing that will make it perfect and a complete back-end solution are:

1. Server code (something like parse server code or AWS lambda) to run event triggers (eg: run more complex data validation or trigger a mail/sms after a ref is created/updated)

2. Full text search. When I need full text search on my apps I have to spin-up a server (normally nodejs) and build/keep a searchable index. Then I think: if I have to run/maintain this back-end piece I might as well build an API for my app and solve the lack of back-end code as well.

3. I am still not sold on React/Vue/Angular2 so the tried and tested Backbone framework is my weapon of choice. Sadly enough, there is no official library to implement Backbone-Firebase bindings so I find myself hacking patches.

Have you taken a look at the AWS managed elasticsearch service for your search/indexing?

Yes, it seems like a good solution. I've also rolled out my own: a simple nodejs app that listens to child added/changed events and updates a simple index which in turn can be queried through an API. For now that fits my needs.

On 3, there is https://github.com/firebase/backbonefire, which is our official library for the Firebase Realtime Database + Backbone. We'd be happy to work with you to add additional web features (Auth, Storage, etc.)

Backbonefire does not work with Firebase 3

https://github.com/firebase/backbonefire/issues/152

I use firebase daily for my project. Love these new features in theory, but a little bummed haven't seen analytics or remote config make its way to the web SDK yet (all my projects are webapps).

Framing analytics as the 'heart of firebase' makes me a little worried about the future of firebase for web projects. Is firebase moving away from webapps?

Honest question to Firebase users - with Google's history of ending products, aren't you nervous about building your business on top of this? This seems pretty locked in.

I think the difference for Firebase, and contradictory to what happened with Parse, is that Google is pretty invested in cloud database offerings through Google cloud. My company doesn't use Firebase anymore (though we briefly did while building our MVP), but we would consider it again if the situation was right.

I think you mean "(at the moment) Google is pretty invested in...".

I'm finding I don't trust other companies any more, even those with the best intentions. I'll use them as long as I have an option to switch away to an alternative. If there is no alternative without a rewrite, no way...

I don't know. Sure Google has axed a lot of projects, but how many have they axed the size (and investment) of Google cloud? Just on HN you'd think they have hundreds of people on it just from the "-source work on google cloud" comments.

That's a great question. My answer is a solid YES.

I am worried. My entire business currently depends on Firebase from top to bottom. Of course I would have preferred this were not the case, but the services they offer can get you up and running very quickly.

I have to say, that over time, I may try and build my own tools that I know will exist in 10 years.

I've used Parse extensively as a backed for iOS apps before and lately started trying out Firebase as a replacement. Firebase seems like a decent alternative so far, but there's 2 important features that I'd like to see:

1. Always immediate updates for Remote Config flags - currently Firebase uses old cached flags for up to 12 hours and only allows immediate updates in the "developer mode", but in production, sometimes you need to change a config flag for all users immediately, perhaps to fix a bug, and can't afford having clients still use the old cached values.

Also, it would be nice if Remote Config supported additional data types like arrays, dicts, and dates.

2. A non-realtime key-value datastore - most apps don't require a realtime database, so it'd be great to have a simple datastore where you don't have to worry about managing the number of simultaneous connections.

The free version of Google Analytics gets capped at a certain volume of traffic whereas Firebase doesn't. That's definitely one motivating factor to make the switch.

I'll be interested to check it out when they get around to introducing Real-Time user stats to firebase. That's a pretty crucial component of analytics which I have open all the time.

Google contacted me to switch to firebase from analytics. Seems like they're putting a lot of effort into re-launching the firebase brand this year.

Checkout the sneak peak of Firebase Analytics's StreamView. https://youtu.be/2sCjSz_svdY?t=1787

Also, it sounds like you may find the new DebugView feature interesting. https://youtu.be/2sCjSz_svdY?t=1346

Cheers, Stewart (Firebase team)

That keynote helps a lot, thanks Stewart

What do you do if firebase dies like parse and stackmob? This quora answer makes a pretty persuasive argument as to why you shouldn't rely on these platforms: https://www.quora.com/Why-is-Parse-shutting-down/answer/Tim-...

However the alternative is making your own stack which for small devs is more resources then you may have. Instead of spending time developing the tech that's core you have to create a backend. I had a project on parse but it isn't very successful so I'm letting it die instead of migrating. If it was successful I would have the time & money to migrate it.

Use open source alternatives in a first place. For authentication there is RedHat's http://keycloak.org, thanks to containers it's really easy to setup if you want to try it out. See https://medium.com/@ak1394/simple-social-login-for-react-nat... for an example.

I stopped looking at Firebase for a while since they seemed to have trouble with my multiple, simultaneous Google account logins. Pretty reasonable growing pains actually, and based on clicking around now, possibly fixed.

No opinion on the current news, other than that it's nice to see continued signs of life.

If you use Firefox, that bug won't affect you. But yeah, huge pain, and was difficult to troubleshoot.

The best way around that is to use Chrome's "Switch Person" feature.

Disagree. Google manages multiple logins just fine.

Interviewed a new YC startup recently called Scaphold they are a BaaS using GraphQL.

https://soundcloud.com/user-925097294/mike-paris-founder-of-...

Scaphold, along with Reindex, are pretty interesting. Don't know a lot about graphql, but it looks like they're both positioning to be firebase competitors. Both would have the distinct advantage (for the user, disadvantage for them) of using regular graphql queries in an app, meaning a project could easily migrate from one graphQL backend to another (whereas Firebase would require significant refactoring).

yes it is scaphold.io and there was the first GraphQL summit last week in San Francisco and they were mentioning all the companies changing over and hiring for graphql skills.

Seriously? What about triggers, or running google functions at request? Who needs more analytics functions.

So happy to be wrong about the future of Firebase. Firebase makes it so easy for setting up the basics of any crud and I'm glad Google continues to support it.

Good news & glad to see the continued investment in Firebase. It's quickly become the go-to BASS for our client's React apps; works great with Redux/Thunk.

Any update on the multi-domain hosting [0] issue?

[0] https://groups.google.com/forum/#!topic/firebase-talk/fcpBcB...

A solution is under active development. We don't communicate timelines, but it's a high priority for the team.

> Google decided to double down on Firebase

So much so that they announced the closing down of another realtime service just last week, the Channel API [1], and are trying to funnel everyone into using Firebase instead. Frankly I'm not sure I even want to look into another Google service as I feel it'll get deprecated in no time as well. Better to use someone whose primary business I'm using.

[1] https://cloud.google.com/appengine/docs/deprecations/channel

Any idea what are the alternatives? Dont see similar offerings from AWS or Azure.

One minus point for Firebase is its Android SDK relies on the availability of Google Play services. Most of Android phones in China has no Google Play. So apps can not run even when you do not utilize any of Google Play services. In addition, there is no official words that you can use Firebase services within the great China firewall. It's better to look elsewhere if you have China market in mind.

Alternatives for the whole collection of Firebase services? Not sure, but for the realtime messaging/sync part I found the following four that I'll take the time to investigate as replacements for my Channel API usage.

* https://pusher.com/

* https://www.pubnub.com/

* https://www.ably.io/

* https://framework.realtime.co/

Sounds like a well handled deprecation to me:

> The Channel API did not scale well enough for the workloads it was intended for and so did not find wide adoption.

> You can use the Firebase Realtime Database to achieve superior realtime functionality in your application. Firebase is a more robust and customizable solution than the Channels API, and it allows communication with a broader set of clients. It currently supports Android, iOS, and apps, and web browser apps.

What kind of apps do you build with Firebase? The lack of server-side logic must be really limiting.

Firebase is great for getting up and running quickly.

If you want server side logic then you can use Firebase as a queue. So let the client request data through Firebase and then you have another service monitor the queue and fill requests.

Has there been any commitment stated anywhere to analytics for web apps?

Anyone has link to the new Firebase course in Udacity mentioned in the article?

EDIT: Also, if possible, link to join the realtime analytics beta, as I just checked in the Console, there's nothing new there.

Firebase is fast becoming my favorite platform for Android development. Great feature set. I just hope nothing like Parse befalls it.

It's nice to see the Unity SDK out. What I would love to see is support for unity3d with webgl.

Reply on news.ycombinator.com