In modern web applications, the common way data is exchanged between client and server is through REST (representational state transfer) services. JSON is the standard file format for this two-way communication.
In REST, the client makes a request to a specific endpoint, and the server responds to it.
This architectural style works fine and has been the standard for several years. All web frameworks for creating SPA (single-page applications) are based on it. At first glance, even Blazor WebAssembly seems to use REST just like other frameworks.
Despite the wide use of this standard, there are some critical issues to consider:
- If it is true that JSON is less verbose than XML, then it is also true that it is not optimized for bandwidth. Sometimes, JSON structure gets much too complicated.
- REST APIs are stateless. This can have some negative consequences; for example, all requests should contain all the necessary information in order to perform the desired operations.
- REST is not a protocol, but an architectural style. This involves increasing the responsibilities of developers. Most implementations of REST use only a subset of its principles but work, more or less. Often there is a confusion between REST services and RESTful services (those that implement REST services).
To be clear, REST architecture remains a great way to exchange data between clients and servers, but perhaps today we can afford to look beyond to find alternative solutions.
What are gRPC and gRPC-Web?
gRPC is a remote procedure call system created at Google in 2015. It is open source and can be defined as a replacement for Windows Communication Foundation (WCF). However, thanks to the latest update, it can also substitute REST API.
gRPC uses Protobuf (Protocol Buffers) as the format for the payload and supports all kinds of streaming:
- Server-side streaming
- Client-side streaming
- Bidirectional streaming
From a performance point of view, Protobuf is an efficient binary message format. Protobuf serialization results in small message payloads, which is important in limited-bandwidth scenarios like mobile and web apps.
gRPC defines the contract of services and messages by the .proto file shared between the server and client. It allows you to automatically generate client libraries. gRPC is consistent across platforms and implementations.
The following table shows a comparison of features between gRPC and REST APIs with JSON format.
FeaturesgRPCREST APIs with JSONContractRequired (.proto)OptionalProtocolHTTP/2HTTPPayloadProtobuf (small, binary)JSON (large, human readable)PrescriptivenessStrict specificationLoose. Any HTTP is valid.StreamingClient, server, bi-directionalClient, serverSecurityTransport (TLS)Transport (TLS)Client code generationYesOpenAPI + third-party tooling
All of this sounds great, doesn’t it? Unfortunately, there’s bad news!
gRPC can’t be used from within web browsers because it requires HTTP/2 binary protocol. Don’t worry, the solution to this problem is called gRPC-Web, which makes gRPC usable in the browser. There’s also an implementation of gRPC-Web for .NET that has been officially released.
To be fair, gRPC-Web provides limited gRPC support. For example, client and bi-directional streaming aren’t supported, and there is limited support for server streaming too.
After this preamble, it’s time to go from theory to practice!
In this post I’ll show you how to consume a gRPC-Web service from within a Blazor WebAssembly app to build weather forecasting application. At the time of writing, there’s no native project template for this yet, so adding gRPC support to a Blazor WebAssembly app is a somewhat significant task. But again, don’t worry. No part of this is complicated. It’s only 10 small steps!
#blazor #development #web #grpc #productivity #wasm #webassembly
