Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Discussion: How should we use service discovery in Blazor WASM?
See original GitHub issueI was building out a sample that I wanted to contribute via PR. The sample would have a Blazor WASM frontend and a simple Web API backend.
As with the angular sample, I was forced to hard-code the ports so I could know how to call the API on the back-end. The Blazor WASM project runs client-side, so it wouldn’t have access to the server-side configuration settings unless I hosted it in an ASP.NET Core project complicating the sample.
I know hard-coding for client-side apps is the reality now, but is there any plans to ease this minor pain? I saw some issues mention generating constants use a source generator, but that didn’t seem to be in progress.
BTW: The GetServiceUri extension method works well server-side and that was a great addition.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:6
- Comments:7 (1 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Client-side apps are different due to being executed on the client. I think that you either have to request it from the orchestrator somehow or inject it at build time.
Ideally, there would be an API endpoint which the client-side app would request configuration from. Tye could provide that endpoint.
@robertsundstrom hit the nail on the head here; either we need to inject it at build time, which requires knowing about a publicly exposed ingress endpoint, or setup a service/api.
I’m not sure which solution is better here though.