User Profiles With Angular and Firebase

so that app, it’s going to need users, right?

i’ve been working on a fun html5 app for a few months now, using angular 1.x, bootstrap , and firebase . angular is getting good stuff done and i have to say i’ve been extremely impressed with firebase, but i’ll get to that in  a bit.

in short: my app is like that of any other startup. a series of sprints leading toward some minimum viable product, with the occasional stumble along the way. anything you can do to shave off a week here or there is a big win. that’s why i’m giving away the user profile management part. if you’re building on angular and plan to use firebase, i’ve already done a lot of the work for you. or at least i can show you the general outlines of what you’ll need to build your own.

after doing a spike on the main functionality for proof-of-concept, the next order of business was to build a user profile management module. and since, as a user, i personally don’t like having to create a username and password for every new site i want to interact with, i’m partial to those who allow me to use social sign-in via oauth . that way, i only have to place my authentication trust in a few big players, and other sites can confirm my identity via those players we both trust.

fortunately, in addition to standard password-based authentication, firebase integrates with google , facebook , twitter , and github out of the box, and it’s a breeze to set them up to work with each other. other options include anonymous login (guest accounts) and custom authentication using secure json web tokens .

i chose to implement sign-in via password and the four social providers. and while the process was relatively straightforward, it was a week or so of necessary drudgery. maybe it will save someone else a few days. that’d be nice.

fig 1: firebase’s flexible authentication options.

a few words about firebase

totally freakin’ awesome. in addition to providing app hosting from a fast cdn, firebase is a queryable, indexable json database, with powerful rules-based security that can be customized down to every node. in this case, we’ve got a “users” node, which contains a node for each user, where the key is a globally unique identifier assigned by firebase. for password-based users, this is just a gobbledygook string. for social network users, it’s the oauth provider name (e.g., ‘facebook’) followed by the user’s id on the provider’s network.

fig 2: the data structure for our basic user profile.

the public and private bits of the profile

even though we probably want to keep the user’s email address hidden from other users, we would want to expose some things, like display name and bio. that’s handled with specific security rules, which you manage in the firebase dashboard for your project.

the key to understanding firebase security rules is that read and write operations are disallowed at every node unless access is granted at or above that node. in other words, access is inherited by child nodes, and can’t be revoked, only granted.

in the demo, the user is the only one (other than the site admin) who can read and write to all of their profile data. note, however, that there is a node called “expose” containing several items (name, bio, image, and achievements) that we expose to other authenticated users on a read-only basis.

also, we use a validation rule to ensure that new items written to the database under the “users” node must have a child called “uid” and its value must be the same as the key the profile is stored under. this way, when we create records in other parts of the database and key them to this user, we’re certain that the user id will always be correct on the profile we retrieve.

fig 3: the firebase security rules for our database.

how do i know the rules work?

a nice feature of the firebase dashboard is the simulator. it allows the admin to fake authentication as any user (or none at all) and then attempt accessing any node. it will tell you explicitly why it allows or disallows any read or write you attempt.

fig 4: an authenticated user is denied access to another’s profile.

fig 5: an authenticated user is allowed access to another’s “expose” node.

think flat, and don’t sweat making calls

we could continue putting lots of collections of things, each with their own controlled-access rules down to a depth of 32 levels. that way, you could fetch every piece of a user’s data (invoices, messages, etc.) by retrieving their profile node.

but the rule of thumb is to think flat. don’t build deep structures, make shallow ones and link them together with keys. treat it like any relational database. make an invoices node, and put all the invoices there. you can index invoices on uid, and fetch all of them for a given user with a simple query.

but that means making a lot of calls if you have a lot of data, right? potentially, yes. but, firebase uses websockets, so each call doesn’t carry the ordinary overhead of an http request negotiation. it comes down to just the bytes required to specify the requested data and the data itself, returned on the already open pipe. http chattiness is minimized, and therefore, the desire to fetch big blocks of data all at once (as opposed to just what you need, when you need it) is too.

in short, firebase is fast, fun, flexible, and highly recommended.

fig 6: the live demo, hosted on firebase's cdn

try out the demo and download the code

aside from user authentication, the demo implements basic navigation and a mobile-first design. the code is open source under the bsd 3-clause license.

repository: https://github.com/cliffhall/angular-firebase-user-profiles

demo: https://ng-user-profiles.firebaseapp.com/

enjoy!