How to use with multiple cloud functions

[RSpace]

I have a handful of cloud functions that work together and plan to add more. With the NodeJS 6 Cloud Function Emulator, I can run all of them on a single port for local development and manual integration testing.

With this framework, I need to run each cloud function on a separate port, which can become quite a hassle as the number of functions increase.

How will multiple Cloud Functions be better supported going forward?

[stew-r]

Hi RSpace -- this is the second time I've seen this feedback. We have some thinking to do. I don't have a good answer for you just yet but wanted to acknowledge that we're aware of your request.

[watsab]

Hi ! I'm also interested in this feature. Especially since I'm working with Docker, it means that I need to restart my container when I want to work on another function...
Thanks !

[jessep]

Just came to see if there was an answer. Unfortunately, this is currently a blocker for me.

[dennisnewel]

Same issue here. Not sure how I should/could spin up all the functions at the same time for local development without a huge overhead

[grant]

We'll need to look into how to configure a reverse proxy to host multiple functions on the sample port. This would probably be a wrapper library on top of the functions framework.

Technically speaking, for both local and GCF functions, hosting multiple functions is the same as hosting multiple Node servers.

Some reading:
https://itnext.io/hosting-multiple-apps-on-the-same-server-implement-a-reverse-proxy-with-node-a4e213497345

[grayside]

Is the goal having a single port, or having an easy way to spin up multiple functions without port conflicts?

Much simpler than a proxy would be a script that can look at a directory structure such as:

• my-functions
  • function1
  • function2
  • function3

Then figure out how to assign an unused port to each of them, starting each in sequence.

Developers can implement aspects of this for themselves, here's a couple approaches to help demonstrate the point and enable anyone that wants to try rolling their own solution:

Multiple Functions in One Package

One npm start can be run to spin up all the functions.

First, add "concurrently", one of several packages that facilitate concurrent command execution in a npm script:

npm install --save-dev concurrently

Configure package.json scripts.start:

"concurrently --kill-others \"PORT=9001 functions-framework --target=function1\" \"PORT=9002 functions-framework --target=function2\""

One Function per Package

The developer will visit the directory of each function they want, running npm start as needed:

Let's collect a couple lessons as we go to build up to the new start command:

Decide how to count the number of running function instances:

$(ps -ef | grep function-framework | wc -l)

Route the output to a log file so we can do all this work in a single shell:

...  >> ff.log 2>&1

Configure package.json scripts.start:

PORT=$((PORT+$(ps -ef | grep function-framework | wc -l))) functions-framework --target=function1 >> ff.log 2>&1

Configure the environment for a starting PORT variable:

export PORT=9000

[dennisnewel]

For me it’s about having a single port as that’s how the functions are consumed once in GCF. It’d be a fair amount of extra work to update my front end (JavaScript single page web app) to hit different ports for different API endpoints (functions) for just one environment.

I could likely do all this myself in 15 different ways, but the reason I’m hanging on to the old emulator is that I don’t have to :) it works similarly enough to GCF that I don’t have to worry about it

[quantuminformation]

What was the reason to archive the old emulator?

[stew-r]

It is not, and has not been, properly supported for a while. The Functions Framework is actually used as part of the core product -- we add it to your function code to make it runnable -- so that's a long-term supported path.

We understand that there is currently a use case that is not as seamless using this new tool ("I want to serve multiple functions on my local machine and have them represented in a manner similar to how they're served in production"). We have a few potential solutions in mind, just need to get around to evaluating/implementing them.

[oshliaer]

I'm still wary of the idea of a proxy.

Now I have two dimensions of a project in the context of functions (as a service): (1) functions as Google Cloud entities, (2) functions as elements of a code base. I already use something like http-proxy-middleware in some projects. And I'm worried about the large number of middle proxies.

Does it complicate the development and deployment system?

All my projects already look like @grayside @grant said.

[dupski]

Found a simple workaround for this - just define an "index" function which then calls your other functions for local development, e.g.:

export function index(req: Request, res: Response) {
  switch (req.path) {
    case '/oauth2_init':
      return oauth2_init(req, res)
    case '/oauth2_callback':
      return oauth2_callback(req, res)
    case '/my_func':
      return my_func(req, res)
    default:
      res.send('function not defined')
  }
}

and have that as the target when running the function framework locally, i.e.:

npx @google-cloud/functions-framework --target=index

[quantuminformation]

@dupski would you use the same index for prod?

[quantuminformation]

What do you guys think of the approach that is being done here:

https://github.com/gothinkster/gcp-datastore-cloud-functions-realworld-example-app/blob/master/index.js

specifically with this router:

https://github.com/gothinkster/gcp-datastore-cloud-functions-realworld-example-app/blob/master/src/API.js

Could this play nice with testing multiple functions locally with the FF?

The only thing with that repo is that is isn't that recent, if anyone has any other examples of Real world apps using GC, I'm all ears.

[dupski]

@quantuminformation I guess you could do, but I export them seperately as well for prod at the moment