search

dotnet / tye

Tye is a tool that makes developing, testing, and deploying microservices and distributed applications easier. Project Tye includes a local orchestrator to make developing microservices easier and the ability to deploy microservices to Kubernetes with minimal configuration.
MIT License
5.28k stars 521 forks source link

Discussion: How should we use service discovery in Blazor WASM? #582

Open seesharprun opened 4 years ago

seesharprun commented 4 years ago

I 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.

seesharprun commented 4 years ago

I put a stripped-down WIP Blazor app here: https://github.com/seesharprun/blazortye

marinasundstrom commented 4 years ago

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.

marinasundstrom commented 4 years ago

I found this while browsing NuGet:

https://github.com/WildGums/Blorc.Tye

jongio commented 4 years ago

It would be great to get official guidance from Microsoft on best approach here.

azsdke2e azsdke2e2

jkotalik commented 4 years ago

@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.

marinasundstrom commented 4 years ago

@jkotalik Excuse me for repeating myself:

Just ask yourself: What would the Azure Team come up with. So that is why I believe that they would server the configuration just like you would a appsettings.json through some endpoint. I don't know what is best when it comes to security though. These are public endpoints anyway and Blazor webassembly apps should not expose any secrets, like API keys and connection strings. That should be on the server-side.

The cases might differ when you run standalone Blazor or hosted Blazor (or any other app type).

I would probably implement it like this:

  1. Endpoint on the server-side with logic for exposing the configuration. If it is an hosted app then this would not be trivial. A package to install basically. Tye would handle the rest.
  2. Then a library for the client that fetches that data and exposes it through the Configuration API.
  3. In your standalone client-side app, you have to specify the endpoint in appconfig.json (or similar). This can be injected att development and even when you publish the app in containerized form.
jongio commented 4 years ago

I ended up using ingress for this:

So in my blazor app, I just need to bind to the same host that the blazor app is bound to. B/c of ingress it appears to be the same host to the blazor app.

  - name: ingress
    rules:
      - path: /
        service: memealyzernetwebapp
      - path: /images
        service: memealyzernetapi
        preservePath: true
      - path: /image
        service: memealyzernetapi
        preservePath: true
      - path: /config
        service: memealyzernetapi
        preservePath: true
      - path: /imagehub
        service: memealyzernetapi
        preservePath: true
    tags:
      - staging
      - prod