gRPC-Web: Typed Frontend Development

gRPC is a modern, HTTP2-based protocol, that provides RPC semantics using the strongly-typed binary data format of protocol buffers across multiple languages (C++, C#, Golang, Java, Python, NodeJS, ObjectiveC, etc.

gRPC-Web is a cutting-edge spec that enables invoking gRPC services from modern browsers.

Please note - Whilst this package supports Node.js, there is an official Node.js gRPC library that does not require the server to support gRPC-Web

Components of the stack are based on Golang and TypeScript:

grpcweb - a Go package that wraps an existing grpc.Server as a gRPC-Web http.Handler for both HTTP2 and HTTP/1.1
grpcwebproxy - a Go-based stand-alone reverse proxy for classic gRPC servers (e.g. in Java or C++) that exposes their services over gRPC-Web to modern browsers
ts-protoc-gen - a TypeScript plugin for the protocol buffers compiler that provides strongly typed message classes and method definitions
grpc-web-client - a TypeScript gRPC-Web client library for browsers (and Node.js).

Why?

With gRPC-Web, it is extremely easy to build well-defined, easy to reason about APIs between browser frontend code and microservices. Frontend development changes significantly:

no more hunting down API documentation - .proto is the canonical format for API contracts
no more hand-crafted JSON call objects - all requests and responses are strongly typed and code-generated, with hints available in the IDE
no more dealing with methods, headers, body and low level networking - everything is handled by grpc.invoke
no more second-guessing the meaning of error codes - gRPC status codes are a canonical way of representing issues in APIs
no more one-off server-side request handlers to avoid concurrent connections - gRPC-Web is based on HTTP2, with multiplexes multiple streams over the same connection
no more problems streaming data from a server - gRPC-Web supports both 1:1 RPCs and 1:many streaming requests
no more data parse errors when rolling out new binaries - backwards and forwards-compatibility of requests and responses

In short, gRPC-Web moves the interaction between frontend code and microservices from the sphere of hand-crafted HTTP requests to well-defined user-logic methods.

Example

For a self-contained demo of a Golang gRPC service called from a TypeScript projects, see example. It contains most of the initialization code that performs the magic. Here's the application code extracted from the example:

You use .proto files to define your service. In this example, one normal RPC (GetBook) and one server-streaming RPC (QueryBooks):

syntax = "proto3";

message Book {
  int64 isbn = 1;
  string title = 2;
  string author = 3;
}

message GetBookRequest {
  int64 isbn = 1;
}

message QueryBooksRequest {
  string author_prefix = 1;
}

service BookService {
  rpc GetBook(GetBookRequest) returns (Book) {}
  rpc QueryBooks(QueryBooksRequest) returns (stream Book) {}
}

And implement it in Go (or any other gRPC-supported language):

import pb_library "../_proto/examplecom/library"

type bookService struct{
        books []*pb_library.Book
}

func (s *bookService) GetBook(ctx context.Context, bookQuery *pb_library.GetBookRequest) (*pb_library.Book, error) {
	for _, book := range s.books {
		if book.Isbn == bookQuery.Isbn {
			return book, nil
		}
	}
	return nil, grpc.Errorf(codes.NotFound, "Book could not be found")
}

func (s *bookService) QueryBooks(bookQuery *pb_library.QueryBooksRequest, stream pb_library.BookService_QueryBooksServer) error {
	for _, book := range s.books {
		if strings.HasPrefix(s.book.Author, bookQuery.AuthorPrefix) {
			stream.Send(book)
		}
	}
	return nil
}

You will be able to access it in a browser using TypeScript (and equally JavaScript after transpiling):

import {grpc, BrowserHeaders, Code} from "grpc-web-client";

// Import code-generated data structures.
import {BookService} from "../_proto/examplecom/library/book_service_pb_service";
import {QueryBooksRequest, Book, GetBookRequest} from "../_proto/examplecom/library/book_service_pb";

const queryBooksRequest = new QueryBooksRequest();
queryBooksRequest.setAuthorPrefix("Geor");
grpc.invoke(BookService.QueryBooks, {
  request: queryBooksRequest,
  host: "https://example.com",
  onMessage: (message: Book) => {
    console.log("got book: ", message.toObject());
  },
  onEnd: (code: Code, msg: string | undefined, trailers: BrowserHeaders) => {
    if (code == Code.OK) {
      console.log("all ok")
    } else {
      console.log("hit an error", code, msg, trailers);
    }
  }
});

Browser Support

The grpc-web-client uses multiple techniques to efficiently invoke gRPC services. Most modern browsers support the Fetch API, which allows for efficient reading of partial, binary responses. For older browsers, it automatically falls back to XMLHttpRequest.

The gRPC semantics encourage you to make multiple requests at once. With most modern browsers supporting HTTP2, these can be executed over a single TLS connection. For older browsers, gRPC-Web falls back to HTTP/1.1 chunk responses.

This library is tested against:

Chrome >= 41
Firefox >= 38
Edge >= 13
IE >= 11
Safari >= 8

Node.js Support

grpc-web-client also supports Node.js through a transport that uses the http and https packages. Usage does not vary from browser usage as transport is determined at runtime.

Please note - There is an official Node.js gRPC library that does not require the server to support gRPC-Web

Client-side streaming

It is very important to note that the gRPC-Web spec currently does not support client-side streaming. This is unlikely to change until new whatwg fetch/streams API lands in browsers. As such, if you plan on using gRPC-Web you're limited to:

unary RPCs (1 request 1 response)
server-side streaming RPCs (1 request N responses)

This, however, is useful for a lot of frontend functionality.

Status

The code here is alpha quality. It is being used for a subset of Improbable's frontend single-page apps in production.

Known Limitations

Server-side streaming with XHR

Browsers that don't support Fetch with body.getReader (Currently only Edge 14+ and Chrome 43+ - full ReadableStream was added in Chrome 52, but only body.getReader() is used) or XMLHttpRequest.responseType = moz-chunked-arraybuffer (Firefox 38+) use XmlHttpRequest (XHR). XHR keeps the entire server response in memory. This means that a long-lived or otherwise large streaming response will consume a large amount of memory in the browser and may cause instability. Fetch does not suffer from this issue. It is therefore advised that you don't use open-ended or large payload server streaming if you intend to support browsers that do not support Fetch.

Running the tests

See test README

telekid/grpc-web