Q:

Is it better to send two requests or one when indexing a Firebase?

My Firebase looks like this:

- widgets
  - abc123abc
    - key1: val1
    - key2: val2
    - key3: val3
    - ...
  + abc123abd
  + ...
- widgets-index
  - abc123abc
    - timestamp: 1289183274834
  - abc123abd
    - timestamp: 1289183274834

I am storing a collection of widget objects and simultaneously keeping a separate list of their indices. When I fetch data from a selected object using a view of indices, I need to obtain a subset of the data object's properties.
I read somewhere that Firebase uses web sockets so I should not worry about the performance cost of multiple fetches? Did I understand that correctly?
At what point should I store the entire subset of object properties at the widgets-index node instead of making a separate call to /widgets?
Edit:
The solution to this problem can be found here.

A:

The Firebase Realtime Database supports arbitrarily complex atomic deep updates (blog post). It works like so:
You can update any arbitrarily deep path with a single .update() call
The full path on the key side of your update map will be replaced, so you must address subkeys directly if you don't want to blow away the parent
Paths are relative to your current ref
So let's take your example:
var update = {};

update['emails/email3@example,com'] = {new: 'data'};
update['emails/email4@example,com'] = {new: 'data'};
update['users/c0djhbQi6vc4YMB-fDgJ/emails/email3@example,com'] = {new: 'data'};
update['users/c0djhbQi6vc4YMB-fDgJ/emails/email4@example,com'] = {new: 'data'};

firebase.database().ref().update(update);

This will update all of the locations simultaneously. To make it dynamic, simply use string interpolation when constructing the keys.
Disclaimer: This answer is copied from here. Originally answered by: @Michael Bleigh

