81–90 of 99 posts
Earlier quoted context omitted.
There has recently been a lot of work for native grpc client in the browser. It’s not fully there yet but is looking real promising! https://github.com/improbable-eng/grpc-web
Also grpc web is coming along https://github.com/grpc/grpc-web
Earlier quoted context omitted.
Thanks for posting! How did you work around issues with GRPC on AWS/ELB?
When I implemented GRPC on ELB, we used a multiplexer to re-route the GRPC requests. See: https://github.com/soheilhy/cmux/ . The only other issue we had was that ELB's would not let connections live longer than 30 seconds.
Hey everyone! I'm the OP and primary author of Twirp. I'm happy to answer any questions and hear feedback. You can also reach me directly, if you like, email is in my profile.
I like the simplicity of the library. I haven't tried it yet, but this behavior is a bit unfortunate choice > If there is an error, it will be JSON encoded, including a message and a standardized error code. Why not to return standard protobuf error when the source was a protobuf? It massively complicates things when you have to expect errors in one format and responses in the other.
Hopefully, the complexity is encapsulated by the generated client.
POST /api/user/:username/update_email
POST /api/user/:user_id/update_email
Earlier quoted context omitted.
I like the simplicity of the library. I haven't tried it yet, but this behavior is a bit unfortunate choice > If there is an error, it will be JSON encoded, including a message and a standardized error code. Why not to return standard protobuf error when the source was a protobuf? It massively complicates things when you have to expect errors in one format and responses in the other.
It’s important for errors to be human-readable off the wire. If they were proto-encoded, you couldn’t get at them easily with tcpdump, and you couldn’t read erroring response bodies from curl, and you couldn’t read errors shipped to stuff like rollbar. Hopefully, the complexity is encapsulated by the generated client.
Earlier quoted context omitted.
It’s important for errors to be human-readable off the wire. If they were proto-encoded, you couldn’t get at them easily with tcpdump, and you couldn’t read erroring response bodies from curl, and you couldn’t read errors shipped to stuff like rollbar. Hopefully, the complexity is encapsulated by the generated client.
What about allowing/respecting an Accept header in the Request? In @doh's case, if the client only specified Accept: application/protobuf that would override the default behavior of returning JSON encoded errors.
But what would the benefit(s) to users be? If they are deserializing a protobuf error, they are almost certainly using a generated client, so I don’t think they will know or care how the error was encoded.
(This might be better as a github issue to keep a visible record of the design for others.)
Earlier quoted context omitted.
Can I ask why you want JSON with gRPC? The benefits to protobuf are tremendous, with little to no downsides
On the other hand, plain URLs with JSON are much easier to work with without writing any code. You can do everything want with curl from the shell, and often an API allows doing almost anything from a browser (Elasticsearch comes to mind). The simplicity of it all comes in handy when you want to do something trivial — load a small piece of data into the server, do some diagnostics, run some ad-hoc queries, etc. — wit…
For a few years inside Google I experienced zero discussions about almost every aspect of RPC. It took a trivial amount of time to implement stuff interfaces, clients and servers in multiple languages and it was trivial to understand the interface of, and implement a client for, other people's code.
I didn't necessarily like everything in Stubby, but I absolutely loved not needing to have pointless discussions about RPC mechanisms or protocol design.
Since I left Google, anything even remotely resembling RPC (including REST) has been an utter waste of time mostly spent bickering over this crap solution or that crap solution – mostly with people who don't care about the same things you care about.
REST is a crap solution in my eyes because it invites absolutely endless discussions on an endless list of subtopics. From the dogmatic/fundamentalist HATEOAS end of the spectrum to the RPC-using-HTTP-and-JSON-and-let's-call-it-REST camp. Not to mention that in addition you need to have an IDL and toolchain discussion. (Of course, none of the toolchains or ways to describe interfaces are very good. In fact, they all suck in part because the attention is being spread across so many efforts that don't get the job done).
I have yet to see an IDL that works better than a commented .proto file from a "get stuff done" point of view.
I completely understand where you are coming from when it comes to having human readable wire format. For 20 years I was a strong believer in the same, and for some systems I still believe in human readable formats.
But RPC and RPC-like mechanisms is no longer among them. RPC is for computers to talk to each other and not for humans trying to manually repair stuff.
(I'm a pragmatist, so I'm allowed to both change my mind and have seemingly inconsistent opinions :-))
For RPC you should encourage the creation of tools. If you need to look at the traffic manually: fine, make a Wireshark plugin or a proxy that can view calls in real time. That's annoying, but cheaper than going off and inventing yet another mechanism. And once it is done, it is done and there's one more thing that is sane.
We should really encourage people to build tools so we can automate things and have more precise and predictable control over what we are doing without having to reimplement parsing (which is what happens if people think they understand your protocol - which they often don't)
Also, make sure it works for a large enough set of implementation languages and understand how to work in mechanical sympathy with build systems. I don't care if Cap'n Proto is marginally better than Protobuf if it lacks decent support for languages I have to care about.
I have no idea how much time we wasted on trying to get Thrift to work in a Java project that needed to build on Windows, Linux and OSX back in the day, but I was ready to strangle the makers of Thrift for not paying attention to this.
At this point I'm beyond caring about the design of RPC systems. I just want something that works for software development and doesn't have to be a discussion. Hence, I get annoyed every time I see a new RPC mechanism instead of attempts to make some of the existing mechanisms work by just making just one aspect of them a bit more sane and exhibit a bit more empathy with programmers rather than the egos of protagonists of various libraries, frameworks and formats.
Here's how we did it in CockroachDB: https://github.com/cockroachdb/cockroach/blob/24ed8df04719a1...
The supporting code (protoutil) is https://godoc.org/github.com/cockroachdb/cockroach/pkg/util/... and https://godoc.org/github.com/cockroachdb/cockroach/pkg/util/....