Looking for examples of firebase usage with node / express

9,934 views
Skip to first unread message

Dan Chilton

unread,
Jan 28, 2013, 9:02:10 AM1/28/13
to fireba...@googlegroups.com
Can anyone point me to some good examples of firebase integration with node / express?

Patrick Williams

unread,
Jan 29, 2013, 10:29:54 AM1/29/13
to fireba...@googlegroups.com
Here's the main file from one of my projects that uses firebase and node/express


It is probably helpful if all you want is to get the basic plumbing working, but not sure if it has value past that.

Dan Chilton

unread,
Jan 29, 2013, 7:48:00 PM1/29/13
to fireba...@googlegroups.com
Thanks Patrick,

I'll check it out tonight.

Dan Chilton

unread,
Jan 30, 2013, 12:04:23 PM1/30/13
to fireba...@googlegroups.com
Well, Patrick's example helped me create and set the auth token, but I'm still at a loss on how to get facebook / twitter authentication up and running. I ended up porting firebase into passport to get twitter authentication working, but I'm not happy with all the code cruft to get it running. You can see it here:


I'm surprised there aren't more examples out there for facebook / twitter integration in express. Any other suggestions?

Rob DiMarco

unread,
Jan 30, 2013, 12:50:22 PM1/30/13
to fireba...@googlegroups.com
Hi Dan -

Generally speaking, authentication with Firebase means generating a signed authentication token, which contains some verified user data that you've specified. This authentication token, once verified, gives you access to that user data via the 'auth' variable in our security rules language.

Broadly speaking, you can generate Firebase authentication tokens and begin using them in two ways: (1) generate the tokens on your own servers using one of our JSON Web Token libraries, or (2) using Simple Login, which will generate auth. tokens and authenticate to Firebase with them automatically.

The first solution, server-side token generation, is intended to be used when you already have authentication in your application, and want to integrate that authentication with Firebase. The latter is to be used when you're not running your own server, and want Firebase to handle all aspects of authentication for you.

For your case, we don't currently offer Facebook / Twitter / etc. authentication via Node, since our authentication flows for these services are entirely client-side. However, if you're interested in running your own server and implementing your own authentication via these services (using something like a Node app running Express + Passport), then you're doing things correctly by authentication the user, generating an authentication token using your Firebase secret and specifying the user data that you're looking for, and using that token to authenticate with Firebase.

It might be helpful to learn a bit more about your use case and what you would like you user flows to be, and then we can discuss application architecture and authentication further. Let me know if any of the above was unclear.

Thanks!

Rob


--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Dan Chilton

unread,
Jan 30, 2013, 1:39:03 PM1/30/13
to fireba...@googlegroups.com
That's very helpful, Rob. Thanks for the run-through.

Patrick Williams

unread,
Jan 30, 2013, 2:34:14 PM1/30/13
to fireba...@googlegroups.com
I'm actually doing something similar where I want my node server to operate on behalf of a user. In this case, the user still goes through the client sign authentication flow, but once that's done, the user object with have the access token stored at firebaseAuthToken. If you pass this to your calls to your server, you can call auth using this value to authenticate server side as a specific user. 

Andrew Lee

unread,
Jan 30, 2013, 2:42:21 PM1/30/13
to fireba...@googlegroups.com
Beware that when you call "auth()" on a Firebase reference, it changes the authentication for all references to that Firebase. So if you're calling auth() on a node server using a client-supplied token, all Firebase activity coming from that Node client will be treated with those authentication credentials. 

We recommend authenticating your servers using either your Firebase Secret (giving full read/write access to Firebase -- It's your server code -- you should be able to trust it!) or a custom generated token that grants the server access to only pieces that the server should be touching. If a client is proxying any calls through your servers to Firebase, you should then be enforcing access control in your own server code.

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.

-Andrew
--
Andrew Lee
Founder, Firebase
http://twitter.com/startupandrew

Dan Chilton

unread,
Jan 30, 2013, 2:45:08 PM1/30/13
to fireba...@googlegroups.com
Would love to see an example of the latter set-up.


--Dan

Andrew Lee

unread,
Jan 30, 2013, 2:46:59 PM1/30/13
to fireba...@googlegroups.com
Here's a "work-queue" example I put together a few weeks back:


-Andrew

Patrick Williams

unread,
Jan 30, 2013, 2:47:16 PM1/30/13
to fireba...@googlegroups.com
That's actually today's project...I'll post a link to the src when I'm done

Patric Lanhed

unread,
Jun 20, 2013, 5:11:08 PM6/20/13
to fireba...@googlegroups.com
Bump :) I'd love to see some examples too! But hopefully the examples section will grow soon as they are hiring an evangelist!

/Patric

Jonathan Friedman

unread,
Jun 20, 2013, 5:47:00 PM6/20/13
to fireba...@googlegroups.com
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.

Michael "Kato" Wulf

unread,
Jun 20, 2013, 6:58:01 PM6/20/13
to fireba...@googlegroups.com
I've done a few privileged consumers (worker threads). In fact, in my app, we used this approach exclusively--no servers or APIs anywhere, just data consumers eating and regurgitating the datum back into Firebase, which makes the perfect stack to set these little workers on.

As for code examples, we use the firebase-work-queue for all of our privileged processes. There's nothing else to show for an example--just our proprietary data manipulations and task scripts that get invoked by the work queue.

The only interesting thing at all in our node.js code, besides the work queue, is our Firebase promise wrapper, which converts all our calls to Deferreds, which suits my usage patterns.

For recurring events and maintenance, I created a little "cron" worker that schedules events to get pushed into the queue, but the code for that is just a setInterval() that checks certain Firebase paths and queues events as appropriate.

So I'm doubly curious what sorts of examples would be meaningful, as I can't find hardly anything to do server side that's more difficult than a Firebase.on('child_added', ...) or a queue consumer anymore : )

Cheers,




Michael Wulf
www.wordspot.org


Andy Joslin

unread,
Jun 23, 2013, 3:34:34 PM6/23/13
to fireba...@googlegroups.com, dan.c...@gmail.com
Here's a couple of files I'm using on a project.

I created a small abstraction of firebase in express which allows me to make tokens really easily and know when firebase is auth'd really easily.

I also have a file in here which will send an invite email whenever a child is added to an 'invites' area under 'farms/$id/invites/$email'


Hope this helps :-)
Reply all
Reply to author
Forward
0 new messages