Today, the Cloud Native Computing Foundation (CNCF) officially released the GA version of GRPC-Web, a JavaScript client library that enables Web applications to communicate directly with back-end gRPC services, without the need for HTTP servers to act as intermediaries.

This means that you can now easily build true end-to-end gRPC application architectures by defining client and server data types and service interfaces through.proto files. Grpc-web provides an alternative to REST for Web development.

Grpc-web lets you use.proto to define the service “contract” between the client Web application and the back-end gRPC server, and automatically generate client-side JavaScript (you can choose the Closure compiler or use the more general CommonJS).

You don’t have to worry about creating custom JSON serialization and deserialization logic, handling HTTP status code (which may vary depending on the REST API), content-Type negotiation, and so on.

From a broader architectural perspective, GRPC-Web makes end-to-end gRPC possible. As shown below:

On the left, a client application communicates with a gRPC backend server through Protocol Buffers, which in turn communicates with other gRPC backend servers through Protocol Buffers. On the right, the Web application communicates with a back-end REST API server over HTTP, which in turn communicates with other back-end services through Protocol Buffers.

To be clear, there is nothing wrong with the REST application on the right. A number of highly successful applications have been built on REST API servers that use non-HTTP protocols to communicate with back-end services. But if these applications are developed around a single protocol and a set of. Proto interfaces (and a set of service contracts), countless hours of time and headaches can be saved.

The benefits of GRPC-Web are not just in terms of “technology”, but also in terms of impact on the organization. The bright orange line isn’t just a protocol — it represents an independent source of work and cognitive load, and now you can turn it bright green.

Grpc-web will offer a broader feature set over time. For now, what I can see is:

  • End-to-end gRPC- As mentioned above, with GRPC-Web, you can formally remove REST components from the technology stack and replace them with gRPC, allowing you to use Protocol Buffers to create the entire RPC pipeline. Imagine a scenario where a client request is forwarded to an HTTP server, which interacts with the five gRPC services at the back end. You will most likely spend a lot of time building the HTTP interaction layer because you will need to build the rest of the pipeline.

  • Closer collaboration between front – and back-end teams – by referring back to the chart above, you no longer need to bundle the “microservices team” with the “client team” after using Protocol Buffers to define the entire RPC pipeline. The interaction between the client and the back end is just one more LAYER of gRPC.

  • Easy generation of client libraries – With GRPC-Web, the server that interacts with the “outside” world becomes a gRPC server instead of an HTTP server, which means that all client libraries can be gRPC libraries. Need client libraries for Ruby, Python, Java, and 4 other languages? You no longer need to write HTTP clients for all these languages.

Some of the advantages of GRPC-Web in large-scale applications have been described above. Now let’s go through an example: a simple TODO application. In grpc-Web, you can start with a simple todos.proto definition, as follows:

Syntax = "proto3"; package todos; message Todo { string content = 1; bool finished = 2; } message GetTodoRequest { int32 id = 1; } service TodoService { rpc GetTodoById (GetTodoRequest) returns (Todo); }Copy the code

You can use this. Proto definition and protoc command line tool to generate CommonJS client code:

protoc echo.proto \
  --js_out=import_style=commonjs:./output \
  --grpc-web_out=import_style=commonjs:./outputCopy the code

Then get the TODO list from the back-end gRPC server:

Const {GetTodoRequest} = the require (". / todos_pb. Js'); Const {TodoServiceClient} = the require (". / todos_grpc_web_pb. Js'); Const todoService = new proto. Todos. TodoServiceClient (" http://localhost:8080 "); const todoId = 1234; var getTodoRequest = new proto.todos.GetTodoRequest(); getTodoRequest.setId(todoId); var metadata = {}; var getTodo = todoService.getTodoById(getTodoRequest, metadata, (err, response) => { if (err) { console.log(err); } else { const todo = response.todo(); If (todo == null) {console.log(' A todo with the ID ${todoId} wasn't found '); } else { console.log(`Fetched TODO with ID ${todoId}: ${todo.content()}`); }}});Copy the code

There is no HTTP code or methods, no JSON parsing, no header negotiation. You declare the data types and service interfaces, and GRPC-Web strips away all the boilerplate code, leaving you with a clean and user-friendly SET of apis.

On the back end, gRPC servers can be written in any language that supports gRPC, including Go, Java, C++, Ruby, node.js, and more (see the development language-related documentation in the official gRPC documentation https://grpc.io/docs/).

The final key component is the service broker. From the outset, GRPC-Web supports Envoy as the default service proxy, which provides a built-in enlist.grpc_web filter with just a few lines of configuration. More information will be Envoy blog (https://blog.envoyproxy.io/) in detail.

The release of the GA version means that the core building blocks are ready for use in a production environment. But grPC-Web will bring a lot more.

You can view the official development roadmap (https://github.com/grpc/grpc-web/blob/master/ROADMAP.md), in order to understand the core team envisioned the future.

If you are interested in contributing to GRPC-Web, the core team would like the community to help with the following:

  • Front-end Framework Integration – Common front-end frameworks such as React, Angular, and Vue do not officially support GRPC-Web. We’d like to see it supported by these frameworks, as each will benefit greatly from gRPC.

  • Language-specific proxy support – As of the GA version, Envoy is the default proxy for GRPC-Web and is supported through a special module. We would also love to see in-process agents developed in other specific languages. In-process proxies remove dependencies on special proxies – such as Envoy and Nginx – and can make grPC-Web easier to use.

https://www.cncf.io/blog/2018/10/24/grpc-web-is-going-ga/