We do this in our node.js/express production app
(
https://circuithub.com -- you have to sync a component to your
library to see the Firebase stuff):
> Another approach you can take is to never have your clients talk
> directly to your servers; have all of your data pass through Firebase. You
> can then set up your server as just another client (using our Node.js
> library) and have it synchronize and process data as needed.
Unfortunately, I don't have any good nugget to extract to show you
(if you have any specific questions just ask), but in case you're
worried about being the first one to go with that approach, you're not
alone. :)
There is a users --> username key for each user that we authenticate.
The server (with it's own credentials) then writes to the user -->
username of the specific user it wants to communicate with but doesn't
register for the callback. Fortunately, we don't need to disambiguate
multiple servers. The client is updating state as things change, but
the servers don't actually need to consume those state changes until
other things happen. That isn't true in reverse (server changes
trigger callbacks on clients).
I'm re-working on a project called atmosphere (currently based on
RabbitMQ) to use Firebase to do more complex things around "jobs" and
disambiguation of the server response. I'll notify the list when I
release (hey Firebase team, I could really use the
run-a-Firebase-server-locally feature that's been discussed before to
enable local dev and debug -- Thanks!).
Overall, we've been *extremely* happy with Firebase's performance in
our production node.js/express app so far. I think you can confidently
more forward with your plans in the node.js/express world.
Warm regards,
-Jonathan
Jonathan Friedman
CircuitHub, Inc.