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

Reverse proxying to a service with open_api_spex #643

Open
oceanlewis opened this issue Nov 6, 2024 · 0 comments
Open

Reverse proxying to a service with open_api_spex #643

oceanlewis opened this issue Nov 6, 2024 · 0 comments

Comments

@oceanlewis
Copy link

oceanlewis commented Nov 6, 2024

There's a scenario I want to explore which is:

Let's say we have two Elixir servers:

  1. An external-facing Gateway API that proxies to...
  2. an Internal-only API

In the Gateway I'd like to apply custom limiting logic to incoming requests based on the caller's identity, and if all is good we proxy the request to the Internal-only API.

Both servers have OpenAPI specs available (thank you open_api_spex), but from the caller's perspective only the Specs defined inside the Gateway API would be available.

My question is, how feasible would it be to dynamically load the Internal-only API's OpenAPI spec at startup time inside Gateway API and generate the schemas/routes/etc. so that external callers can see the available proxies endpoints as well as their Open API schemas via Swagger/etc? In addition to this, how feasible would it be to add the required authorization header token definition to the exposed endpoint request object specs that are unique to Gateway API (as in, Internal-only API doesn't know about this auth header and it's added in by Gateway API to all endpoints it proxies to)?

It would be nice to have/build this dynamic proxy behavior, the alternative being copy-pasting code or managing external libraries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant