Support bring-you-own-function projects for swa start

[danwatford]

Is your feature request related to a problem? Please describe.
To develop static web apps with functions that take advantage of managed identity it is necessary to deploy the functions to an functions-app separate to the swa-app and then link them together. This is referred to in the documentation as Bring Your Own Functions.

A solution which makes use of Bring Your Own Functions will often use two git repositories to store the SWA and the function-app sources.

With remote development approaches such as codespaces or docker containers becoming more common, it is likely that the developer will find themselves running/debugging the SWA and the function-app on different network hosts. They may also deploy the function-app to Azure and want to run/debug their SWA app locally.

When the function-app is running on a different network host to the swa-cli, the developer will need to specify the URL to the function-app as an HTTPS URL. Currently the swa-cli does not support this use case, but can be made to do so with a few changes.

Describe the solution you'd like

Support proxying of API requests to APIs hosted on remote hosts, using HTTPS URLs.

Allow use of insecure connections to the remote API similar to the -k | --insecure command line option in curl. This is to handle the case where the API host is using wildcard certificates which do not appear to be accepted by the http-proxy node module used by swa-cli.

When proxying requests to the remote function-app, swa-cli should rewrite the host header to match the URL of the function app. Without this the function-app host will receive a request with a Host header of /localhost/ and will respond with a 404.

Describe alternatives you've considered
When running the function-app in GitHub codespaces, port 7071 can be shared publicly. I tried making this available over HTTP, but this does not appear to supported for public ports.

VS Code will forward ports in codespaces to the local development host. I then tried using ngrok to make the local port available at a public HTTP URL which could be accessed by the swa-cli running in another codespace, but ran into connection issues around wildcard TLS certs used by ngrok.

Additional context
Setting a remote URL with the --api-location option to swa-cli start causes swa to attempt to resolve the URL as a filesystem directory. It is necessary to also specify the --api-devserver-url option.

However specifying --api-devserver-url only causes swa-cli to not be aware of any API server settings since conditional logic prevent --api-devserver-url being examined if --api-location is not also specified. Therefore in testing (of updates to swa-cli) I had to use command lines similar to:

node dist/cli/bin.js start http://localhost:3000 --api-location dummy --api-devserver-url https://codespaceshost-7071.githubpreview.dev

Changes needed to support this use case

• net.ts parseUrl function should return port 443 for HTTPS URLs. Currently it returns 0 which causes a timeout in subsequent connection checking. See https://nodejs.org/dist/latest-v16.x/docs/api/url.html#urlport which explains the parsed port from a URL can be an empty string. PR fix(core): identify correct default port for http and https urls #524 merged.
• msha/handlers/function.handler.ts should optionally call httpProxy.createProxyServer with { secure: false } to prevent connections to remote function-apps failing due to wildcard TLS certificates. Addressed in PR feat(start): allow insecure https connections to remote api hosts #534. (Update 2022-10-03: No longer needed. Only the host header change, mentioned below, is necessary for TLS connections to remote API hosts)
• msha/handlers/function.handler.ts injectHeaders function should set the host header to match the host of the remote function-app. Without this change the host header will remain set to localhost and proxied request will likely fail to get routed corrected at the remote host. Addressed in PR feat(start): set host header in proxied requests to match remote API hosts #578.

With the above changes I was able to connect swa-cli to a remote function-app addressed via an HTTPS URL.

[sgollapudi77]

Fixed by #524

[danwatford]

@sgollapudi77 - this is not complete - still two other items that need to be addressed.

Please see last part of the issue text and reopen.

I'm working on the other items at the moment.

[manekinekko]

Thank you @danwatford for identifying this issue and working on it.

[davide-bergamini-sevenit]

Please finish this, it's very important for us

[carovegas]

Are there any news regarding this issue?

We are also facing problems trying to work locally in the front-end app pointing to the remote azure function.