dwettlaufer

Stargate v1 is a monolith where everything runs within the same JVM which means service to persistence communication is just simple method calls. One of our main goals of Stargate v2 was to break up this monolith which meant that we could no longer communicate with just direct method calls and would instead need to bridge the gap between service and persistence with some other communication mechanism. We explored a few different options such as REST or CQL via drivers but ultimately landed on gRPC for a few reasons:

1. REST could be a viable option and has been used many times when splitting up a monolith but we didn't believe it could give us the performance we would need due to opening and closing connections

2. With REST we would essentially have to define our own schema definition language to describe the transport of messages between service and persistence which would also add the overhead of serializing and deserializing json payloads

3. CQL is a proven transport mechanism but requires the use of a driver which means whatever language used to implement the service must also have a workable driver (flexibility is a driving design principle for v2)

4. The session based nature of drivers would cause issues in a multi-user or multi-tenant environment

5. Although CQL fits most of our use cases it doesn't quite cover everything

So, yes performance was a factor in choosing gRPC but there was also the flexibility it gave us while being able to reuse CQL thus avoiding reinventing the wheel.

Thanks! The team put a lot of work into writing this and exploring many different options before arriving at the proposed architecture.

Initially we'll be using unary calls but I can see use cases where streaming would be useful. One might be for keeping a schema representation in sync between the services and coordinator (for those services that need to be schema aware). Another potential could be future implementations of reactive APIs and subscription or push models. Although in the near term we can leverage streaming for performance improvements by allowing the service to begin performing transformations before the entire response has been received.

Hi! I helped build this, AMA!

Thanks!

The reason for Cassandra is the normal reasons someone would turn to Cassandra, fault tolerance, scalability, high write throughput. It's a powerful database we really like but can get a bad rap at times so with Stargate we wanted to make it easier for developers to get their data in and out with their preferred interface. Although we have left it open to extension so if Cassandra isn't your cup of tea we welcome PRs to add new persistence backends.

Example docker-compose and helm charts are definitely in the works! Stay tuned and we should have those out soon.

Oh that looks cool! I'm digging the UI. Thanks for sharing, I'll have to try that out later and maybe we can learn some things from each other.