3 ms·

How does the serialization layer impact your rpc choice?

• cmrdporcupine 3y ago
  Cap'N'Proto comes with a (quite good) RPC facility. Based on asynchronous promises and grounded in capabilities. You don't have to use it. You could just use it just as a 'serialization' layer but if you're writing services you could be missing half the advantage, really. And if you're writing in C++ you'll end up having to use their KJ library anyways. If you take the whole package the zero copy, capability-security, and asynchrouny (a word I just coined!) all fit together nicely.
  • insanitybit 3y ago
    Yeah I'm aware of all of that. What I'm saying is that I don't see what about the Schema Definition Language pushes you towards the RPC other than that they obviously go well together, just like gRPC is almost always used with protobuf, or http with JSON. > but it bothers me that what is ultimately a message encoding protocol has an opinion on how I should architect my server. To me, this is like saying "Using JSON is unfortunate because it has an opinion that I should use HTTP" when I don't think anyone would argue that at all, and I don't see the argument for capnp much either.
    • kentonv 3y ago
      The main thing that Cap'n Proto PRC really requires about the serialization is that object references are a first-class type. That is, when you make an RPC, the parameters or results can contain references to new, remote RPC objects. Upon receiving such a reference, that object is now callable. Making this work nicely requires some integration between the serialization layer and the RPC layer, though it's certainly possible to imagine Protobuf being extended with some sort of hooks for this.
  • ajkjk 3y ago
    Asynchrony?