13 : Google Rocket Powered Computing - gRPC for short

Random fact

Google was originally named BackRub.

Sergey Brin and Larry (Lawrence) Page met by chance.

In 1995 Larry Page, then 22 earned a computer engineering degree from the University of Michigan, he wanted to attend Stanford University to do a Ph.D.

Sergey Brin, then 21, was already a Ph.D. student at Stanford, was assigned to show Page around campus.

As fate would have it, quite the momentous meeting of the minds.

Backrub

In 1996, Larry Page and Sergey Brin collaborated on a pioneering “web crawler” concept curiously called BackRub.

Some speculate the name was a nod to retrieving backlinks.

BackRub lived on Stanford’s servers for more than a year, but eventually chewed up too much bandwidth.

Google name

In 1997, their project was mushrooming and they had enough of the BackRub name.

Page and Brin registered the domain name Google which is a twist on “googol,” a mathematical term represented by the numeral one followed by 100 zeros.

The name hinted at the seemingly infinite amount of data the webcrawler processes.

Many wondered if Google is a misspelling of the word Googol.

Introduction

What is RPC?

A: Basically calling a procedure on a remote machine - normally using a proxy so it appears as a normal procedure call.

Been around since late 70s early 80s - Bruce Jay Nelson is generally credited with coining the term "remote procedure call" in 1981.

From Wikipedia - In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space (commonly on another computer on a shared network), which is coded as if it were a normal (local) procedure call, without the programmer explicitly coding the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. This is a form of client–server interaction (caller is client, executor is server), typically implemented via a request–response message-passing system. In the object-oriented programming paradigm, RPCs are represented by remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures are largely the same whether they are local or remote, but usually they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders of magnitude slower and less reliable than local calls, so distinguishing them is important.

Why did it fall out of favour?

In the 1990s, with the popularity of object-oriented programming, an alternative model of remote method invocation (RMI) was widely implemented, such as in Common Object Request Broker Architecture (CORBA, 1991) and Java remote method invocation. RMIs in turn fell in popularity with the rise of the internet, particularly in the 2000s.

• too much coupling?
• tech lockin?
• http was universally supported
• scalability
• extensibility / maintainability
• operational management - logging / tracing

RPC the history

History of distributed APIs

1970-80s RPC, Messaging, Queuing,

1990-2000s OLE/COM/DCOM/ActiveX/MTS, CORBA, Java RMI,

• Net remoting? Object remoting relied on a lot of chatter under the hood to maintain state, connection latency killed this

2000-2010s XMLHTTP, REST, SOAP,

—> WCF happened <— back to the dark ages - PAIN!

2010-Now GraphQL, gRPC (first general purpose RPC infrastructure internally in Google and then open sourced in 2015), Protobuf message exchange format (2001 internally, 2008 first public release)

So why gRPC then?

gRPC is a modern open source high performance Remote Procedure Call (RPC) framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.

The story behind gRPC

gRPC was initially created by Google, which has used a single general-purpose RPC infrastructure called Stubby to connect the large number of microservices running within and across its data centers for over a decade. In March 2015, Google decided to build the next version of Stubby and make it open source.

By default, gRPC uses Protocol Buffers, Google’s mature open source mechanism for serializing structured data (although it can be used with other data formats such as JSON). Here’s a quick intro to how it works. If you’re already familiar with protocol buffers, feel free to skip ahead to the next section.

Protocol buffers (ProtoBuf)

• Developed by Google to be initially faster than XML
• Binary encoding - different to XML / JSON which is text based and human readable
• highly performant messaging format
• interface definition language
  • simple to define message and service format
• Language independent
  • C++, Java, Obj-C, Python, Ruby, Go, NodeJS, C#
• Great performance due to binary message format results in:
  • Faster encoding and decoding
  • Smaller payloads

Who’s using it?

A number of different organizations have adopted gRPC, such as Uber,[8] Square, Netflix, IBM, CoreOS, Docker, CockroachDB, Cisco, Juniper Networks,[9] Spotify,[10] Zalando[11] and Dropbox.[12]

**Using gRPC in .net core

What can you build with it? Services, console apps, web apps, APIs?

• no web clients, we’ll talk about that...

• backends / windows services / console apps

• Can use it if doing self hosted, or as windows service (.Net 6) or Linux service (.Net 6)

• Using it in aspnet core - browser clients wont be able to connect to straight gRPC services (due to HTTP/2 support, more on this below), but other servers / non browser clients could connect

• Can recently host full gRPC in IIS - IIS requires .NET 5 and Windows 10 Build 20300.1000 or later.

• gRpc Clients - .Net Core 3 and above - gRPC and gRPC.Web

  • .Net Framework 4.6.1 will do gRPC-Web

• James Newton-King is the guy - of JSON.Net fame - Principal Software Engineer

Visual Studio Tooling and getting started:

• support for .proto files

  • Codegen from .proto to c# types, service base classes and client

• Create subclass of generated service base classes

• Make service available in net core in Program.cs using:

  app.MapGrpcService<GreeterService>()
  

• Call into the service with the generated client:

  var channel = GrpcChannel.ForAddress("https://localhost:5001");
  var client = new Greeter.GreeterClient(channel);
  
  var response = await client.SayHelloAsync(
      new HelloRequest { Name = "World" });
  

• Or use a ClientFactory if needed!

• Support existing aspnet core authentication mechanisms like

  • azure Active Dir
  • client certs
  • JWTs
  • OAuth2 OpenId Connect

• Works same way as http Development story

  • Authorize attributes

[Authorize]
public class TicketerService : Ticketer.TicketerBase
{
    public override Task<AvailableTicketsResponse> GetAvailableTickets(
        Empty request, ServerCallContext context)
    {
        // ... buy tickets for the current user ...
    }

    [Authorize("Administrators")]
    public override Task<BuyTicketsResponse> RefundTickets(
        BuyTicketsRequest request, ServerCallContext context)
    {
        // ... refund tickets (something only Administrators can do) ..
    }
}

gRPC and streaming / bi-directional streaming

Pure gRpc supports bi-directional streaming ie from both server to client and client to server, but only if both parties support the full gRpc protocol

• Can return a full dataset / array / list - use repeated keyword in .proto file
• or
• For long running persistent connections, data can be streamed back and rows / array items / list items can be processed individually as multiple messages by the client - use stream keyword in .proto file

gRPC and gRPC-Web

It is currently impossible to implement the HTTP/2 gRPC spec in the browser

• no browser API with enough fine-grained control over the requests
• eg) there is no way to force the use of HTTP/2, and even if there was, raw HTTP/2 frames are inaccessible in browsers

In the summer of 2016, both a team at Google and  Improbable independently started working on implementing something that could be called “gRPC for the browser”

They became aware of each other and hooked up to define gRpc-Web protocol to make grpc work in browsers

gRPC-web is not compatible with client-side and bi-directional streaming but only with unary and server-side streaming - ie server side streaming does work

Aspnet core and gRPC-Web

• aspnet core has support for gRRP-Web services

  • Use middleware provided by the Grpc.AspNetCore.Web package - Support gRPC-Web alongside gRPC HTTP/2 in ASP.NET Core

• Easily configured in Startup.cs - setup gRPC-Web for individual services or for all:

  public void Configure(IApplicationBuilder app)
  {
      app.UseRouting();
  		app.UseGrpcWeb(); // Must be added between UseRouting and UseEndpoints
  		app.UseEndpoints(endpoints =>
      {
  			endpoints.MapGrpcService<GreeterService>().EnableGrpcWeb();
  		});
  }
  

• Built in CORS support - easily configured in Startup.cs as well

  • Cross-origin resource sharing (CORS)

Opportunities that gRPC-Web provides:

(https://devblogs.microsoft.com/dotnet/grpc-web-for-net-now-available/)

• Call ASP.NET Core gRPC apps from the browser – Browser APIs can’t call gRPC HTTP/2. gRPC-Web offers a compatible alternative.
  • JavaScript SPAs
  • .NET Blazor Web Assembly apps
• Host ASP.NET Core gRPC apps in IIS and Azure App Service.
• Call gRPC from non-.NET Core platforms

Quickstart

https://grpc.io/docs/languages/csharp/quickstart/

OS project/utility of the week

Both discussed gRPC and thought of dapr as it uses gRPC behind the scenes - We talk about this in Episode 10 - Dapr not to be confused with Dapper

Dapr is

• portable,
• event-driven runtime

Easy for any developer to build

• resilient, stateless and stateful applications
• run on the cloud and edge
• Language and framework independent
• state management
• pub / sub
• secret management
• service discovery
• call tracing
• actors model
• binding - bind to http handler endpoint