5 ms·
The first thing I start trying to convince people to ditch on any internal service is JSON. There are only two times when JSON is a particularly good choice: w
by bunderbunder 8y ago
The first thing I start trying to convince people to ditch on any internal service is JSON.
There are only two times when JSON is a particularly good choice: when it's important for the messages themselves to be human-readable, or when it's important to be able to consume it from JavaScript without using a library. Any other time, something like protocol buffers is going to give you lower latency, lower bandwidth requirements, lower CPU costs, lower development effort, less need for maintaining documentation, and better standardization.
If you ditch the HTTP stuff while you're at it, you can also handily circumvent all the ambiguities and inter-developer holy wars that are all but inherent to the process of taking your service's semantics, whatever they are, and trying to shoehorn them into a 30-year-old protocol that was really only meant to be used for transferring hypermedia documents. Instead you get to design your own protocol that meets your own needs. Which, if you're already building on top of something like protobuf, will probably end up being a much simpler and easier-to-use protocol than HTTP.
- CoolGuySteve 8y agoMan if you think protobuf is fast, just wait until you try C pod structs with type-length headers. They are literally infinitely faster to encode/decode than protobuf. They even have the same obnoxious append-only extensibility of protobuf if that’s what really gets your jimmies firing.
- netmonk 8y agoasn1 for the win
- Danieru 8y agoFlatBuffers and then Endian concerns are gone.
- presscast 8y agoAre FlatBuffers essentially Capnproto without the RPC?
- alexhutcheson 8y agoFlatBuffers can be used with gRPC, so they shouldn't need a separate RPC ecosystem like Cap'n Proto: https://grpc.io/blog/flatbuffers https://grpc.io/blog/flatbuffers
- presscast 8y agoRight, but I'm asking if FlatBuffers' approach to encoding is similar to Cap'n Proto. It seems like the answer is "yes", but I might be missing something.
- kentonv 8y agoThey are both zero-copy, but the designs have a number of differences. I compared them back in 2014: https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... Disclaimers: 1) I'm the author of Cap'n Proto; I'm probably biased. 2) A lot could have changed since 2014. (Though, obviously, serialization formats need to be backwards-compatible which limits the amount they can change...)
- presscast 8y agoCool, thanks for this! I'm happily using Cap'n Proto in a side project, and so far have really enjoyed working with it. It's a really impressive piece of engineering.
- stouset 8y agoNot to mention, JSON APIs start out simple because you just call `to_json` on whatever object you need to share and then move on. Except nobody’s ever documented the format, and handling ends up taking place in a million different places because you can just pass the relevant bits around. The API is “whatever it did before we split it up”. Now when someone goes to replace one side, it’s often impossible to even figure out a full definition of the structure of the data, much less the semantics. You watch a handful of data come across the pipe, build a replacement that handles everything you’ve seen, and then spend the next few months playing whack-a-mole fixing bugs when data doesn’t conform to your structural or semantic expectations. JSON lets you get away with never really specifying your APIs, and your APIs often devolve to garbage by default. Then it becomes wildly difficult to ever replace any of the parts. JSON for internal service APIs is unmitigated evil.
- geezerjay 8y ago> Except nobody’s ever documented the format, That's hardly a JSON problem. You still experience that problem if you adopt any undocumented document format or schema.
- danmaz74 8y agoI think the point the OP was making was more about the tooling than the format. Having a library that forces you to define the format you're using, instead of dumping to_json whatever internal representation you had, also doubles as documentation. But then, of course, that can be considered boilerplate code (and, in the beginning and most of the time, it actually is just a duplication of your internal object structure).
- bunderbunder 8y agoThat, and having the format definition file support comments means that you have a convenient all-in-one place where, at lest in the more straightforward cases, you can handily describe both the message format and the service's behavior in a single file that's easy to share among all your teams.
- StavrosK 8y agoWhat serialization format do you all recommend when starting out? Protobufs seems to be the go-to, but what about Cap'n Proto etc?
- deleted 8y ago[deleted]
- alexhutcheson 8y ago(personal opinion, not speaking on behalf of my employer) Start out with protobufs, so you can take advantage of gRPC[1] and all of its libraries and all the other tooling that is out there. If you profile and determine that serialization/deserialization is actually a bottleneck in your system in a way that is product-relevant or has non-trivial resource costs, then you can look at migrating to FlatBuffers, which can still use gRPC[2]. [1] https://grpc.io/ https://grpc.io/ [2] https://grpc.io/blog/flatbuffers https://grpc.io/blog/flatbuffers
- StavrosK 8y agoAh, good tip, thanks!
- bunderbunder 8y agoI'd agree on starting with protobufs, precisely because it's the go-to. Other options have plenty of advantages, but none are as widely supported.