Solving problems in Firebase during an app mash-up

The other day, my budding development team and I encountered an interesting problem. The three of us had been contracted to write three separate web application that were initially meant to prototype three different functions of a client’s website.

However, there came a time constraint and the group of us were advised to “smush” the three of our apps together into one Firebase-backed back-end. Yet this was easier said than done because one of our apps was entirely in React, while another was in vanilla JavaScript — and another in Node. So, how to make them work?

We eventually built a framing React app that had three separate components — shown as “tabs” — for the three self-standing applications. But, there was then a new question: how do we get all three apps to start talking to each other?

Like, really start talking to each other — and not just as a demonstration?

<ul class="tabs">
<li><a class="tab" href="#create""> <span>✎</span></a></li>
<li><a class="tab" href="#coordinate"">Coordinate</a></li>
<li><a class="tab" href="#review")"><span>★</span></a></li>

It turns out we had actually been working backwards, because the client actually wanted this (which was one app, with one current user object and one user experience as you scroll from left to right across tabs):

Client’s wireframe of the finished application.

One solution that I eventually struck on was to have all of the app components talk to one place centrally. Instead of us trying to decipher each other’s code, and pass UI elements and objects around within our components, why not just keep re-loading the same data source —why not draw all the data from the same well, so to speak?

So we decided to add a “get session” action to the object-placards on the screen (representing the objects available in our database). If a user clicks on that object initially (we are pulling its key into the divs), then a “current session” is set. In fact, it’s taking the current user’s ID as a reference and then setting a key-value pair of { current_object: current_object_id }. In Firebase parlance this is done using set.() rather than .push() so that the current value over-writes whatever was there.

// On the front end in HTML:
<li><a class="tab" href="#review" onclick="getSession(this)"><span>★</span></a></li>
// Leads to this function on the back end in JavaScript:
myRef.on("value", function(data) {
var myRef = firebase.database().ref('session/' + person.uid);
var mySelector = document.getElementById('my-selector');
var currentSessionID = data.val().current_object);
// Then we have the object id and can retrieve what want from it. 
firebase.database().ref().child('objectData/' +          data.val().current_object)
        .on('child_changed', function(data) {
yourFunctionHere(data.key, data);

It’s kind of like saving your progress in a video game. When you return, you’ll by default return to where you left off.

I thought it was a neat insight. It might be the common convention in some places and seem obvious in hindsight, but the process of getting there was one of discovery — of trial and error (mostly because the Firebase documentation was so poor), and thinking on your feet as a deadline looms.

Hope others have had similarly enjoyable moments.


Like what you read? Give Omar’s Codex a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.