Firebase Leaves Beta Today | Hacker News Reader

Firebase Leaves Beta Today

firebase.com

239 pointslyime44 comments

Before I worked for ReadyForZero and before I started Light Table, I built a whole bunch of "real-time" infrastructure for a little live-blogging as a service company I started called TypeWire. It was miserable, difficult, full of quirks, had very unusual scaling characteristics and just a huge mess. I sincerely wish something like Firebase had existed back then, because it would've completely trivialized what I was trying to do. And that's the way things should be. We shouldn't be constantly rebuilding infrastructure, we should be solving problems - and Firebase is a wonderful way to get you back to solving problems.

I've been good friends with these guys for a while, and I'm impressed with how well they've done, how much people seem to love the service, and just the general quality they instill in what they do. Congratulations guys, it's been awesome watching you get to here.

This is one of the reasons I'm absolutely itching for the Light Table plugin system -- it'd be awesome to collaboratively edit (and maybe evaluate!) code using Firebase.

Can't wait!

Congratulations! Firebase is very compelling.

Personally, I have been trying to determine if I should buy or build a new mobile game backend that has an average of 50-250K iPhone app downloads/month. I'm adding online multiplayer to an otherwise single-player game.

I've looked at Firebase and a number of other offerings include Exit Games' Photon Cloud. Firebase had seemed to be expensive for my use case of ~ 400K MAU. However, Firebase's experience of 1 CCU = ~ 1400 MAU [1] would be easily supported under the "Candle" or "Bonfire" tiers which are not expensive.

Exit Games' has a different experience [2] but I'm probably comparing apples to oranges a bit. Games vs Big Brother. Well, there is Roll20 so maybe it's at least comparable experiences.

1 CCU = 1400 MAU vs 1 CCU = 20 MAU

That's a big difference. Am I thinking about this strangely?

[1] "In our experience, 1 concurrent corresponds to roughly 1,400 monthly visits." https://www.firebase.com/pricing.html#pricing-faq

[2] "To calculate monthly active users (MAU) we assume a CCU to translate into 10 daily active users (DAU) and each of these into 20 MAU" https://cloud.exitgames.com/Pricing

I agree Firebase's plans are poorly worded. If your app just has to sync stuff (and can then disconnect from Firebase) you can have a lot of users and will still only have a few concurrent connections. If your app relies on real-time data with a Firebase connection, you will have a lot of concurrent connections.

Source: Been using Firebase beta as a developer for 2 months

The stat listed on our site is for a typical website. If you have a mobile app, or an atypical website, your mileage may vary. Even for highly engaging, paid apps I suspect you'll find it's in the 100 to 1 range (or more). 1 CCU = 20 MAU is very high.

For example, World of warcraft peaked at ~10% of their users online at any one point recently: http://venturebeat.com/2012/11/07/wow-pandaria-1-million-con...

Also note that we bill at the 95th percentile, not peak usage, so you can spike well above those numbers without consequence.

If you want to know how many concurrent users you'll need, sign up, drop in our script, and have your clients connect to Firebase (but do nothing). You'll be able to see concurrent user counts under Analytics in Forge.

That's a valuable data point about WoW; thanks!

I like your idea of just adding Firebase and testing the waters. Alas, the next version of my app is a rewrite to Unity3D and there is no Firebase client for Unity3D (yet?) so this amounts to just feeling things out.

I love Firebase and was planning on using it as a back-end for a JavaScript game I'm making. However, since there doesn't seem to be a way to prevent cheating without adding an extra server layer I had to drop the idea.

Something as simple as preventing people from just manually setting their own score on a leaderboard seems to be impossible. I would be very happy to be proven wrong though.

That's a great point. I'd be eager to hear a response as well.

You typically cannot trust the game client so either you'd have to submit the scores to your own backend and then forward to Firebase or perhaps use .validate rules as per:

https://www.firebase.com/docs/security/security-rules.html

I'm guessing you were using Firebase before our security and validation rules were released. We now have a very powerful method for controlling data access and validation that can secure your data.

There's a screencast on our website that explains how this works here: https://www.firebase.com/docs/security-quickstart.html

Thanks but I don't see how security rules will prevent someone from manually setting their own score. Take your 404 Astroids game as an example. Right now anyone can set their own score as they wish. Is there a way to prevent that using security rules?

You can enforce this as well as any other backend can. Games are a bit of a special case because you not only want to enforce access controls and a particular data model, you also want to make sure the client didn't "cheat".

It turns out this is an issue with any game that runs on the client though -- regardless of if you're using Firebase or not. Preventing cheating is tough because at some step in the process here you're relying on the client to tell the server the truth. Since the game runs on the client, you can't ensure that the code hasn't been tampered with, or that an AI isn't playing the game, or that the user hasn't cheated is some other way.

With Firebase security rules, you can enforce that only that user can set the score, and you can enforce that the score is of a valid format, but fundamentally there's no way to ensure that the score is "real".

No, but you can make it much more difficult by passing something like a frame of the game state, where some variables (like Timer) are passed in plaintext, and others (which are calculated in an aggregate way at runtime, e.g. can't be easily guessed) are hashed for double checking by the server. Of course double-submission is still an issue, but nonces and server-side duration checks should help you here as well. Compress the &*!# out of your source and.. it will at least take an attacker a lot of time to break.

afaict (would loved to be proven wrong here) Firebase gives you basic protection but any script kiddie will still be able to defeat it.

Edit: grammar

When you say 'game that runs on the client' -- I'd clarify that you're talking about the authoritative game logic.

Ie most multiplayer games ship the same physics code on client and server, but the server is the authority.

That kind of game is clearly impossible with Firebase, but depending on the expressiveness of the validations, there might be ways to prevent cheating.

    allow update of y_pos IF jump.pressed 
    AND not jump.wasPressed 
    AND new.y_pos - old.y_pos < 3 
    AND old.was_on_top_of geospatial( world_geometry, entities)
    AND new.not_inside geospatial( world_geometry, entities)

I came to the same conclusion that Kiro did when I evaluated Firebase a few months ago that I would always end up needing some server-side validation even with the authentication and security rules but I think I just noticed something useful.

Apparently you can get the actual data being used when writing the rules expression by using the `val` function[0] on the `data` variable[1]. However, your docs called the rules expression "Javascript-like"[2] which makes me wonder what limitations exist on the expression syntax. Since I can call `val` to get the primitive value, can I use Javascript functions/properties on those primitives like `length` on arrays?

Here's a use case, given an object that looks like

    { name: "Adam", family: { spouse: "Eve", children: [...]}}

Will the following expression work to limit changing the name of the spouse if there are more than 1 element in the children collection:

    "$spouse": {.write: data.child("family").val().children.length < 2}

Not quite sure if you can write a rule for a property within an object but if the above works, then the rules system is pretty damn awesome :)

[0] https://www.firebase.com/docs/security/rulesdatasnapshot/val...

[1] https://www.firebase.com/docs/security-quickstart.html Ctrl+F "We use the "data variable"

[2] https://www.firebase.com/docs/security-quickstart.html Ctrl+F "We use the "Javascript-like"

When the floods hit Alberta, I saw a need for a realtime communications app to match volunteers with the victims who needed them. So I had a weekend project on my hands.

Without much/any javascript/web experience I was able to take their existing twitter-clone implementation and transform it into a flood relief application http://highriver.abfloods.ca/

It never really got the traffic that I had hoped, but the whole development process went very well and I got the support from them that I needed. Thank you! I'm looking forward to their upcoming developments.

I would love to see a highscalability.com article from the Firebase guys talking about how they handle the load, particularly with strategies around broadcasting X messages to Y clients who are distributed across Z servers.

(Or if anyone has links to similar discussions around scaling strategies in a messaging-heavy distributed architecture, that would be great as well!)

I used FireBase to power my multiparty WebRTC video chat, and the entire codebase is < 300 lines. What is the most exciting for me is that FireBase also has an iOS and Android SDK, letting me work on mobile apps that plays nicely with my WebRTC app without having to worry about implementing a real time backend: http://opentokrtc.heroku.com/

The only feature I wish that firebase would have is the ability to detect when the last person has left the connection. Currently, the only way to accomplish this is with their nodeJS module.

This looks good. But I do have some doubts regarding its querying abilities. As far as I can tell, you can only define a range of data to be fetched (limit). If I want to query for a particular value, i.e. fetch all users matching name - that doesn't seem possible. Or am I missing something?

It's possible, but you'll have to structure your data slightly differently. There's a blog post detailing one possible approach: https://www.firebase.com/blog/2013-04-12-denormalizing-is-no...

We're working hard in regards to adding more powerful query support to Firebase though and would love your feedback so we can improve the API (just email support@firebase.com).

Really happy for the firebase team. Here's something that's been bugging me for a while (and why I only used firebase on pet projects rather than my main systems):

1. How does it work with non-only web stuff such as background workers, C, Python software, etc.

2. What about the hosting for html/css/js?

Here's a real world example:

I've got a python software that scrape an uploaded PDF for patients data and then create a kind of todo list for doctors/nurses/students. That todo list is accessible from the web - more specifically from a mobile browser. The front-end was hacked using html/css/js (angular).

I really wanted to use Firebase but struggled about the 1) and 2). It seems that the solution is to use a VPS to host a node.js back-end, but rather than using mongo it should use the firebase database through their node API, amicorrect?

For some reasons, when I thought about using firebase, I expected it to host the html/css/js files and provide the background jobs. Why can't I just have a some_task.js and call it from my js code using firebase API? I.e.

    Firebase.async('some_background_function', function (result) { .. } );

Same for hosting.. I thought of firebase more like a one-stop shop.

As you can see, I might be a bit lost so please feel free to point where I'm wrong!! : )

Firebase is terrific and this is great news it's fully launched. I've talked with their founder in depth about their growth plans and I'm very impressed and excited for them.

Can’t rhyme the unrest over the NSA leaks with the praise for this database as a service. If this becomes popular, just plugging into one service will give secret services etcera access to many websites. And since its out of your control, you’re not going to find about it either.

This tale of internet surveillance is not an abstract stories with bad and good guys, it has happened through the sum of all our own practices, the way in which we have built web services, and the dependencies we construct. Lets take that into account into our daily lives as developers ( /rant )

Firebase looks awesome and would be great for something I'm working on. The first thing I did was check if it was based in America then decide not to use it.

They are synchronizing your data so it's all going through their servers.

I think it's a great idea, unfortunately I won't be using it.

The combination of Firebase, Angular, and Node.js is the most powerful development platform that exists today. I wouldn't build any web application without these three.

FAN for the win.

That's good news, but with their production version, the pricing also changed. I believe before they had more of an AWS/S3 model paying per GB stored and transferred. Now I need to pick a tier, and pay monthly.

Congrats! Firebase is awesome.

Rohan! haven't seen you around in awhile!

Great project! :)

Congratulations on arbitrarily incrementing a version number?

I really don't understand why anyone would be willing to use something like this for anything beyond a toy website. I would be very wary of using a closed source commercial database for any core infrastructure, I can't imagine a scenario where I would be willing to use any kind of 'highly proprietary database as a service'. It's vendor lock of the worst kind.

you clearly haven't used firebase

Firebase can take over having to use server side cookies & site settings for each user. You can use an oAuth login and then sync their settings to the firebase backend. That's how I've used it, with great success.

Firebase makes it possible to make a fully-featured and complex website with pure HTML/CSS/JS and no big backend crap (looks at PHP/MySQL)

I'm not saying you can't get value out of it. If your website is very simple, or not very valuable, then use whatever gets it done nicely.

However, if you are doing anything serious or valuable or even moderately complex, locking into a single vendor like this is a bad decision. You can go along fine, but sooner or later you will need to do something that is just not possible inside of the proprietary system. At that point, you are either going to have to jump ship and reimplement features (introducing regressions and wasting development time), or try to convince the vendor to make changes to enable you, or give up. You are handing over a lot of power to someone and in exchange paying them a lot of money. I'm not saying it's never a good decision, I'm saying if there were something my company depended on to function, I would think very hard before I chose a solution that permanently locked me into a single vendor.

Here's some violent agreement...

I think this is a great product - if I am building a site, I want to concentrate on building features for that without first building technical bleeding-edge interaction from the ground up.

Sooner or later I may want to do something with this that isn't possible in the proprietary system, yes (although that's not guaranteed at the starting point).

If I get to that point with traction and money to invest, I probably would do exactly what you suggest, i.e. build a bespoke solution.

And, in that case, since the Firebase system acts as a modular component, refactoring this solution might even be a better option than refactoring a messy roll-your-own solution.

[Firebase Founder] Hi Justin, we're pretty excited about leaving beta and think it's fairly significant. Building robust infrastructure isn't an easy task and this change is meant to signal that we're ready for primetime. I hope that comes across!

If you're worried about lock-in, I'd first try Firebase along with our AngularJS[1] or Backbone[2] bindings. You don't have to change the way you write your app and can switch Firebase our for another backend easily. We recognize that we're only going to win a developer's trust by building a reliable service with the best tools and fair pricing -- so this is what we're going to do

I'd love to dispel any concerns, please feel free to email me anytime (james at firebase)

[1] https://github.com/firebase/angularFire

[2] https://github.com/firebase/backfire

Hi James, thanks for the thoughtful reply to my grumpy trolling.

I can at least tell you what would dispel my concerns:

1. Some kind of death-rattle clause. If your company doesn't make it or shuts down this service, all the code necessary to set up the service would be released under a permissive license, something like that.

2. The ability, even if it had a high cost ($100k a year or something crazy), to license the source to the engine that powers Firebase and deploy a modified version (obviously just for our own use).

I think those two things would mean that if I were making decisions on the technical direction of a company or large project, I wouldn't feel like Firebase might suddenly cause a major disruption in the future. At least if there were a major incident or insurmountable problem with the service, we could bring it in house and proceed without having to go back and re-engineer all the previous work.

I'd think you'd use a service like Firebase in much the same way people outsource IT infrastructure to the cloud. Eventually you reach a scale that it pays to bring the infrastructure in house. That might/might not happen with your product. Also, there's a lot of products where you're not going to care about 95% of the data in a few years anyway - trendy games maybe?

Anyway, I'm intrigued about the idea around Firefbase for allowing people to quickly start executing on their ideas and focus on what seems to matter a lot these days, the front-end.

I'm also appreciative of the AngularJS bindings....will definitely make me check this out...

I've seen worse on the internet :)

To answer your questions:

1. We put our code in escrow for very large customers. We are thinking about the best way to address the concerns of everyone else. Stay tuned.

2. This is coming. It'll be a little while.

Thanks again for your comments. Criticism helps us figure out where we need to improve.

"Congratulations on arbitrarily incrementing a version number?" ...

Such a shitty attitude. I give the guy from firebase who replied to you credit for not being snarky when your comment started with that ignorance.

Are you saying that there is a non-arbitrary criterion to when '-beta' is removed from a product's logo?

If not, then it is arbitrary, and acting like it is a milestone is purely a PR move, an attempt to make noise and create interest without any substantive event which would justify calling renewed attention to the thing, all for personal financial gain.

In other words, it is an attempt to manipulate people for money.

I'm all for manipulating people to make money, but I hardly think you can fault me for pointing it out.

I think there's something to be celebrated about finally standing up and saying "OK! This is done enough to call it done". As a software creator it feels great. Software is never truly finished but taking that step and declaring it a released product is something. I'm never going to convince you of that, I know. You're obviously a "this glass sucks, whatever it's half full of sucks and whatever used to be in the other half of it sucked too" kind of guy.

A journey of a thousand miles ends with a single step.

When a developer-facing API goes "stable", it is a signal for the developers who might use that API that it is no longer subject to changes and that it's ready to be used in production. This is very different from, say, removing the "Beta" status from Gmail, because it meaningfully impacts the audience.

Reply on news.ycombinator.com