Frequently Asked Questions
Why the framework is called Spine?
Why use Protobuf and not Json?
Because Protocol Buffers are implemented in a variety of languages, they make interoperability between polyglot applications in your architecture that much simpler. If you’re introducing a new service with one in Ruby or Go, or even communicating with a backend written in Node, or Clojure, you simply have to hand the proto file to the code generator written in the target language and you have some nice guarantees about the safety and interoperability between those architectures.
The finer points of platform specific data types should be handled for you in the target language implementation, and you can get back to focusing on the hard parts of your problem instead of matching up fields and data types in your ad hoc JSON encoding and decoding schemes.
Why Protobuf instead of Cap'n Proto, or SBE, or FlatBuffers?
Have a look the comparison matrix created by Kenton Varda, the author of Protobuf v2 and Cap'n Proto. The main features that make Protobuf best choice for our framework are:
- Schema evolution — we need this as business models evolve as business grows.
- Usable as mutable state — we need this for transforming Aggregate States and Stream Projections.
Also, the experience Google gained through years of using this technology internally is a major factor of preferring Protobuf over alternatives.
Which version of Protobuf can I use?
The framework is based on and supports only proto3 dialect.