GoogleCloudPlatform / functions-framework-nodejs

FaaS (Function as a service) framework for writing portable Node.js functions
Apache License 2.0
1.29k stars 158 forks source link

Web Server Context Path #45

Closed hrovira closed 5 years ago

hrovira commented 5 years ago

Having some difficulty with the development web server, and the GCF web server having different context paths. Deploying a web application as a cloud function called "helloworld", the URL takes the form: https://us-central1-MYPROJECT.cloudfunctions.net/helloworld

But when I use the functions-framework to launch the local web server... the URL lacks the context root.

functions-framework --target=helloworld

Serving function...
Function: helloworld
URL: http://localhost:8080/

Formerly, the GCF emulator would provide URLs that would closely match GCF... http://localhost:8010/MYPROJECT/us-central1/helloworld

It would be more convenient, if dev environment matched the GCF context path, or if we are given an option start the web server with the same context path. Currently having to deal with alternative webpack configurations, and figuring out how to properly specify the URIs for AJAX calls to be agnostic of the deployment. (I was trying to use relative URLs but the dev and prod environments are not consistent...)

Maybe related to a different issue, in which user wanted to deploy multiple functions within the same webapp, but would have to launch multiple dev web servers on separate ports, and run a proxy in front.

grant commented 5 years ago

Trying to understand the issue. I think you're trying to say that it would be nice if the functions framework had a:

MY-PROJECT/MY-REGION/ prefix to the localhost hostname to make the URLs more similar?

I could see how that would make dev/prod environments a little bit more similar, but you'd still have a different URL host.


The other issue about deploying multiple functions is already tracked in GoogleCloudPlatform/functions-framework#59.


Given we don't want to tie this library too much with the previous emulator or Google's Cloud Function URLs (we want this framework to run in all sorts of environments, I think we should probably not add this and just let the developer map 1 URL to another.

What do you think?

hrovira commented 5 years ago

I don't particularly need the MY-PROJECT/MY-REGION prefix, but that might help with keeping it consistent across environments.

However, I realized that the best solution to my problem is to use express internally to manage the routes to my individual HTTP functions, and just deploy a single http-trigger function. I was also able to manage the different URLs by specifying an alternate "publicPath" in my webpack configuration for production.

On Mon, Jul 8, 2019 at 10:39 AM Grant Timmerman notifications@github.com wrote:

Trying to understand the issue. I think you're trying to say that it would be nice if the functions framework had a:

MY-PROJECT/MY-REGION/ prefix to the localhost hostname to make the URLs more similar?

I could see how that would make dev/prod environments a little bit more similar, but you'd still have a different URL host.

The other issue about deploying multiple functions is already tracked in GoogleCloudPlatform/functions-framework#59 https://github.com/GoogleCloudPlatform/functions-framework/issues/59 .

Given we don't want to tie this library too much with the previous emulator or Google's Cloud Function URLs (we want this framework to run in all sorts of environments, I think we should probably not add this and just let the developer map 1 URL to another.

What do you think?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GoogleCloudPlatform/functions-framework-nodejs/issues/45?email_source=notifications&email_token=AACHVLP2W5E7ZSKSPX7DKH3P6N3VVA5CNFSM4H2VOUT2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZN2KJY#issuecomment-509322535, or mute the thread https://github.com/notifications/unsubscribe-auth/AACHVLNP4KBHRQZELCBMIITP6N3VVANCNFSM4H2VOUTQ .

grant commented 5 years ago

OK. It sounds like you've been able to solve the issue with using Express routing.

If you want to add a doc on how to use WebPack with the publicPath option, that would be great.

Please re-open if there's anything else we can help with.