Provide naming convention that is not derived from filename

[goleary]

In my project my functions are laid out as such:

-src
 |- index.ts // imports & rexports all functions
 |- plaid/index.ts
 |- stripe/index.ts
 |- splitwise/index.ts
 |- transactions/index.ts
 |- auth/index.ts

Plaid, Stripe & Splitwise are 3rd party services that my application interfaces with and mostly have https functions defined within although there are also different types of triggers. transactions & auth refer to data in my application and are either firestore or user triggers.

Each of these subfolders has a single index.ts because none of them have gotten big enough to warrant splitting into multiple files. Inside this file there are often utility functions that are used across multiple functions for the same service.

I have 20 functions across all of these files/services.

If I understand correctly, to use better-firebase-functions I would need to split my 5 files up into 20 files (1 for each functions) + more files that would hold utility functions for a specific service.

The main reason I have ended up here is to try and speed up the cold start of my functions, and I plan to explore that a bit more fully before I resort to reorganizing my entire functions code base.

I'm leaving this here in case I'm missing something and there is a way for me to use this lib without reorganzing everything, or in the hopes that this feedback helps you adapt this library to suit more people's needs.

[george43g]

Hi goleary,

The complexity of your project is perfect for a tool like BFF.

In case you haven't yet, definitely check out this detailed guide I wrote on structuring Firebase Functions: https://medium.com/@george43g/organise-firebase-functions-part-1-optimize-cold-start-time-cd36f76d2133

Now, regarding naming triggers - it is possible to customise via the config object:

• how the function trigger is extracted from the module
• how the function is named based on its filename

There are certain deliberate limitations in place to maintain the speed boost that this package is meant to give you - and to get it you should follow the convention. The article above sorta explains how it works.

If you want to boost your cold start, it makes sense to split all of your functions up. Because each time you require() a module, every dependency that that module has is also require()d. By splitting up your functions, you ensure that for any particular invocation, you are only require()ing what is needed for that function.

Furthermore, BFF can't load each file to check what's exported from it in order to find and return the function trigger currently being called - as this would require every module to be loaded and inspected. This would defeat the purpose - which is why BFF bases the name of the function on the name/path of the file - BFF must be able to locate the correct module given its corresponding function name.

It's also a good idea to split up your utility modules so that no function ends up loading utilities it does not need.

The idea is that for each function, you want your dependency graph to be as small as possible - to load the very least possible modules to execute that function.

I will be releasing an update which helps you bundle and minify your functions (using uglify/webpack under the hood) - this will hopefully provide further optimisation.

If you want to explain what your ideal use case would be, I'll see if there's a way that a feature can be added to BFF in order to facilitate your use case.

What would you like to see? Multiple functions per file? How would you want them named? etc...

[MikaelAmborn]

Could you give an example how the feat(extracttriggers) commit allows for having multiple function triggers per file? Wouldn't funcNameFromRelPath have to return an array of function names for this to work?