Playing with Fire(base) – Three Way Data Binding

I’ve been playing with Angular and Firebase over the last few days. But it sounds better the other way round. I remember one of my school teachers getting angry with some other kid being naughty and shouting “you are playing with fire!”. Except the teacher was German so it was “you are playing wiz fire!”. We used to shout that at each other for a while after that. Kids, eh?

Anyway, one of the core principles in Angular is two-way data binding between the model and the view (in your MVC structure). The user changes the data in the view, it gets changed in the model. Some code changes the data in the model, it gets changed in the view. It’s pretty neat in practice and makes pages feel really dynamic as you interact with them.

So that’s two-way data binding but what if you could go another layer down and bind that to your database as well and have all three update whenever any one of them is changed? Well that’s what Firebase allows you to do through the AngularFire library. You just bind your model to a Firebase object and you get this:

three way data binding

(Normal Angular data binding is the bit within the browser window frame)

…click here to read the rest…

Implementing Roles in Firebase

Roles in Firebase

Firebase provides a JSON-based language for us to restrict different parts of a back-end database to different users based on their auth token id (auth.uid).

That’s handy enough for restricting a user to only be able to see their data but what if you want to assign some roles to distinguish between user types and give those roles different permission levels throughout your Firebase database?

Well, that’s something I’ve been flirting with over the last couple of days with some limited success but today I stumbled on a project built by Firebase themselves called Firechat and I just wanted to draw people’s attention to it as it has a pretty useful rules.json file that gives a good example of how to implement read and write permissions at different levels of the database tree.

I don’t really like that the default permissions in Firebase are read and write on everything. I do like that in this example they are both set to false for everything and then you have to explicitly set how you want to handle permissions for everything down the chain.

So in this example we’re looking at chat rooms which have users and moderators. Here’s the rules file on Github:

And here’s the Firechat app in action:

It’s pretty useful to see a full app built by the Firebase developers to get some insight into how they use it and/or expect it to be used. I think this is a better example to work from than the Gist here which comes high in Google at the moment.

…click here to read the rest…

Playing with Fire(base) – Preamble

Firebase wants to take the headache out of building full-stack JavaScript apps (and mobile) by taking care of your back-end and authentication for you.

But first a little background…

When I first got into the idea of full-stack Javascript about 6 months ago, my first step was to start playing around with Node.js and then Angular trying to connect the two but I quickly became frustrated with every step requiring me to learn some new component that would make my life easier (Bower, Gulp, Grunt, Sass, etc) but only after I’d got up the learning curve. Each time becoming another step removed from just writing some code of my own.

In the end I put it all to one side and just focussed on building an entirely front-end single page app (SPA) in pure Angular so that I could learn some of the principles without the clutter and confusion of working out what was doing what. Fortunately I’d chosen a little toy project that didn’t require me to build a back-end as I was building on top of Spotify’s API –

Anyway, at that time I did look into a couple of Backend-as-a-Service (BaaS) providers, including Parse, whom I see today are shutting down their service and releasing some of their code into the wild for people to use on their own servers. A shame for them – the absence of reasons in their statement I suspect means it’s down to not being able to sufficiently monetise their product. I guess the BaaS area will become commoditised pretty soon with Google, Amazon and others fighting to be the Supreme Cloud.

One thing that might help Google with that is their acquisition in 2014 of Firebase which is really what I’d planned to write about but maybe I’ll just leave this post here as a thought on getting started in full-stack JavaScript (too many things you might or might not have to learn) and on the future on BaaS (probably a race to the bottom on pricing which will be won by the players that can afford to make a loss until hardware costs catch up with their low prices and until after the competition are gone).