Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow removing proxy prefix #176

Open
pete-murphy opened this issue Apr 20, 2024 · 1 comment · May be fixed by #177
Open

Allow removing proxy prefix #176

pete-murphy opened this issue Apr 20, 2024 · 1 comment · May be fixed by #177

Comments

@pete-murphy
Copy link

As of #160, we can proxy requests from "/api" to "http://localhost:5000/api", by specifying

"proxy": {
  "/api": "http://localhost:5000"
}

but we're not able to proxy requests from "/api" to "http://localhost:5000" using this setting; we can't remove the "/api" prefix.

Stripping the prefix seems like a common use case when proxying requests. elm-live's --proxy-prefix is removed by default:

The string passed to --proxy-prefix will be removed from the --proxy-host url. If you would like the url to include the prefix just add it there as well like: http://localhost:5000/api.

This is also how proxying requests works in NGINX config

If the URI is specified along with the address, it replaces the part of the request URI that matches the location parameter. For example, here the request with the /some/path/page.html URI will be proxied to http://www.example.com/link/page.html.

Vite's config exposes a rewrite function that is often used for this purpose, but we can't do this with elm-land's config because we're limited to JSON. There may also be a desire not to expose Vite server options directly.

This has been the only notable painpoint so far when migrating an Elm app—that currently uses these elm-live and NGINX proxy settings to proxy requests to a handful of services that have a shared base URL but no common route prefix—to elm-land. I haven't found a satisfactory solution. In elm-land.json we can specify that each service gets proxied:

"proxy": {
  "/foo": "https://api.some-url.com",
  "/bar": "https://api.some-url.com",
  "/baz": "https://api.some-url.com",
  "/quux": "https://api.some-url.com",
  ...
}

which works, but we also need to maintain an identical mapping in our nginx.conf.

@pete-murphy
Copy link
Author

pete-murphy commented Apr 22, 2024

There are a few possible solutions I can think of:

  1. We could accept a mapping from RegEx to replacement string. So if we want to proxy requests from "/api" to "http://localhost:5000", our elm-land.json would have

        "proxy": {
          "/api": {
            "target": "http://localhost:5000",
            "pathRewrite": {
              "^/api": ""
            }
          }
        }

    This is following http-proxy-middleware's API, which is also what Parcel and Webpack expose in their proxy options.

  2. A prependPath or stripPrefix boolean for the most common use case

        "proxy": {
          "/api": {
            "target": "http://localhost:5000",
            "stripPrefix": true
          }
        }

    I think this would be similar to prependPath from http-proxy options.

  3. Keep the existing API, but change the behavior to something more like elm-live's --proxy-prefix/--proxy-host args, so

        "proxy": {
          "/api": "http://localhost:5000",
        }

    would proxy from "/api" to "http://localhost:5000" instead of "http://localhost:5000/api". This seems simplest, but could be a potentially confusing breaking-change.

pete-murphy added a commit to pete-murphy/elm-land that referenced this issue May 12, 2024
Fixes elm-land#176

The behavior is based on the `pathRewrite` in `http-proxy-middleware`
where the first matching pattern determines the rewrite:
https://github.com/chimurai/http-proxy-middleware/blob/f2a0af329969f8a70b3967a969146758a73d8b0e/src/path-rewriter.ts#L33-L39
@pete-murphy pete-murphy linked a pull request May 12, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging a pull request may close this issue.

1 participant