
GRPC and JSON - ngaut
https://grpc.io/blog/grpc-with-json
======
drenvuk
All of these should come with the disclaimer that your use case among other
things will determine how much your mileage varies. For instance, when I
benchmarked (wrk) my json utilizing API with a payload size of 145-200 bytes +
a minimal header it came out ahead of GRPC with protobufs. I was getting
~180,000 requests per second with serialization & deserialization on my laptop
(Thinkpad T25). You're already saturating a 1gbps connection at 1/3 of that
output but when you think of the extra leeway for processing that you have,
not to mention the smaller size box you can run it on it's pretty nice.

This wasn't in java, the environments themselves are different, the code is
different, the benchmarking tool is different, etc, etc so maybe it's not
applicable but it still stands that you should investigate whether it will
really be worth it or not to invest in the tech if you optimize elsewhere. I
mean, I've tried similar things with python and have only gotten 20-40k rps
across various frameworks.

Please take everything above with a grain of salt and do your own research.

~~~
foota
Interesting, what was your test setup like out of curiosity?

~~~
drenvuk
Kore.io, 4 workers, modified cpp example, along with state machine
[https://github.com/jorisvink/kore](https://github.com/jorisvink/kore)

json library
[https://github.com/nlohmann/json](https://github.com/nlohmann/json)

wrk, post with json payload via lua post script
[https://github.com/wg/wrk](https://github.com/wg/wrk)

~~~
misterbowfinger
Interesting! I wonder if there's a bug in the gRPC library that you used?

------
paradite
I thought this was a comparison between gRPC and JSON, but turns out to be
about using rRPC and JSON together.

I think HN title should be changed to either "gRPC + JSON" (the original
title), or "gRPC with JSON", which is in the url.

------
Aardappel
Similarly, you can use it with FlatBuffers:
[https://grpc.io/blog/flatbuffers](https://grpc.io/blog/flatbuffers)

------
maxpert
One thing I hate about GRPC with Kotlin is the crap of get set that it
generates for Request/Response payloads. I've always wanted to used basic POJO
objects and this might solve my problem. Although I've seen some unmaintained
Kotlin generators for GRPC there is no battle tested solution and this post
just might solve my problem. Jackson is performant enough for me.

~~~
throwexceptionz
Can you elaborate on what these getter setters look like?

~~~
willeh
I think he is referring to the fact that you use a fluent builder interface
when building protobuf messages so you chain together a bunch of
`.setFoo(myFoo).myBar(myBar).build()` to build your protobuf, while in Kotlin
it is idiomatic to write `foo = myFoo` and `bar = myBar`. There are ways
around this with `.apply` in Kotlin, but it all feels really clunky.

That said if you want a systematic don't make me think approach for backward
and forward compat I think protobuf/GRPC is the way to go you just need to
learn a few rules for how to do it and you're set. In terms of static typing
protbuf doesn't really get you that much because in order to get
backward/forward compat you can't have required fields, so everything needs to
be null-checked or have default values.

