Extract CassandraSession and related classes to a separate library

[TimMoore]

@WadeWaldron suggested that CassandraSession would be useful in Akka/Lagom services that don't use Akka Persistence. For example, something that consumes events from a Kafka topic and updates a Cassandra table. It offers a better, more consistent API than using the underlying DataStax Java driver directly.

This would require adding a new "session" module, and moving classes to it that don't depend on any Akka Persistence APIs.

[patriknw]

I agree that CassandraSession would be useful standalone, and that’s why it’s public api in Lagom.

Perhaps it could live in Alpakka Cassandra connector (merging with what is already there)?

[TimMoore]

Would that mean that Akka Persistence Cassandra would depend on the Alpakka Cassandra connector, or that there would be two separate CassandraSessions?

I think we'd want to retain the SessionProvider as well to make use of automatic service discovery (which we should port from Lagom and base on Akka Service Discovery).

[patriknw]

It would be ok to depend on Alpakka Cassandra here, but that would require that there is no performance loss or other drawbacks in the Alpakka implementation.

[WadeWaldron]

Let me explain what I am looking for here, if that helps.

When I am working with Lagom Read Models, I have access to a Cassandra Session. However, sometimes I want to access a Cassandra Session outside of a read model (eg. consuming from a Kafka topic). In that case I want to be able to use the same Cassandra Session. I want to avoid having to switch between different implementations. I want one implementation everywhere.

However, I don't want that implementation to require me to implement Akka Cluster features or Lagom Persistent Entity features. Cassandra shouldn't require those things. Right now that isn't possible.

I guess at the end of the day what I want is a fairly minimal CassandraSession that provides me with things like non-blocking APIs, simple configuration etc, and can be used consistently across our products.

[patriknw]

It's clear, I agree.

[TimMoore]

@ennru and @2m could you comment on whether you think this should be merged into the Alpakka Cassandra connector?

It makes some sense, because it implements queries using a custom graph stage. On the other hand, it also offers non-streaming convenience APIs for queries and updates that are also very commonly used, so that makes me think that Alpakka might not be appropriate.

[chbatey]

Put this at the bottom of the Todo list as not to complicate the dev process until we're sure it won't change

[patriknw]

On the other hand I think @ennru might be eager to use this in Alpakka for building other things for the Cassandra connector there.

[ennru]

We can start working on it in this repository so that it doesn't disturb the development of APC* things, but get's closer to what we want to offer in Alpakka.
We intend to release Alpakka 2.0 soonish and want to pull this in before.

[patriknw]

sounds good

[ennru]

Fixed with #736