gRPC Features / Questions

Hi Guys, Is there a way to see which gRPC endpoints are active from the dashboard /metadata page. If not , something like this will be very useful.

Currently I use the JsonHttpClient in my cross platform solution with the HttpMessageHandler property where I use the NativeMessageHandler so that I can for instance use the native OKHttp3 on Xamarin Forms Android. Is there an option to use something like this in gRPC ? If not how does this work on XF android for instance.

Lastly, gRPC Server Send Events does not have a fallback as is the case with gRPC and REST. Any plans in future to give us an equivalent fallback on basic functionality like channels / triggers ? So for clarity where you can define one endpoint for SSE that will include both gRPC and REST. Obviously only where the functionality overlap.

thanks in advance.

gRPC is not a normal ServiceStack HTTP endpoint, all requests instead goes through ASP.NET Core gRPC Endpoint > protobuf-net.gRPC support.

You can use the protoc support in ServiceStack’s dotnet tools, to discover which services are available, e.g:

$ x proto-csharp <base-url>

Which will download both the gRPC .proto API description and the generated C# classes.

You can also view the proto file directly from /types/proto, e.g:

https://todoworld.servicestack.net/types/proto

There are 2 ways to consume in C# through C# generic GrpcServiceClient where you can use your normal Add ServiceStack Reference C# POCO DTOs.

The other way is using Google’s protoc generated clients. Both of these work well in .NET Core but I’m not sure how well supported they are in Xamarin clients as it’s not anything we have any control over, ultimately it’s down to the underlying Grpc.Core, Grpc.Net.Client & protobuf-net.Grpc gRPC package implementations and how well Xamarin supports them.

thanks @mythz. When you generate the protoc files , is there no way to then “flag” the rest endpoint so that it can be displayed in the metadata page. visually it will be much easier to check ;))

If I follow you correctly then there should be no reason to use any HttpMessageHandler to increase performance as it’s already using custom clients (Grpc.Core, Grpc.Net.Client & protobuf-net.Grpc) that should work great especially when .net 5 arrives and use the same BCL as .net core 3.0

No there shouldn’t be any need to interfere with the gRPC communication implementation as they’re developed to use an efficient HTTP/2 persistent channel.

The issue with the metadata page is that all gRPC Server implementation is in a .NET Core 3. ServiceStack.Extensions project what ServiceStack’s metadata pages don’t have a reference to, there’s also no additional information we could show about a gRPC service only that it’s available via gRPC.

Thanks @mythz. much appreciated. was hoping for an easy check especially in an environment with lots of endpoints.

Servicestack gRPC has is minimum .net standard 2.1. Is this because of Grpc.Net.Client that takes a minimum .net standard 2.1 dependency or are you also using .net standard 2.1 features ?

UWP is really a pain only supporting .net standard 2 especially in my current cross platform solution.

It’s due to Grpc.Net.Client only supporting .NET Standard 2.1.

FYI I’ve just added a link to the /types/proto in the metadata page which defines all gRPC Service APIs which follow the naming convention in the docs.

This change is available from the latest v5.8.1 that’s now available on MyGet.

1 Like