2 ms·

I don't think we disagree about anything here, if you wanna optimize for maximal machine/network utilization then optimize for that with gRPC or equivalent, if

I don't think we disagree about anything here, if you wanna optimize for maximal machine/network utilization then optimize for that with gRPC or equivalent, if you wanna optimize for lean stack and have to use HTTP anyway because you're on the web then use (RPC over) HTTP - both can be considered more "efficient" depending on the setting and your constraints. But the point was that contrasting web requests with RPC is a mistake of category and has little to do with various IO handling and concurrency models that the author was discussing.

jchw 7y ago
Well, the thing is, I do agree with the author, though, on their point of not using web requests for RPCs. I think we must be interpreting the author's text differently.
- seemslegit 7y ago
  Either that or she's lumping together two separate issues, or both.
lern_too_spel 7y ago
The author never conflated the design choices of RPC protocol and threading model. Just the opposite, in fact. She listed them separately.
- seemslegit 7y ago
  Except she writes: " Then it does its weird userspace "thread" flip back to the original request's context and reads the response. It chews on this data, because, again, it's terrible JSON stuff and not anything reasonable like a strongly-typed, unambiguously, easily-deserialized message. The clock is ticking and ticking. " If she laments that it is bad design to do the deserialization on the IO thread it is just as true for JSON as it is for protobuf or whatever "true rpc" format she considers worthy.
  - lern_too_spel 7y ago
    It is less true for formats that deserialize faster. I still don't see where she is confusing the two. At the very top, she explicitly notes them separately: "I will not use web requests when the situation calls for RPCs. I will not use 'green' (userspace) 'threads' when there are actual OS-level threads and parallelization is necessary."

jchw 7y ago

Well, the thing is, I do agree with the author, though, on their point of not using web requests for RPCs. I think we must be interpreting the author's text differently.

seemslegit 7y ago
Either that or she's lumping together two separate issues, or both.

lern_too_spel 7y ago

The author never conflated the design choices of RPC protocol and threading model. Just the opposite, in fact. She listed them separately.

seemslegit 7y ago
Except she writes: " Then it does its weird userspace "thread" flip back to the original request's context and reads the response. It chews on this data, because, again, it's terrible JSON stuff and not anything reasonable like a strongly-typed, unambiguously, easily-deserialized message. The clock is ticking and ticking. " If she laments that it is bad design to do the deserialization on the IO thread it is just as true for JSON as it is for protobuf or whatever "true rpc" format she considers worthy.
- lern_too_spel 7y ago
  It is less true for formats that deserialize faster. I still don't see where she is confusing the two. At the very top, she explicitly notes them separately: "I will not use web requests when the situation calls for RPCs. I will not use 'green' (userspace) 'threads' when there are actual OS-level threads and parallelization is necessary."