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.
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.
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?
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.
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!
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!
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
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.
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
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.
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.
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.
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.
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).
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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.