This is my second of two posts about the Linux Foundation’s recent gRPC Conference. Check out my first post for some reflections on the conference as a whole and a few observations about where gRPC is going four years after it was open sourced by Google. This time around, I’ll share some key points from my own talk, which was about how web applications can benefit from gRPC by leveraging a gRPC sub-project called gRPC-Web along with Istio service mesh.
gRPC-Web addresses a shortcoming in the core Google gRPC framework: the fact that it doesn’t work so well with web applications running on browsers. That’s because even though most browsers support HTTP/2 and gRPC is based on HTTP/2, gRPC has its own protocols that web applications must understand in order to work properly with it. But web applications do not have this capability because browsers don’t support gRPC out of the box. Developers are increasingly looking to benefit from the advantages the core gRPC server and framework confers beyond backend microservices, thus gRPC-Web was born.
One way to get around the above problem is to use the gRPC-Web plugin and run an Envoy proxy along with it. An Envoy configuration can serve as the default proxy for Istio, and by configuring its gRPC-Web filter, we can create seamless, well-connected, cloud native web applications. Traditionally, services have exposed their functionality over REST APIs. This gives you service isolation, scalability, load balancing, velocity and independence. But the REST API itself is not type safe; it doesn’t give you forward and backward compatibility and performance can be constrained.
A Protobuf message lets us define the same API in a standard way with an interface definition language (IDL), which resolves the issues that REST APIs aren’t addressing. Replace the REST API in services with gRPC Web client and the backend works pretty much the same as before. That doesn’t totally solve the problem though (i.e. the web UI still cannot talk to backend services because browsers don’t directly support gRPC). You get around that by using the gRPC-Web library and an edge proxy. With those in place, web applications can now talk to a gRPC backend directly.
Another alternative is to use an HTTP server pattern, where you implement some kind of an intermediate middleware that takes simple HTTP requests from the browser and converts them to gRPC. But that configuration won’t scale because you need to keep updating the API, and it’s not maintainable when you have a lot of microservices and need to create these kinds of APIs for a large microservice architecture. Instead, use a proxy-based approach built around a service mesh framework and it will transcode your HTTP requests into gRPC requests so you can get rid of the HTTP server.
In my talk, I showed a demo of a web app that uses gRPC-Web on the front end and a simple Go backend exposing a gRPC API. I didn’t configure a proxy directly but instead deployed the gRPC application on Istio, which configured the proxy and the gRPC-Web filter automatically. Crucially, the front and backend are now talking seamlessly, and you also gain a whole set of features from Istio as well.
One of the most important of these is observability. You can now observe your microservices on the Grafana dashboard that shows key metrics like client and server request volumes, success rates, request durations and response rates. Then, because you are working with Istio, you can also trace all HTTP and gRPC requests in a much more standard manner using Jaeger. Apart from these, Kiali lets you visualize your deployment as a service graph which it generates by observing the traffic flow in real-time.
The bottom line here is that by switching over to a gRPC-Web and Istio paradigm, developing a cloud native gRPC application becomes a relatively seamless experience.
People seemed interested in the approach I was outlining and were curious to know how it might work in production. The demo is the result of very recent research, so it’s all I had at the moment – but if you would like to give it a go in configuration and production, let us know how it works! You can find the demo on GitHub and you can read more about how it all works in a post on my personal blog. Feel free to check out the code and deploy the demo on Istio to see how it performs.