blog post about grpc stacks #781

carl-mastrangelo · 2018-11-30T01:24:35Z

carl-mastrangelo · 2018-11-30T01:25:40Z

This is not meant to be very long, just pretty. I've had these in my TODO tab list for some time, and I wan to get them out.

srini100 · 2018-11-30T02:31:39Z

_posts/2018-11-30-grpc-stacks.md

+<!--more-->
+
+
+There are three main stacks in gRPC: C-core, Go, and Java.  Most of the languages are thin wrappers on top of the [C-based](https://github.com/grpc/grpc/tree/v1.16.1/src/core) gRPC core library:


Link to master branch as 1.16.1 will be old soon.

I had picked a tag because links tend to break over time (re-orging code). Done, though.

srini100 · 2018-11-30T02:33:22Z

_posts/2018-11-30-grpc-stacks.md

+
+<p><img src="https://grpc.io/img/grpc-core-stack.svg" alt="gRPC Core Stack" style="max-width: 800px" /></p>
+
+For example, a Python application calls into the generated Python stubs.  These call pass through interceptors, and into the wrapping library where the call is translated into C calls.  The gRPC C-core will encode the RPC as HTTP/2, optionally encrypt the data with TLS, and then pass write it to the network.


These calls ...
...where the calls are ...

then ~~pass~~ write

srini100 · 2018-11-30T02:40:07Z

_posts/2018-11-30-grpc-stacks.md

+
+<p><img src="https://grpc.io/img/grpc-java-stack.svg" alt="gRPC Java Stack" style="max-width: 800px" /></p>
+
+Again, the structure is a little different.  Java supports HTTP/2, QUIC, and In Process like the C-core.  Unlike the C-Core though, applications commonly can bypass the generated stubs and interceptors, and speak directly to the Java Core library.  Each structure is slightly different based on the needs of each language implementation of gRPC.


Is QUIC supported directly or is it via Cronet? If Cronet then the diagram needs to change a include TCP under Cronet.

From talking to @ncteisen I thought there was built in support not from Cronet.

@vjpai as far as I am aware we do not have a non cronet QUIC transport.. IIUC We do not have server side support of quic either, but rely on a translating proxy in between...

carl-mastrangelo · 2018-11-30T23:08:16Z

@srini100 PTAL

srini100

Noted one small nit. Diagrams look good.
LGTM.

srini100 · 2018-11-30T23:23:40Z

_posts/2018-11-30-grpc-stacks.md

+
+<p><img src="https://grpc.io/img/grpc-core-stack.svg" alt="gRPC Core Stack" style="max-width: 800px" /></p>
+
+For example, a Python application calls into the generated Python stubs.  These calls pass through interceptors, and into the wrapping library where the call is translated into C calls.  The gRPC C-core will encode the RPC as HTTP/2, optionally encrypt the data with TLS, and then write it to the network.


..where the calls are translated...

carl-mastrangelo

I also added blurbs about the HTTP/2 components based on our discussion.

carl-mastrangelo · 2018-12-01T00:05:06Z

_posts/2018-11-30-grpc-stacks.md

+
+<p><img src="https://grpc.io/img/grpc-core-stack.svg" alt="gRPC Core Stack" style="max-width: 800px" /></p>
+
+For example, a Python application calls into the generated Python stubs.  These calls pass through interceptors, and into the wrapping library where the call is translated into C calls.  The gRPC C-core will encode the RPC as HTTP/2, optionally encrypt the data with TLS, and then write it to the network.


hsaliak

Some minor nits, but I do not want to block the approval on them..

hsaliak · 2018-12-05T23:16:17Z

_posts/2018-11-30-grpc-stacks.md

+<!--more-->
+
+
+There are three main stacks in gRPC: C-core, Go, and Java.  Most of the languages are thin wrappers on top of the [C-based](https://github.com/grpc/grpc/tree/master/src/core) gRPC core library:


C++ based? but a restricted subset of C++? How do we want to word this? @vjpai any suggestions here?

hsaliak · 2018-12-05T23:18:03Z

_posts/2018-11-30-grpc-stacks.md

+
+<p><img src="https://grpc.io/img/grpc-java-stack.svg" alt="gRPC Java Stack" style="max-width: 800px" /></p>
+
+Again, the structure is a little different.  Java supports HTTP/2, QUIC, and In Process like the C-core.  Unlike the C-Core though, applications commonly can bypass the generated stubs and interceptors, and speak directly to the Java Core library.  Each structure is slightly different based on the needs of each language implementation of gRPC.


@vjpai as far as I am aware we do not have a non cronet QUIC transport.. IIUC We do not have server side support of quic either, but rely on a translating proxy in between...

sanjaypujare · 2018-12-11T21:25:26Z

_posts/2018-12-11-grpc-stacks.md

+
+For example, a Python application calls into the generated Python stubs.  These calls pass through interceptors, and into the wrapping library where the calls are translated into C calls.  The gRPC C-core will encode the RPC as HTTP/2, optionally encrypt the data with TLS, and then write it to the network.
+
+One of the cool things about gRPC is that you can swap these pieces out.  For example, you could use C# instead, and use an In-Process transport.  This would save you from having to go all the way down to the OS network layer.   Another example is trying out the QUIC protocol, which allows you to open new connections quickly.  Being able to run over a variety of transports based on the environment makes gRPC really flexible.


It will be good to provide a link/reference to In-process transport (grpc/grpc-java#518 or something better if there is one).

Similarly make "QUIC" hyperlinked (to https://www.chromium.org/quic or better)

sanjaypujare · 2018-12-11T21:28:39Z

_posts/2018-12-11-grpc-stacks.md

+
+One of the cool things about gRPC is that you can swap these pieces out.  For example, you could use C# instead, and use an In-Process transport.  This would save you from having to go all the way down to the OS network layer.   Another example is trying out the QUIC protocol, which allows you to open new connections quickly.  Being able to run over a variety of transports based on the environment makes gRPC really flexible.
+
+For each of the wrapped languages, the default HTTP/2 implementation is built into the C-core library, so there is no need to include an outside one.  However, as you can see, it is possible to bring your own (such as with Cronet, the Chrome networking library).


Make "Cronet" a link to https://developer.android.com/guide/topics/connectivity/cronet/ (or better?)

sanjaypujare · 2018-12-11T21:34:43Z

_posts/2018-12-11-grpc-stacks.md

+company-link: https://www.google.com
+---
+
+Here is a high level overview of the gRPC Stacks.  Each of the **10** default languages supported by gRPC has multiple layers, allowing you to customize what pieces you want in your application.


gRPC Stacks => gRPC Language Stacks

sanjaypujare · 2018-12-11T21:37:45Z

Looks good. In the next version it will be good to include a feature comparison matrix or table for the various language stacks so one can quickly see the Cronet and QUICK support is offered by core and Java but not by Go.

carl-mastrangelo · 2018-12-11T22:02:34Z

@sanjaypujare Agree on the matrix, though these are somewhat time consuming to make. (and keep up to date).

I sent a PR addressing your comments in #793

blog post about grpc stacks

4537604

carl-mastrangelo requested review from hsaliak and srini100 November 30, 2018 01:24

srini100 reviewed Nov 30, 2018

View reviewed changes

carl-mastrangelo added 2 commits November 30, 2018 11:29

update comments

d16a992

update pics

9598f45

srini100 approved these changes Nov 30, 2018

View reviewed changes

more fixes

8a79c4c

carl-mastrangelo commented Dec 1, 2018

View reviewed changes

hsaliak approved these changes Dec 5, 2018

View reviewed changes

publish!

d29589b

carl-mastrangelo merged commit b198570 into grpc:master Dec 11, 2018

carl-mastrangelo deleted the stacks branch December 11, 2018 19:51

sanjaypujare reviewed Dec 11, 2018

View reviewed changes

		<!--more-->


		There are three main stacks in gRPC: C-core, Go, and Java. Most of the languages are thin wrappers on top of the [C-based](https://github.com/grpc/grpc/tree/v1.16.1/src/core) gRPC core library:


		<p><img src="https://grpc.io/img/grpc-core-stack.svg" alt="gRPC Core Stack" style="max-width: 800px" /></p>

		For example, a Python application calls into the generated Python stubs. These call pass through interceptors, and into the wrapping library where the call is translated into C calls. The gRPC C-core will encode the RPC as HTTP/2, optionally encrypt the data with TLS, and then pass write it to the network.


		<p><img src="https://grpc.io/img/grpc-java-stack.svg" alt="gRPC Java Stack" style="max-width: 800px" /></p>

		Again, the structure is a little different. Java supports HTTP/2, QUIC, and In Process like the C-core. Unlike the C-Core though, applications commonly can bypass the generated stubs and interceptors, and speak directly to the Java Core library. Each structure is slightly different based on the needs of each language implementation of gRPC.


		For example, a Python application calls into the generated Python stubs. These calls pass through interceptors, and into the wrapping library where the calls are translated into C calls. The gRPC C-core will encode the RPC as HTTP/2, optionally encrypt the data with TLS, and then write it to the network.

		One of the cool things about gRPC is that you can swap these pieces out. For example, you could use C# instead, and use an In-Process transport. This would save you from having to go all the way down to the OS network layer. Another example is trying out the QUIC protocol, which allows you to open new connections quickly. Being able to run over a variety of transports based on the environment makes gRPC really flexible.


		One of the cool things about gRPC is that you can swap these pieces out. For example, you could use C# instead, and use an In-Process transport. This would save you from having to go all the way down to the OS network layer. Another example is trying out the QUIC protocol, which allows you to open new connections quickly. Being able to run over a variety of transports based on the environment makes gRPC really flexible.

		For each of the wrapped languages, the default HTTP/2 implementation is built into the C-core library, so there is no need to include an outside one. However, as you can see, it is possible to bring your own (such as with Cronet, the Chrome networking library).

blog post about grpc stacks #781

blog post about grpc stacks #781

Uh oh!

Conversation

carl-mastrangelo commented Nov 30, 2018

Uh oh!

carl-mastrangelo commented Nov 30, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carl-mastrangelo commented Nov 30, 2018

Uh oh!

srini100 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carl-mastrangelo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hsaliak left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sanjaypujare commented Dec 11, 2018

Uh oh!

carl-mastrangelo commented Dec 11, 2018

Uh oh!

Uh oh!