3 ms·
"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
by Mister_Snuggles 10y ago
"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?
If so, that's scary. Really, really scary.
- baptistejamin 10y agoWe used Firebase ACL to prevent from that. Our backend were already splited.
- Mister_Snuggles 10y agoOk, 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?
- thruflo22 10y agoA 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'.
- inlined 10y agoThe 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.
- asciimike 10y agoFirebase engineer here: 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/ 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 https://firebase.google.com/docs/database/security], which this article mentions, and Firebase Storage [https://firebase.google.com/docs/storage/security] 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 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/ http://jsfiddle.net/firebase/VBmA5/ and secure client side only trades: http://jsfiddle.net/firebase/j562wj1r/ http://jsfiddle.net/firebase/j562wj1r/). FWIW, this system is not a concept unique to Firebase. Parse has user ACLs (PFACL, PFRole on iOS for instance: https://parseplatform.github.io/docs/ios/guide/#roles https://parseplatform.github.io/docs/ios/guide/#roles), and Horizon has it's own Rules templating system ( http://horizon.io/docs/permissions/ http://horizon.io/docs/permissions/).