How to Make Your Firebase Application Open Source Friendly

Serverless Technologies & Open Source

Serverless technologies like Firebase are great options for hobbyist developers because they are very affordable for small projects; however, you might have experienced some difficulties sharing your lovely projects with the open source community because of the nature of serverless: a big chunk of your app is managed by the platform provider (GCP, AWS, etc.).

The first and most obvious way to share your project is to invite your contributors to your Firebase project. This is a big hurdle for contributors because they can't even run the app until they reach out to the maintainer and gain the maintainer's trust.

Another approach is to make your project configurable, so that the contributors can set up their own Firebase project and wire it into your project. This is better than the first approach, but it is still a nuisance for contributors.

Strike a Balance

So here's my suggestion: accept that your repository is tied to your Firebase project, but make use of the local emulator to get rid of the contribution hurdle.

This approach doesn't require inviting everyone to your Firebase project, because emulator can be run without credentials.

A drawback of this approach is that it becomes harder to use your code in another Firebase project. I think this is a reasonable compromise to make because contributors will have easier time by skipping the configuration step.

Tips

Here are some Firebase-specific tips to make your project more contribution-friendly.

Make your local app zero-config

Make sure the contributors can run your app locally without setting any environment variables, or at least try to minimize the configuration process.

Provide valid default values for Firebase API key, auth domain, project ID, app ID, etc., so that contributors don't need to provide them manually.

Ideally, a contributor should be able to get started by running yarn && yarn firebase emulator:start.

Commit your .firebaserc

Check in your .firebaserc to the repo with your Firebase project name.

{
  "projects": {
    "default": <your-project-name>
  }
}

There are many advice against this practice because this will tie your repository to your Firebase project; however, Firebase local emulator asks the developer to log in with Firebase credentials when .firebaserc file is missing. Therefore, this is a crucial step to minimize the configuration hassle for your contributors.

If you're using external services

It is common for an application to make use of external services like Stripe, Mailchimp, etc.. If you need secrets to access these services, use Google Cloud Secret Manager. Since contributors cannot access your secrets, I suggest using something like MSW to mock these services.

If you're using Firebase Hosting

If you're using Firebase Hosting service, make sure your proxies are configured correctly. Here's an example of hosting configuration (firebase.json):

{
  "hosting": {
    "public": "app/dist",
    "ignore": ["firebase.json", "**/.*", "**/node_modules/**"],
    "rewrites": [
      {
        "source": "/api/**",
        "function": "api"
      },
      {
        "source": "**",
        "destination": "/index.html"
      }
    ]
  }
}

If you use a dev server for local development, you would need to set up another reverse proxy like this:

Conclusion

It takes extra effort to build an open source application with serverless technologies, but it is certainly doable. Although I only covered Firebase in this post, there are other tools that provide local emulation (e.g. LocalStack). If you're considering which platform to use, pick one with local emulation support or a Docker image.

Going serverless means you have less control over infrastructure details. But that doesn't mean you need to compromise the contributor experience. You'll see that you can streamline the setup process to a pleasant level.