Firebase Realtime Database - Database trigger structure best practice

Question

I have some data in a Firebase Realtime Database where I wish to split one single onUpdate() trigger into two triggers. My data is structured as below.

notes: {
  note-1234: {
    access:{
      author: "-L1234567890",
      members: {
        "-L1234567890": 0,
        "-LAAA456BBBB": 1
      }
    },
    data: {
      title: "Hello",
      order: 1
    }
  }
}

Currently I have one onUpdate() database trigger for node 'notes/{noteId}'.

exports.onNotesUpdate = functions
.region('europe-west1')
.database
.ref('notes/{noteId}')
.onUpdate((change, context) => {
  //Perform actions
  return noteFunc.notesUpdate({change, context, type:ACTIVE})
})

However, since my code is getting quite extensive handling both data and access updates - I am considering splitting the code into two parts. One part handling updates in the access child node and one handling the data child node. This way my code would be easier to read and understand by being logically split into separate code blocks.

exports.onNotesUpdateAccess = functions
.region('europe-west1')
.database
.ref('notes/{noteId}/access')
.onUpdate((change, context) => {
  //Perform actions
  return noteFunc.notesAccessUpdate({change, context, type:ACTIVE})
})

exports.onNotesUpdateData = functions
.region('europe-west1')
.database
.ref('notes/{noteId}/data')
.onUpdate((change, context) => {
  //Perform actions
  return noteFunc.notesDataUpdate({change, context, type:ACTIVE})
})

I am a bit unsure though, since both access and data are child nodes to the note-1234 (noteId) node.

My question is - Would this be a recommended approach or could separate triggers on child nodes create problems?

Worth mentioning is that the entire note-1234 node (both access and data) will sometimes be updated with one .update() action from my application. At other times only access or data will be updated.

Kind regards /K

score 1 · Accepted Answer · answered Aug 08 '20 at 15:42

It looks like you've nested two types of data under a single branch, which is something the Firebase documentation explicitly recommends against in the sections on avoid nesting data and flatten data structure.

So instead of merely splitting the code into two, I'd also recommend splitting the data structure into two top-level nodes: one for each type of data. For example:

"notes-data": {
  note-1234: {
    author: "-L1234567890",
    members: {
      "-L1234567890": 0,
      "-LAAA456BBBB": 1
    }
  }
},
"notes-access": {
  note-1234: {
    title: "Hello",
    order: 1
  }
}

By using the same key in both top-level nodes, you can easily look up the other type of data for a note. And because Firebase pipelines these requests over a single connection such "client side joining of data" is not nearly as slow as you may initially think.

Thank you Frank! :D I will begin by implementing two triggers and plan for a flattening of the data structure real soon. It will be a bigger job though since I already have code depending on the nested structure. :/ Will keep "flaten data structure" as a mantra in my mind from now on! ;) /K — Kermit, Aug 08 '20 at 21:19

Firebase Realtime Database - Database trigger structure best practice

1 Answers1