Blazor WebAssembly: Debugging gRPC-Web with Custom Chrome Developer Tools

If you are working with Blazor, gRPC is a big issue for transferring data from APIs to clients. One issue of developing with gRPC-Web is debugging the transmitted data because the data is in an efficient binary message format. In this article, I will show you how to solve this problem with the help of my NuGet.

In diesem Artikel:

Blazor WebAssembly: Debugging gRPC-Web with Custom Chrome Developer Tools
Patrick Jahr ist Architekt bei Thinktecture. Sein Fokus liegt auf Backend-Systemen mit .NET Core und der Frontend-Entwicklung mit Angular.


Since I’ve worked with Blazor WebAssemby, gRPC has also been a big topic in getting data from my APIs to my clients. But gRPC is currently not supported by browsers because it is impossible to implement the HTTP/2 gRPC spec in the browser(more here). Therefore, applications running in the browser need an alternative to use gRPC. The choice was gRPC-Web, a stripped-down version of gRPC. With gRPC-Web, sending data from the API to my client and back is possible. If you want to know more about gRPC and how gRPC-Web works in Blazor WebAssembly, check out the talk by my colleague Christian Weyer about „Blazor & gRPC – Code-first .NET SPA developer productivity.“

That means we can use gRPC-Web in the browser and everything is cool? No, unfortunately not.

One problem of developing with gRPC-Web is the debugging of the transferred data. Looking at the following image, we can see the Network tab of Chrome Browser Dev Tools.


Here we see a gRPC-Web response that sent back a list of conferences to the client. But unfortunately, this is not readable because the messages are serialized with Protobuf, an efficient binary message format. But what can I do here to make the whole thing more readable?

For some time now, there has been a Chrome browser extension for the gRPC-Web Developer Tools. This extension makes it possible to show the request and response data in a pretty JSON format, as you see in the following picture in this article.
The only problem is that there is no way to use this extension in Blazor WebAssembly yet.

To solve this little problem, I have made it my task to make this handy tool also usable for Blazor WebAssembly 🙂

In this article, I will show you how to turn on the Developer Tools for gRPC-Web in your Blazor WebAssembly application using my Nuget package Thinktecture.Blazor.GrpcWeb.DevTools.

The GitHub repository for this article and also for the NuGet package can be found here.

What are the gRPC-Web Developer Tools, and what can they do?

The two main tasks of gRPC-Web Developer Tools are:

  • Collect and display all gRPC-Web network requests and responses in a list. 
  • Chrome Developer Tools extension for the official gRPC-Web library. It allows you to inspect the gRPC-Web network protocol in Chrome Developer Tools. The transferred data is displayed as a deserialized JSON object rather than in the original ProtoBuf format.

With the Developer Tools, you will get a new tab called gRPC-Web in your Chrome Developer Tools. This tool will list the configured gRPC-Web client network requests. The features are similar to the standard Network tab but only for gRPC-Web requests.

Selecting a network log entry displays the deserialized JSON for the request, response, and any error objects returned by your gRPC-Web server (See the following figure).

gRPC-Web Devloper Tools

Enable gRPC-Web Developer Tools for Blazor WebAssembly

To use the gRPC-Web Developer Tools in your project, you only have to add a few instructions to the Program.cs.
First, register the GrpcChannel class in the dependency injection. This is likely already present in your Blazor WebAssembly client code when you are using the gRPC-Web client.


private GridItemsProvider<Contribution>? _contributionsProvider;
private PaginationState pagination = new PaginationState { ItemsPerPage = 100 };

protected override async Task OnInitializedAsync()
    _contributionsProvider = async req =>
        var count = await _contributionService.GetContributionCountAsync(req.CancellationToken);
        var response = await _contributionService.GetContributionsAsync(req.StartIndex, req.Count ?? 100, req.CancellationToken);
        return GridItemsProviderResult.From(
            items: response ?? new(),
            totalItemCount: count);
    pagination.TotalItemCountChanged += (sender, eventArgs) => StateHasChanged();

    await base.OnInitializedAsync();

private async Task GoToPageAsync(int pageIndex) =>
    await pagination.SetCurrentPageIndexAsync(pageIndex);

private string? PageButtonClass(int pageIndex)
    => pagination.CurrentPageIndex == pageIndex ? "current" : null;

private string? AriaCurrentValue(int pageIndex)
    => pagination.CurrentPageIndex == pageIndex ? "page" : null;

In the next step, the gRPC-Web service interfaces can be registered by using the AddGrpcService extension method from the blazor-grpc-web-devtooling Project.

With this extension method, the service is registered in the ServiceCollection with the help of the GrpcChannel and can then be added via DI to the component or a service (more will be explained in the next chapter).


Note: Of course, the services can also be registered and used without the Developer Tools.

To activate the developer tools, you have two options:
On the one hand, we can call the extension method EnableGrpcWebDevTools() in the Program.cs.

The second possibility is via appsetting.json. We can add the entry GrpcDevToolsEnabled to enable or disable the developer tools (see more information on this setting in the following section).
  "GrpcDevToolsEnabled": true

Both options register an CallInvoker instance, which registers an additional interceptor.
This interceptor extends the base class Interceptor. The interceptor calls the JavaScript method postMessage with the help of JSInterop for each unary and server_streaming call (see more information on this interceptor in the following section).

The interceptor sends the request/response data via window.postMessage to the developer tools. The tools can receive and display the request or response, as seen in the following video snippet.

How it works under the hood

The project consists of three essential parts that work together to send the gRPC-Web requests and responses to the gRPC-Web Developer Tools.

The first part is an interceptor, which extends the base class Interceptor to get the possibility to override the gRPC-Web call methods and add its implementation or extend the existing implementation. The gRPC-Web Developer Tools currently support the two requests, Unary and ServerStreaming, which is overridden in the interceptor class GrpcMessageInterceptor. If one of the two methods is called, the base method is executed, and the request or response is also sent to the gRPC-Web Developer Tools with JSInterop.

					public partial class GrpcMessageInterceptor : Interceptor
    // ...

    public override AsyncUnaryCall<TResponse> AsyncUnaryCall<TRequest, TResponse>(
        TRequest request,
        ClientInterceptorContext<TRequest, TResponse> context,
        AsyncUnaryCallContinuation<TRequest, TResponse> continuation)
        var call = continuation(request, context);

        return new AsyncUnaryCall<TResponse>(
            HandleUnaryCall(context.Method.Name, request, call.ResponseAsync),

    public override AsyncServerStreamingCall<TResponse> 
        AsyncServerStreamingCall<TRequest, TResponse>(
            TRequest request, 
            ClientInterceptorContext<TRequest, TResponse> context, 
            AsyncServerStreamingCallContinuation<TRequest, TResponse> continuation)
        var streamingCall = base.AsyncServerStreamingCall(request, 
            context, continuation);

        var response = new AsyncServerStreamingCall<TResponse>(
                new AsyncStreamReaderWrapper<TResponse>(

        return response;
   // ....
And here we come to the second important point. With JSInterop, the postMessage-method is called, which sends the data to the gRPC-Web Developer Tools. Since this is a window method, no additional JavaScript file is needed here. The method can be called directly from the JSRuntime, as shown in the following code sample.
					internal static async Task HandleGrpcRequest<TRequest, TResponse>(
    this IJSRuntime jsRuntime, 
    string method,
    TRequest request, 
    TResponse response)
            await jsRuntime.InvokeVoidAsync(
                new GrpcDevToolsCall<TRequest, TResponse>(

The JavaScript-Method window.postMessage() in the code above is called with the JSRuntime. This call will pass the data to the gRPC-Web Developer Tools. To let the Chrome Developer Tools know which tool to send the data to, the identifier for the gRPC-Web Developer Tools is also sent. The parameters method, GrpcUnaryMethodName, request, and response used by the gRPC-Web Developer Tools to display the requests and responses shown in the video of the previous chapter.

The last part is registering the Interceptor so that all calls will be sent to the gRPC-Web Developer Tools. To do this, I have written an extension method, which you can use to register the gRPC-Web services interfaces.

					public static void AddGrpcService<TService>(this IServiceCollection services)
            where TService : class
            services.AddScoped(serviceProvider =>
                var invoker = serviceProvider.GetService<CallInvoker>();
                if (invoker != null)
                    return GrpcClientFactory.CreateGrpcService<TService>(invoker);

                    var enabled = serviceProvider
                    if (enabled.HasValue && enabled.Value)
                        if (invoker == null)
                            var jsRuntime = serviceProvider.GetService<IJSRuntime>();
                            invoker = serviceProvider
                                    .Intercept(new GrpcMessageInterceptor(jsRuntime));
                        return GrpcClientFactory.CreateGrpcService<TService>(invoker);
                catch (Exception e)
                    var channel = serviceProvider.GetService<GrpcChannel>();
                    return GrpcClientFactory.CreateGrpcService<TService>(channel);

In the code above, we see two options to enable the Developer Tools extension. On the one side, we look at the configuration, which we explained in the first part of this article. On the other side, the extension method EnableGrpcWebDevTools checks if the interceptor is already set.

And that’s it. With these three steps, we can use the gRPC-Web Developer Tools in our Blazor WebAssembly project.


With the help of a few lines of code, we have a much easier time finding errors, debugging network requests
or to better track the progress of requests in a gRPC-Web-enabled end-to-end application.
Feel free to use it. I am open to ideas and improvements and also pull requests 🙂


Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Diese Artikel könnten Sie interessieren
Incremental Roslyn Source Generators: High-Level API – ForAttributeWithMetadataName – Part 8

Incremental Roslyn Source Generators: High-Level API – ForAttributeWithMetadataName – Part 8

With the version 4.3.1 of Microsoft.CodeAnalysis.* Roslyn provides a new high-level API - the method "ForAttributeWithMetadataName". Although it is just 1 method, still, it addresses one of the biggest performance issue with Source Generators.
Integrating AI Power into Your .NET Applications with the Semantic Kernel Toolkit – an Early View

Integrating AI Power into Your .NET Applications with the Semantic Kernel Toolkit – an Early View

With the rise of powerful AI models and services, questions come up on how to integrate those into our applications and make reasonable use of them. While other languages like Python already have popular and feature-rich libraries like LangChain, we are missing these in .NET and C#. But there is a new kid on the block that might change this situation. Welcome Semantic Kernel by Microsoft!
.NET 7 Performance: Regular Expressions – Part 2

.NET 7 Performance: Regular Expressions – Part 2

There is this popular quote by Jamie Zawinski: Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems."

In this second article of our short performance series, we want to look at the latter one of those problems.
Architektur-Modernisierung: Migration von WCF zu gRPC mit ASP.NET Core – ein pragmatischer Ansatz

Architektur-Modernisierung: Migration von WCF zu gRPC mit ASP.NET Core – ein pragmatischer Ansatz

Viele Projekte mit verteilten Anwendungen in der .NET-Welt basieren noch auf der Windows Communication Foundation (WCF). Doch wie kommt man weg von der "Altlast" und wie stellt man seinen Code auf sowohl moderne als auch zukunftssichere Beine? Eine mögliche Lösung ist gRPC.

gRPC Code-First mit ASP.NET Core 7 und Blazor WebAssembly

gRPC Code-First mit ASP.NET Core 7 und Blazor WebAssembly

Wie in allen anderen browserbasierten Single-Page-Application (SPA) Frameworks, ist Blazor WebAssembly JSON-over-HTTP (über Web- oder REST-APIs) die bei weitem häufigste Methode, um Daten auszutauschen und serverseitige Vorgänge auszulösen. Der Client sendet eine HTTP-Anfrage mit JSON-Daten an eine URL, mitunter über unterschiedliche HTTP-Verben. Anschließend führt der Server eine Operation aus und antwortet mit einem HTTP-Statuscode und den resultierenden JSON-Daten. Warum sollte man das ändern? Nun, es gibt Gründe - vor allem wenn man in einem geschlossenen System ist und .NET sowohl im Frontend als auch im Backend einsetzt.
Blazor WebAssembly in .NET 7: UI-Performance-Optimierung auf Komponentenebene

Blazor WebAssembly in .NET 7: UI-Performance-Optimierung auf Komponentenebene

Stockende UI, keine Reaktion nach dem Klick auf einen Button oder einer Eingabe in einem Feld - dies sind nur wenige Beispiele alltäglicher Probleme, die der Nutzung von Client-Anwendungen im Allgemeinen, und bei Webanwendungen im Speziellen, immer wieder auftreten können. In diesem Artikel schauen wir uns an, wie wir komponentenbasierte UIs in Blazor WebAssembly optimieren können, um dadurch eine für die Benutzer zufriedenstellende Geschwindigkeit und ein flüssiges UI zu bekommen.