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

81–85 of 85 posts

Re: gRPC-Go Engineering Practices

#81

Post by mehrdada »

ocdtrekkie wrote: post #72
Xorlev wrote: post #38

Earlier quoted context omitted.

Disclaimer: I work for Google, but not on gRPC. It's worth mentioning that gRPC is actually format-agnostic. While I can't say it does the best job of this (gRPC+protobuf works best), there's precedent for using any transport in gRPC. gRPC-Java includes examples of JSON serialization and Thrift serialization. gRPC is just the transport protocol (its self built on HTTP/2). That said, I'd highly recommend protobufs, th…

As a note, a disclaimer like this given without explanation could seem to indicate gRPC is a Google product even though apparently it no longer is. I actually had a conversation with the gRPC mailing list a few weeks back about how weirdly this has been communicated on their website as well. The linked blog post continues to refer to 'we' as 'Google'. (For those curious, IIRC it is now been handed off to a subgroup o…

Thanks for the feedback; we updated the footer: https://github.com/grpc/grpc.github.io/pull/622/files

Note that this is an open-source project, and the website itself is on GitHub Pages, so feel free to send us pull requests. Sometimes the reason behind things not changing is not a huge conspiracy, but no one actually having spare time to do it. :)

Re: gRPC-Go Engineering Practices

#82

Post by ocdtrekkie »

mehrdada wrote: post #81
ocdtrekkie wrote: post #72

Earlier quoted context omitted.

As a note, a disclaimer like this given without explanation could seem to indicate gRPC is a Google product even though apparently it no longer is. I actually had a conversation with the gRPC mailing list a few weeks back about how weirdly this has been communicated on their website as well. The linked blog post continues to refer to 'we' as 'Google'. (For those curious, IIRC it is now been handed off to a subgroup o…

Thanks for the feedback; we updated the footer: https://github.com/grpc/grpc.github.io/pull/622/files Note that this is an open-source project, and the website itself is on GitHub Pages, so feel free to send us pull requests. Sometimes the reason behind things not changing is not a huge conspiracy, but no one actually having spare time to do it. :)

Perfect. It'll be nice when Google isn't the only 'author' ;) but now I can clearly end up finding the CNCF this way. It just seemed apparent from the parent comment that it was possible even Googlers commenting were unaware gRPC was now under the CNCF! :)

I generally wouldn't file a PR on someone's copyright line or similar legalese, I don't know what the impact would be for any given organization or how they need to format it.

Re: gRPC-Go Engineering Practices

#83

Post by mehrdada »

ocdtrekkie wrote: post #82
mehrdada wrote: post #81

Earlier quoted context omitted.

Thanks for the feedback; we updated the footer: https://github.com/grpc/grpc.github.io/pull/622/files Note that this is an open-source project, and the website itself is on GitHub Pages, so feel free to send us pull requests. Sometimes the reason behind things not changing is not a huge conspiracy, but no one actually having spare time to do it. :)

Perfect. It'll be nice when Google isn't the only 'author' ;) but now I can clearly end up finding the CNCF this way. It just seemed apparent from the parent comment that it was possible even Googlers commenting were unaware gRPC was now under the CNCF! :) I generally wouldn't file a PR on someone's copyright line or similar legalese, I don't know what the impact would be for any given organization or how they need t…

CONTRIBUTING.md in the repository[1] explicitly suggests authors to add their name to the AUTHORS file on their first substantial commit should they like to. A reviewer would work with them on the order and formatting. One thing is for sure: there is a diverse contributor base; you can see the full list in the git history.

[1] https://github.com/grpc/grpc/blob/master/CONTRIBUTING.md

Re: gRPC-Go Engineering Practices

#84

Post by kajecounterhack »

virmundi wrote: post #42
weberc2 wrote: post #29

Earlier quoted context omitted.

I fully agree, but want to point out that JSON can be compressed.

You're absolutely right. Auth0 shows that when compressed, protobufs don't provide a great benefit vs JSON. Something I've read from others is that gRPC is not the easiest thing to use directly in SPA. If you have services exposed to a web front end and mobile, double exposing a REST-ish API + gRPC might not be worth it. This is a problem with which I'm currently struggling. https://auth0.com/blog/beating-json-perfor…

When compressed sizes can still matter as the payload size increases.

REST is the language the rest of the web speaks so if providing a consumer service that isn't latency sensitive you should feel at liberty to give a RESTful API.

If you're building internal services, consumed internally, gRPC is a decent way to go.

If say you're providing a logging service to a number of large customers you might want to provide a gRPC service for the performance characteristics.

gRPC also provides you the option to write all your services internally using gRPC and then you can expose a JSON service without having to write it yourself.

Re: gRPC-Go Engineering Practices

#85

Post by doh »

bruth wrote: post #78
doh wrote: post #76

Earlier quoted context omitted.

Correct on the versioning. We internally treat protos as an immutable descriptions of our API interfaces. That means whenever we need to change anything (outside of bugs), be it adding a new field, or changing the order, renaming fields, changing types, ... we start a new version. We also use a lot of inheritance of non-default types (timestamps, errors, ...) so it's important to make sure that we don't break anythin…

Interesting so adding new fields even.. I suppose there is quite a bit of planning and iterating on the interface before making it public to reduce churn? I understand doing that for backwards incompatible changes.

We add new fields (or redesign existing protos) very sporadically. We also don't have fully automated process to deal with a change in a proto within all projects so by using new versions we can signal to the developers that they should eventually adopt it. We are actively using 5 languages that have to deal with the changes, so we found it easier overall to do it this way.
Post reply on HN