I'm the guy in that tweet and this is welcome news. The reason firebase+angular gets me so excited is because it's the perfect pairing between a framework that has two-way binding and a backend that supports real-time updating. Not having to worry about asking the server for updates or having to update the dom myself reduces a lot of headaches.
This is cool. Just as a sidenote, myself and other people in the SocketStream community have been doing this for a while now. We integrated Angular with SocketStream + Bootstrap or whatever fairly easily, and happily sync away to the backend with rpc or pubsub. This is the right model for future webapps, IMO.
That's why I like SocketStream -- b/c it integrates with pretty much anything -- but it does have horrible marketing so too few people are aware of it. https://github.com/socketstream/socketstream
I created an entire side project (single-page web app) in SocketStream with AngularJS out front. Hooking up Angular controllers to SocketStream's RPC handlers made for some extremely easy CRUD.
Unfortunately, SocketStream isn't really as mature as older form-oriented frameworks. As an example, a patch was merged into the SocketStream master branch the other day that - I kid you not - marked session cookies as secure =/
That said, I cannot wait for SocketStream to mature, and I hope more people find out about it and dig through the codebase to patch up any other remaining holes.
If you are looking for an open source stack looking to solve a similiar problem, you might want to keep an eye on PouchDB (http://pouchdb.com) as well as CouchDB / TouchDB. (disclaimer, one of the PouchDB authors)
It is nowhere as near as 'out of the box' as firebase is, but every part of the stack is open and I dont think it will take a long time until it is as ready out of the box as firebase is.
I'm falling for the idea of building my next project as a html/javascript app using FireBase (with zero server-side code), but security keeps me wondering, because even after reading everything that the firebase website has to offer about it, I'm still not convinced that it's secure enough.
Am I understanding this right, without explicit rules, anyone can edit all the data in the database? Like anyone can just trash your entire database or fill it with silly amounts of data, using the console, after reading your database credentials in the html file, if you're trying to build an html-only, no-backend app?
I'm curious, how would one build a voting system (a-la hacker news or reddit), what would the permission mask be? Only registered users can vote, but can only increment or decrement the value by x. I'm also confused about how the restriction works, when creating a non-editable title: a registered user is allowed to create a thread and name the title, but is not allowed(not the author or anyone) to edit it after.
If someone could give me a pointer in these use cases, I'd be very grateful.
Good questions! Security is a top priority for us, and we can handle all of the use cases you mention.
One thing to note is that you don't put your auth credentials into the HTML (this would be very insecure!) -- you rely instead on a trusted service to do the auth and generate tokens for you. We provide a means of doing this called Firebase Simple Login, but you can do this yourself if you want as well. We then use these credentials in addition to a security rules language to define the operations a user is allowed to perform to the database. The security rules are very flexible. We have a video here that explains this:
https://www.firebase.com/docs/security-quickstart.html
If you want a full example of security rules in action, check out our Twitter clone Firefeed:
http://firefeed.io
Thanks for that, I've read and re-read the security and the rules pages of your docs several times, but still have questions.
Reading through the firefeed rules file answered a lot of questions for me, except for these two:
1. Editing an existing tweet isn't allowed (".write": "!data.exists()"). How can you make it not editable, but deletable by the author?
2. How would you securely handle liking/unliking or upvoting/downvoting? write if authenticated, validate for the increase/decrease by one, if the user hasn't modified this before? How would that work? Would there have to be a child list of people who edited this? I'm just really curious about this specific use case as it seems pretty common in many apps, yet seems to me, would be really complicated to implement in firebase?
The details here are a little off-topic for this HN thread. Could you open a thread on Stack Overflow and tag it "Firebase", or shoot us an email (support@...)? We support all of these use cases.
I was just looking into using Firebase for a project, alongside trying to choose between Angular and Ember. This might be what pushes me over to Angular.
Not to derail the thread, but can anyone give their experiences using Ember with Firebase? I found a Github project but it's apparently incompatible with the latest version.
While building sample apps with Firebase, binding data changes to the DOM was always the part that seemed to be "missing". We think Angular and Firebase go really well together by filling that gap, and would love to hear your feedback on how we can make the combination even better!
Firebase has a flexible authentication system coupled with security rules: https://www.firebase.com/docs/security-quickstart.html. You can generate your own JWTs (if you have a server or a custom auth backend) or use Simple Login, a service that lets you authenticate against Facebook, Twitter, Github and Persona without requiring you to run any server code. You just authenticate as you would normally in a regular Firebase app, AngularFire will simply inherit the authenticated session.
