Testing database functions locally

[mInzamamMalik]

It looks like firebase cli tool bundles all dependencies and upload it to firebase just like aws lambda function does. But it takes too much time to be done even on minor changes in code and also need a good connectivity of internet . If you are offline for some reason, you are just in dark what code you are writing until you have a way to execute and test that functions offline on your local machine.

Is there any way to test firebase functions locally?
if there is no, then why?

[laurenzlong]

Hey malikasinger1, you can check out our documentation for how to write unit tests: https://firebase.google.com/docs/functions/unit-testing

Google Cloud Functions also open-sourced a local emulator, and we are working to build a tighter integration with Cloud Functions for Firebase. In the meanwhile, you can check it at here: https://github.com/GoogleCloudPlatform/cloud-functions-emulator/

[mInzamamMalik]

Dear @laurenzlong I was not talking about unit testing
I want to run firebase functions locally, just like we can run aws lambda function locally,
either it is possible right now?
if not, are you guise planning to give this facility in near future?

Thank you,
Inzamam Malik.

[laurenzlong]

Hey Inzamam, thanks for the clarification. I accidentally copied and pasted the unit testing link twice. I've revised my response above. The emulator does allow you to run functions locally. Here's the documentation that explains how to use it: https://cloud.google.com/functions/docs/emulator

[atomicleopard]

How this emulator support the firebase specific parts of GCF (i.e. ref().onWrite() ? I haven't found any specific docs for this? Dev cycle while deploying up to the cloud is sort of excruciating, it would be great to be able to do this locally.

[laurenzlong]

Hey @atomicleopard this is something that we are still working on. Stay tuned!

[stephenhandley]

hi @laurenzlong any updates on firebase integration in the emulator?

[laurenzlong]

@stephenhandley Just released! https://github.com/firebase/firebase-tools/releases/tag/v3.8.0
Only HTTPS events for now, but other ones are coming!

[stephenhandley]

@laurenzlong awesome thanks!

[mismith]

Any update on the local Database events @laurenzlong?
Loving functions overall, but developing is currently a nightmare..

[laurenzlong]

Thanks for the follow up! We're prototyping it right now. Would love everyone's feedback on how you would prefer to invoke the emulated database function. Would you rather it be listening to your production database? A test project's datebase? Invokable through a terminal command?

[ryanm2000]

+1 for through a terminal command

Thanks for the great work @laurenzlong

[ahaverty]

We're using separate projects for production/sales/Dev/Dev2 .
Dev2 if more than one of us are working on functions/rules simultaneously.
Local deployed (debuggable?) functions via Firebase tools cli (or IDE/IntelliJ support?) would be great, mainly to avoid the delays with deploying.
I can't imagine how this would work alongside remotely deployed functions, maybe you could give us an idea of how you're thinking of architecting it?
Could a local deployed function overrule a remote one? And automatically switch back on once it's killed locally? How would that work then with multiple local deployments? 🤔
Can't wait👌

[mismith]

@laurenzlong I'm using a separate 'root' within the same project (e.g. /production/data/1 vs. /development/data/1) simply because this was the easiest to get up and running. It's definitely a tough problem to solve, and as you can already see, tons of different perspectives and alternatives to support. Maybe a terminal utility would make sense, something that kind of 'links' the path(s) being watched to the functions being called? e.g. maybe the dev can map which project/path/etc goes to which functions via some config file (with sensible/configless defaults, of course)? Even hardcoded JSON/dummy-data would potentially be better than nothing, at this point.

Btw, thanks for being so responsive and inclusive on this! 🤘 firebasers 🤘

EDIT: is this along the lines of what you mean by the terminal command?: firebase serve --only functions; firebase trigger-function "foo"? or maybe something more generic with a custom path like firebase simulate-write --path="/foo/path/to/bar/with/function/watcher" --data-file="baz.json"?

[jaufgang]

I think the locally deployed database function should definitely listen on a real database rather than being invoked through some terminal command. Whether it listens on a production or test DB would be up to the developer, they should be able to choose which database by calling firebase use before deploying locally.

I like @ahaverty's suggestion that when you run a database function locally, it could send a message to firebase to temporarily disable the cloud listener for the same function, and when the local function listener disconnects the cloud function automatically would take over again. That may not be necessary in all cases though, since it may be innocuous to have multiple listeners on the same node depending what the function does. Perhaps a command line switch could specify whether to temporarily disable the cloud function, and by default it would not. Something like:

firebase serve -disable-cloud --only functions:function1

This would disable the cloud listener of function1, while function1 was being served locally. If there were a function2 in the cloud, the listener for function2 would not be affected.

If you omitted the -disable-cloud switch, the cloud and local listeners for function1 would both be triggered.

If -disable-cloud is invoked by two different developers on the same function at the same time, the second one should just see an error message that this action is currently disallowed because another -disable-cloud is already being used on that function. Dev teams could avoid this scenario by using different test databases for different developers if they choose.