N.B. This is a Proof Of Concept library I built as a side-project over the last month to fulfill the needs I have for another project, it is NOT production ready. 🙏
- Goroutines hold an Endpoint 📍 on which they can listen for inbound Flow 🌊 establishment requests
- Flows 🌊 are bidirectional communication chanel between a client and an Endpoint 📍
- Fabrics 🔗 are meshes of Golang processes — potentially distributed over multiple machines — capable of establishing flow 🌊
This video shows the examples/hello-world example.
First, both goroutines are on the same node and can communicate using a
Flow 🌊 anyway, behind the scene grinta use native Go chan.
Then, we run the same binary but this time, we put each goroutine in a
different process. From a code point of view, nothing change for the goroutines,
they still use a Flow 🌊 but this time, grinta uses a QUIC inter-node
multiplexed stream fabric.
grinta-demo1-edited.mp4
- 😌 Simple API:
Fabric->Endpoint->Flowdescribes an intuitive hierarchy and their APIs are kept minimal. - ✍️ Built-in Codec: We already support:
- Protobuf,
- JSON,
- Raw Bytes,
- 🤏 Golang Focused: By focusing on a single language, we remove a lot of complexity and can optimise for just our specific use-case.
- 👪 No Central Authority: A
grintacluster has no central authority, no strongly consistent consensus protocol, nodes collaborate together to converge as fast as possible. - 😎 GRINTA Protocol: A custom protocol made on top of:
- a first QUIC Transport Layer supporting multiplexed inter-node bidirectional streams and lightweight datagrams,
- an implementation of the "SWIM" gossip protocol:
hashicorp/memberlist, - an adapter to run
memberlistclusters on top of our QUIC Transport Layer, - a set of versioned Protobuf Messages which describes our control plane communication format,
- an event and query bus to propagate Endpoint 📍 information:
hashicorp/serf;