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

Provide better documentation #97

Open
delasource opened this issue May 30, 2022 · 1 comment
Open

Provide better documentation #97

delasource opened this issue May 30, 2022 · 1 comment

Comments

@delasource
Copy link

ASP.NET Core Proxies made easy.

well it may be in your case, but not in mine.

Other users see the usage of the api hard as well. See the other issues: "How would i write... " (#82) or "I Cant figure what i need write" (#90)


In my case, i wanted to proxy my frontend to a react dev server running localhost:3000, which also includes a websocket connection on wss:localhost:3000/ws (for hot reload etc). I still have no clue how to configure both of it in this library.

@twitchax
Copy link
Owner

twitchax commented Jun 1, 2022

The second example here would cover your use case. So, you would just do something like:

app.RunProxy(proxy => proxy
    .UseHttp((context, args) =>
    {
        return "http://localhost:3000";
    })
    .UseWs((context, args) => "wss:localhost:3000/ws"));

If you want to do more complex operations, like pass along the Path to the backend server, then you could do something like this:

app.RunProxy(proxy => proxy
    .UseHttp((context, args) =>
    {
        return $"http://localhost:3000/{context.Request.Path}";
    })
    .UseWs((context, args) => "wss:localhost:3000/ws"));

However, and this is important, this library is generally meant for complex scenarios where something like nginx would not fit your needs. For example, it is really designed for scenarios where you want to use the power of C# to do complex proxying. For example, maybe you need to query a database, or a cache, to discover which endpoint the request should be proxied to, or maybe you need to query a complex load-balancing engine to determine the most efficient backend for the request, or maybe (as was my use case many years ago) you are building an SLA-based scheduler that chooses the best endpoint based on the machine most likely to fulfill some intensive compute request within a specified SLA without wasting resources.

Anyway, all that to say, if this library doesn't fit your needs because it is designed for making complex scenarios easier, you are welcome (and encouraged) to use a more ready-made solution like nginx.

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

2 participants