Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

gRPC-Go Engineering Practices

grpc.io

Post reply on HN
Print view View original

61–70 of 85 posts

Re: gRPC-Go Engineering Practices

#61

Post by jkarneges »

dguaraglia wrote: post #60
zeveb wrote: post #28

Earlier quoted context omitted.

> Most of those clients haven't been updated to deal with the HTTP/2 machinery necessary to drive streams the way gRPC does. HTTP has supported streaming data for years, e.g. Server-Sent Events[0]. The short version is that you GET a URL, and the body keeps on arriving forever. I'm pretty sure that we had this sort of HTTP streaming back in the late 90s … I'll grant that many JSON-oriented pseudo-REST clients probabl…

Right, but server-sent events work only one way: from server to client. gRPC allows you to create bi-directional streams, where both the client and server are pumping data. Chunked encoding allows to do something like what gRPC does, but it's my understanding (I might be wrong) that the data needs to be base64 encoded, whereas HTTP/2 supports raw byte arrays to be sent.

HTTP/1 responses carry raw bytes, and chunked encoding doesn't affect that (just some packet length prefixing).

If you mean binary data would need to be Base64-encoded with server-sent events, that's true. SSE uses text/event-stream as the content type, which is expected to be text. It would be interesting if someone defined a content type for streaming binary events.

Re: gRPC-Go Engineering Practices

#62

Post by marshallbrekka »

doh wrote: post #45
bruth wrote: post #40

Slightly off-topic, but related.. I have read that a common practice for managing proto files (or any schema definitions really) is to put them in a separate repo/package to share. It seems pretty straightforward in my head and provides several advantages. However I still ask about any trade-offs when doing this in practice?

It has similar challenges than a monorepo. First challenge is, that you have to keep some kind of reference on what proto are you using within your project. What Google (and some others) do, is that they a) put all the proto files in a separate repo [0] and then generate them for each language separately (python [1], ...). This way you can use whichever proto file you need within your project, however you have to loa…

The mono-repo of protos has been our approach, and has worked very well for us so far.

Only difference is we publish the resulting code for all languages into a single artifact repo, which other projects use as a dependency.

Re: gRPC-Go Engineering Practices

#63

Post by jkarneges »

Thaxll wrote: post #32
zeveb wrote: post #28

Earlier quoted context omitted.

> Most of those clients haven't been updated to deal with the HTTP/2 machinery necessary to drive streams the way gRPC does. HTTP has supported streaming data for years, e.g. Server-Sent Events[0]. The short version is that you GET a URL, and the body keeps on arriving forever. I'm pretty sure that we had this sort of HTTP streaming back in the late 90s … I'll grant that many JSON-oriented pseudo-REST clients probabl…

Server sent is not stream, it's a pseudo bad implementation on top of http 1.1.

How is SSE not a stream? HTTP 1.1 does a fine job of sending streaming content, and SSE is a stream-parsable content type.

Re: gRPC-Go Engineering Practices

#64

Post by malkia »

kyrra wrote: post #18
willvarfar wrote: post #9

Earlier quoted context omitted.

Afraid I'm going to be contrary and old-fashioned and say I prefer JSON. Its never been problematic adding or extending JSON endpoints and its never been a problem using basic gzip compression on the fly either. And JSON endpoints are a damn sight easier to debug and wireshark and all the rest. I've spent a lot of time writing fast JSON serialization for various languages including Java etc; its staggering how ineffi…

There are definitely cases for both. JSON is definitely easier to consume as a human (so for debugging). gRPC was born out of Google's Stubby rpc system[0], which is used heavily for communicating between different jobs. If you are going to stand up a lot of different services that are going to talk, it provides a lot of advantages that you don't get with JSON. For large companies that use multiple program languages,…

Also a protobuf may be stored directly in some of the databases google uses internally, then you have lots of tools around them (diffing with map-reduces done on them, etc.).

Re: gRPC-Go Engineering Practices

#65

Post by malkia »

dmayle wrote: post #3
rb808 wrote: post #2

Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?

Json is a serialization format. gRPC is both a serialization format and a DDL (data definition language). That means that you are storing your schema, which also happens to contain interoperability features. ...and the serialization format is more efficient.

The schema is not stored, rather think of it this way, a .proto file once it generates an interface for specific language, then this actual code understands the schema.

Now on the wire, you simply sent field numbers (e.g. the numbers that you have to manually specify in monotonically increasing way, and never reuse smaller number), and either simple type (int, float) or symbol reference to another.

But you never send the actual schema... Now some specific storage formats, might have a duplicate version of that schema, but this may be just part of their design.

So the nice thing, is that if you follow some simple rules, like: never reuse previous number, be careful when changing types of existing fields (there are only so and so ways it can go), then you can upgrade independently your services, and the data being pushed.

For example if you've added a new field (and new number), then your existing code (that's still compiled with the older schema), might just ignore it, since, even that it's there, there is no endpoint (e.g. method call to read it) for it to be accessed.

Off course, it's not so simple. After all, there are tricks, should I simply pass through fields that I do not understand to other services, or should I filter them? I certainly don't know.

I wish protos are used more and more, and ways to put them into various databases (like mysql, postgres, sqlite, etc.) is done. Then also formats that store such data in more optimal way, by rearranging such that compression can be gained, and later faster retrieval, etc.

Re: gRPC-Go Engineering Practices

#66

Post by anameaname »

willvarfar wrote: post #9
rb808 wrote: post #2

Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?

Afraid I'm going to be contrary and old-fashioned and say I prefer JSON. Its never been problematic adding or extending JSON endpoints and its never been a problem using basic gzip compression on the fly either. And JSON endpoints are a damn sight easier to debug and wireshark and all the rest. I've spent a lot of time writing fast JSON serialization for various languages including Java etc; its staggering how ineffi…

For the record, gRPC can use JSON. There are examples in the repo on how to do this:

https://github.com/grpc/grpc-java/blob/master/examples/src/m...

Re: gRPC-Go Engineering Practices

#67

Post by mpweiher »

kajecounterhack wrote: post #4
rb808 wrote: post #2

Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?

Versioning your API is one huge benefit and better done using proto/rpc. If you change your Json schema, have fun propagating that change to all clients without fear. Or hope you've built special infra to do that. Also "just more efficient" is a funny way to characterize the performance difference between just data bytes vs data + structure bytes (read: the gap is large). You gain in transmission and you gain during…

> performance difference [..] (read: the gap is large)

Hmm...can you quantify that? I found that while these performance difference you mention exist, they are not actually that large and completely dwarfed by actions later in the chain, particularly if you have generic intermediate representations.

Re: gRPC-Go Engineering Practices

#68

Post by quietbritishjim »

virmundi wrote: post #43

Has anyone found a good resource on using gRPC directly in a JS client? I've looked at using gRPC. My current challenge is that I want to support a website/webgateway on one side and mobile gateway on the other. If I use Swift or Java on the mobile side, it's easy. If I use Ionic Framework, I'm in the same spot as with the web gateway; probably better off with HTTP + RPC.

It is possible to use gRPC directly from JavaScript using the gRPC-Web [1] project by Improbable. More accurately, it uses TypeScript, which is generated from the proto file in a similar way to other languages. You still need a proxy to transform requests from HTTP/1.1 to HTTP/2.0.

I've actually only used the gRPC JSON gateway mentioned in the other replies so I'm not sure how it compares, but it looks interesting.

[1] https://github.com/improbable-eng/grpc-web

Re: gRPC-Go Engineering Practices

#69

Post by matthewrudy »

Inflatablewoman wrote: post #59
rb808 wrote: post #2

Its a good time to ask, is gRPC any good? I'd love to standardize on stable middleware layer that handles multiple versions of clients and servers well. Rest with json really seems to work great for most things already. What is the advantage of gRPC - just more efficient?

My only regret is that when we started our current project, I did not commit 100% to gRPC, so now we have a mix of services. If I had of gone all in, it would be easier to integrate upcoming things like conduit [1], and I would not have to generate Swagger files but could just ship the proto files. [1] https://conduit.io/

I believe conduit is going to support HTTP1.1 by the time it's done.

The http2 and grpc focus was just to get the alpha release out there.

Re: gRPC-Go Engineering Practices

#70

Post by bruth »

doh wrote: post #45
bruth wrote: post #40

Slightly off-topic, but related.. I have read that a common practice for managing proto files (or any schema definitions really) is to put them in a separate repo/package to share. It seems pretty straightforward in my head and provides several advantages. However I still ask about any trade-offs when doing this in practice?

It has similar challenges than a monorepo. First challenge is, that you have to keep some kind of reference on what proto are you using within your project. What Google (and some others) do, is that they a) put all the proto files in a separate repo [0] and then generate them for each language separately (python [1], ...). This way you can use whichever proto file you need within your project, however you have to loa…

Thanks for the response! These are very good references. I like the breakdown of message and/or service definitions into separate files so it is easy to browse through the repository. I am assuming the version bump (v1 vs. v2) occurs when you introducing breaking changes to the API? I am aware that protobuf does a good job at allowing forwards and backwards compatibility at the message level..
Post reply on HN