The "Firebuilder" pattern for structuring Cloud Functions for Firebase apps

I recently spent time trying to achieve the following intertwined goals all at once for a current and future Firebase projects :

• A clean organised convention for multiple apps, in a single functions folder eg. public endpoints plus a private API
• To be compatible with Firebase hosting, local “firebase serve” emulation, and plain node.js for local debugging eg. in Jetbrains WebStorm/IntelliJ IDEA etc
• To support the use of express.js to host an entire app per function, rather than one function per endpoint
• To make efficient use of how Firebase creates a container per function. Each container has code for all functions, but only one function will ever be executed by each container. Therefore, only the setup code for that function needs to be executed.
• To support express-compatible frameworks — Feathers.js in particular

The result is https://github.com/buzzware/function-split-test, which demonstrates what I’m calling the “Firebuilder” pattern.

Usage is as follows :

1. Ensure your project’s endpoints are grouped and hosted as a small number of express-compatible apps
2. Create a build_<app>.js file per app, with a build function that returns an express-compatible app. These files should not call listen()
3. Copy firebuilder.js, index.js and index_node.js to your project
4. Modify index.js and index_node.js to call loadAndBuild() for your apps and “use()” them onto the main app.

This pattern can support the simplest of apps, implemented solely in the build_* file to the most complex apps loaded from a subfolder.

Overall, I’m pleased with the result, and intend to apply this to current and future apps.