71–80 of 111 posts
Any plans for rust lang bindings?
would love community contributions :-). I see some efforts in community but nothing very concrete yet. You can suggest project in gRPC Ecosystem. https://github.com/grpc-ecosystem
Earlier quoted context omitted.
> This turned out to be caused by HTTP/2.0 which only allows 1 billion streams over a single connection. Hilarious. People called this issue out as an obvious flaw when HTTP/2.0 was first proposed, got ignored, and here the issue is. For those unfamiliar: HTTP/2.0 uses an unsigned 31-bit integer to identity individual streams over a connection. Server-initiated streams must use even identifiers. Client-initiated stre…
May be I'm stupid, but how hard it is it to reimplement it as 64 bit unsigned ?
Earlier quoted context omitted.
We use it heavily on multiple projects across languages, and for the most part it works very well. We've had some pain about sharing proto definitions across languages and keeping them in sync. It's probably a much smaller problem when you've got a company-wide monorepo like Google, but you'll definitely have to be vigilant about your build processes to make sure you have the latest definitions shared. Some of the la…
Could you expound upon the problem of keeping your protocol definitions in sync? In my experience this is the strength of protocol buffers: if you follow a few rules, your systems can successfully be decoupled. Some of the rules are never re-using a tag number and never changing a type in an incompatible way (e.g. string->bytes might be ok, but int32->bytes is not).
Most of the projects that we're integrating gRPC into are existing codebases that have their own build tools that are (mostly) in isolation. JSON schemas have been agreed on beforehand, and there are separate client implementations in different languages that basically exists as independent units.
By adding protobufs to this process, the "JSON schemas that have been agreed on" become protobuf definitions - which is _fantastic_ for development teams, because they have a single spec to work from, and there is no ambiguity (or, significantly less).
The challenge comes when we are trying to generate gRPC clients in Go, Ruby and Python for the same profobuf file - in order to do it in an automated fashion without a 'monorepo', we need to create a build system that pulls this protobuf from a central place and generates the client, which doesn't exist right now.
It's not a huge challenge to ensure services can communicate at all - as you said, protobufs have thought of this and have an extensive amount of decoupling built in. When we're working on adding new features however, we need to have a place to keep the "gold master" of protobufs, and grab it for all of our projects to build+deploy at once, which is where the above becomes challenging.
Not an un-solvable problem, and different languages have different tooling for this. We've settled on placing the proto definitions in the "server" side (most of our interactions are fairly well modeled by client/server), and then updating the clients as-necessary, as we can deploy server changes without needing to update the clients immediately.
How does this compare to something like zeroMQ?
Earlier quoted context omitted.
> This turned out to be caused by HTTP/2.0 which only allows 1 billion streams over a single connection. Hilarious. People called this issue out as an obvious flaw when HTTP/2.0 was first proposed, got ignored, and here the issue is. For those unfamiliar: HTTP/2.0 uses an unsigned 31-bit integer to identity individual streams over a connection. Server-initiated streams must use even identifiers. Client-initiated stre…
So, that's the other side of the argument? I assume there was at least a reason they specced it this way originally, even if under comparison those reasons wouldn't have held up. Was there any justification, or was it literally ignored?
Since HTTP2 is a client->server protocol, the server can close whenever and the client can just open another one.
def GetFeature(self, request, context):
Ugh, why does the Python driver use CamelCase method names? def GetFeature(self, request, context): http://www.grpc.io/docs/tutorials/basic/python.html
However, according to the style guide, camelcase is preferred, and the compiler is supposed to generate language-native names with the correct case [1].
One thing the terrible years of SOAP and WSDL should have taught people is that generated stubs are awful to use if they go against the grain of the host language.
[1] https://developers.google.com/protocol-buffers/docs/style
Ugh, why does the Python driver use CamelCase method names? def GetFeature(self, request, context): http://www.grpc.io/docs/tutorials/basic/python.html
Can anyone explain like I'm 5 what an RPC framework is?
for example, if you visit: https://api.github.com/repos/grpc/grpc/issues
you'll get some json back. what happens is the browser resolves "api.github.com" (via DNS) to an IP address, and then opens a socket connection to that address. then, in accordance with the HTTP protocol it executes a "GET" operation (a notion particular to HTTP), and in response the github server will talk to a database or cache and respond with data appropriate to request.
because this sequence of events happens across network boundaries (ie, your browser is talking to something outside your computer), it's often referred to as a "remote" procedure call.