We want to give our users a framework that provides an infrastructure and connects the “service” parts of applications with their “brains”, or in other words, business logic.
As Protocol Buffers are already implemented in a variety of languages, they make interoperability between polyglot applications in your architecture 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 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 your tasks instead of matching up fields and data types in your ad hoc JSON encoding and decoding schemes.
Have a look at the comparison matrix created by Kenton Varda, the author of Protobuf v2 and Cap'n Proto. Here are the main features that make Protobuf the best choice for our framework:
- Schema evolution — business models should evolve as the business grows.
- Usable as mutable state — for transforming Aggregate States and Stream Projections.
Also, proven success of Protobuf technology which Google gained over the years of its successful usage is a major factor for choosing Protobuf rather than other alternatives.
The framework is based on and supports only proto3 dialect.
Here are our plans for the future versions of Spine:
- PostgreSQL storage implementation;
- Migrate to Java 11;
- Scaffold entity classes from Protobuf;
- Generate Bounded Contexts using existing Java model definitions.
We shall also concentrate on coverage of popular programming languages and technologies:
- Node.js to enable Projections development by our users creating UI.
- Dart client library.
No, and we don't have plans to support it.
If you are going to add Spine to an existing Maven-based projects, most likely it would be implemented as a Bubble Context.
If so, you can have a Gradle-based sub-project with which the outer Maven-based project integrates.