Why use an API when blazor.server can call the gRPC directly

[Steven-Beasley]

The issue I see is that you are losing the compression of protobuf, by using an api to pass JSON, when it can be completely bypassed by calling directly to the gRPC directly and gaining the advantages of the binary compression of protobuf. You also skip the overhead of another layer of the API. You could still use the api to test the gRPC service from swagger, but more just to ensure that endpoints are behaving as intended, or for support of exposing the endpoint to a third party that doesn't support connecting directly to the gRPC endpoint. What do you think?

[Steven-Beasley]

Below is the razor page demo I used to make the call work for my demo.

@page "/"
@using DemoCore.Models
@using DemoCore.Services
@using Grpc.Net.Client

<h1>Hello, world!</h1>

Welcome to your new app.

<button class="btn btn-primary" @onclick="@DownloadAsync">Download Async</button>

<p>Grpc Download Async</p>
<p>Count @GrpcCount</p>
<p>Internal Duration @GrpcInternalDuration ms</p>

@code {
    private int GrpcCount;
    private long GrpcInternalDuration;

    async Task DownloadAsync()
    {
        var channel = GrpcChannel.ForAddress("https://localhost:5001");
        var client = new Download.DownloadClient(channel);
        var reply = await client.DownloadAsyncAsync(new DownloadRequest());

        GrpcCount = reply.Items.Count;
        GrpcInternalDuration = reply.Duration;
    }
}

[dotnetgik]

I guess he has done that for solving the issue which is having with blazor wasm and not the server-side I had done the same implementation with new grpc client but the issue is there with the client-side blazor

[isc30]

I guess WASM cannot call GRPC services directly nowadays. Maybe the API project could be replaced with a generic transparent proxy from HTTP to grpc.