Hacker News Reader

Comment by kiafarhang | Hacker News Reader

Great read. As someone not very familiar with Stargate, is the internal communication via gRPC (e.g. from most services to bridge) totally new to v2? Or does Stargate v1 use gRPC internally as well?

If it is new, what drove the decision to use gRPC? Performance?

View on HN

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.

Reply on news.ycombinator.com