"Server-less, doesn't mean code-less! This means that all your server logic is now in your web or mobile client."
Does this mean that the web page you serve up contains all of the code to talk to Firebase? Doesn't this mean that all of your clients have unfettered access to the database? Would all of your credentials (e.g., API keys, etc) be baked right into the pages you're serving up?
BaaS (and "serverless" in general) mean that since you don't control your database/storage/servers/etc. you no longer have the ability to implement your own custom Authentication and Authorization.
Firebase solves this by using Firebase Authentication (https://firebase.google.com/docs/auth/) to determine who a user is and Firebase Rules (currently implemented in the Realtime Database [https://firebase.google.com/docs/database/security], which this article mentions, and Firebase Storage [https://firebase.google.com/docs/storage/security]) to determine what a user can do. Yes, they're different languages, and we're working on upgrading the Realtime Database to use the new language syntax (we know it's a pain point, and we plan to address it).
I strongly recommend watching our I/O talk on "The Key to Firebase Security" (https://www.youtube.com/watch?v=xAsvwy1-oxE) which walks through the basics as well as shows the power of our rules system. While you probably can't specify all of your business logic in our Rules languages, you can enforce a vast majority of cases (including building things like per user rate limiting: http://jsfiddle.net/firebase/VBmA5/ and secure client side only trades: http://jsfiddle.net/firebase/j562wj1r/).
Ok, so Firebase already has a way to make sure clients can only look at/update data they're authorized to do so?
What about business rules? Is there a way to enforce that, for example, when one product is ordered an additional item is automatically added to a shopping cart (e.g., if I buy a computer, my province requires a recycling fee be paid too)?
Or does this get beyond what Firebase is meant for?
The rules for the Firebase Database allow read & write access as well as validation. It may not handle every possible case of business logic, but it's a very powerful tool.
A common pattern is to have a server process running that watches parts of the firebase tree and then runs business logic in response to changes.
It's described as client - db - server rather than client - server - db. I believe there are also Firebase queue and task abstractions that make it fairly easy to map a write to a 'backend handler'.
Does this mean that the web page you serve up contains all of the code to talk to Firebase? Doesn't this mean that all of your clients have unfettered access to the database? Would all of your credentials (e.g., API keys, etc) be baked right into the pages you're serving up?
If so, that's scary. Really, really scary.