Firebase 'Friendly Pix' : Data structure, and Auth

Googles Firebase team have created a demo social media app called FriendlyPix, to give some examples of best practise when creating a social network with a Firebase back-end. Its like a simple Instagram, allowing users to upload photos, comment, etc.

You can get the original iOS version from here.  At the time of writing, theres a design document, which gives a general overview of data structures and how things work in a superficial way, which is available here.  I haven't found a more detailed discussion of the iOS version though, so thats what I'm aiming to do with some articles here.

Data Structure

Its handy to have a look at how they have structured the data, considering their social network (like most) has users, posts, comments, likes, followers, and a personal 'news' feed.  Ive sometimes wondered on the various merits of alternatives ways of structuring that data.  The solution for FriendlyPix is described in the design doc, but heres an overview:

• (root)
• people
• user_id
• searchIndex (full_name, reversed_full_name)
• posts (ids..)
• etc
• posts
• post_id
• author (full_name, pic, uid)
• full_storage_uri
• etc.
• comments
• author_id
• post_id
• author :
• text :
• timestamp : etc.
• feed
• user_id
• post_id : true
• followers
• followee user_id
• follower user_id
• likes
• user_id
• post_id : timestamp

Firebase structures data in the database as JSON. You can examine it at any time on the Firebase console and have a look at what is where, which makes it nice and easy to use. So at the top level the data is sorted into these 6 arrays : People, Posts, Comments, Feed, Followers and Likes. Below that, People and Posts then have a unique key to identify each user or post, and within each lie the details. Comments, Feed, Followers and Likes are structured first with the id of the user that each relate to - so for e.g. the first set of keys in the comments array is an array of author_id, which is a copy of the user_id of the user that created the comment, followed by the post_id that the user commented on, and then the comment details. Similarly the Likes array first has an array of keys of the user that created the like, then the post_id that was liked.

Within a single user_id element, there are full_name and reversed_full_name properties, which is done to help speed up searches for users.

Firebase Auth

Firebase has a whole pod dedicated to 'Auth', and a section on the Firebase console. In general everything within Auth is dedicated to helping us recognise who a user is, and give them access to data, or get them 'logged-in'.

For a simple start in getting users authorised for your app, you can enable email/password authorisation in the Auth area of the Firebase console. Then the following code within an iOS application would create a new user, and if successful, the user will be logged in (via the code in the completion closure).


The default setting on the Firebase database is that without this authorisation, a user cannot access data. So on a simple level, this code has also unlocked the database for the app to query from now on (unless you change settings and open it up for unauthorised users).

Having authorised the user, the app goes on to ensure that the user details have been added into the People array in the database. The following code will add a new user into that People array in the main database, if it doesn't already exist, or update it if its there already.


As I mentioned above, the People array within the database has user_id's as keys at the top level, which is why the database reference above looks like : .reference(withPath: "people/\(user.uid)"). Beyond that you can see the dictionary structure that will populate that user in the database - profile picture URL, full name, etc.

At no point do you need to go into the Firebase console and add properties to data models or anything like that. The code snippet above has directly created the JSON in the database, or it has updated the entry if that key (the user_id) existed already. This is one of the reasons why Firebase is so nice and easy to use - you just send dictionary structures to the database with key values that you have decided upon, and the data is created and saved away for easy extraction later.

I'll be writing a few more articles on this app shortly. I'll be looking at how the Feed page organizes batched downloading of posts next. All feedback or questions welcome of course.