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

danwatford commented 2 years ago

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

[X] 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 #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 #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 #578.