Error: Firebase App named '[DEFAULT]' already exists.

3,504 views
Skip to first unread message

Greg Schechter

unread,
Jun 22, 2016, 10:58:37 AM6/22/16
to Firebase Google Group
I'm getting this error in my app.

Error: Firebase App named '[DEFAULT]' already exists.

It's caused because I'm requiring a couple different npm packages that each have their own initializeApp. They happen to all be different firebase projects. This feels like a bug to require all packages that depend on firebase to make sure to include the optional app name parameter in initializeApp. Is there a work around for this? What if I don't own the packages I'm depending on?

Thanks

Jacob Wenger

unread,
Jun 22, 2016, 1:00:30 PM6/22/16
to fireba...@googlegroups.com
Hey Greg,

What packages are you using? All of the official libraries I know that we maintain (e.g. AngularFire, GeoFire, ReactFire, etc.) usually take a Database reference (or the like) instead of initializing their own app completely. If you can point me towards the packages you are using, I can maybe suggest some improvements to those libraries to make sure they aren't doing work that they don't need to be doing. Libraries shouldn't have to call initializeApp() themselves because then they need to handle things like api keys and database URLs and other stuff which will just clutter up their APIs.

Cheers,
Jacob

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/3289f1b1-040f-41ea-bbe9-f46b33a39816%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Greg Schechter

unread,
Jun 26, 2016, 7:50:51 PM6/26/16
to Firebase Google Group
Here are the two packages my project is using.

They both use firebase as their storage layer and are written in a way to be platform agnostic so they can be used in both the browser and a Node environment.  The project that I'm working on depends on both of these packages for some of their serverside calls.

Greg

Jacob Wenger

unread,
Jun 27, 2016, 12:06:50 PM6/27/16
to fireba...@googlegroups.com
Hey Greg,

Those libraries have three options:
  1. Each library could take an app or database reference instead of initializing the app themselves. This is the route the official Firebase libraries take.
  2. When calling initializeApp(), use the second parameter to assign each firebase.App instance a unique identifier. For example, they could do initializeApp(config, "birdList") and initializeApp(config, 'birdLocations'), respectively.
  3. The libraries could check if the app is already initialized for the correct project and, if so, skip the re-initialization.
Cheers,
Jacob

Greg Schechter

unread,
Jun 27, 2016, 1:32:07 PM6/27/16
to Firebase Google Group
I guess I'm a little confused at how these help.  Each of these packages is a separate firebase app.  So I can't pass in a ref because the client shouldn't know what the ref is for those packages.  The whole idea is to build an api that's hides any of the underlying storage and implementation details from the client.  In this case each one uses firebase, but if I ever want to switch one of these packages to something entirely different the api shouldn't need to change.

Jacob Wenger

unread,
Jun 28, 2016, 3:03:36 PM6/28/16
to fireba...@googlegroups.com
You can always go option #3 which sounds like it would work for you. These modules could also be a single module at which point you don't have this issue.

To be honest, your use case is a bit irregular. You are essentially hosting a public data set in Firebase and want people to access it via a non-Firebase, non-realtime API. This is not our target use case and not really what Firebase was designed for. The realtime nature of Firebase is intended to be an alternative to the old-school request / response paradigm you are looking for. Your API would possibly be better off using the REST API if you don't want the overhead of the realtime updates.

Cheers,
Jacob

Reply all
Reply to author
Forward
0 new messages