Issues with migrating to gRPC client.

[stuharper]

Hello

We are in the process of migrating to the gRPC client and have a couple of issues.

1) The documentation could be improved. For some areas of the migration we are just having to guess what to replace existing functionality with. For example, the Persistent subscriptions section of the documentation is still a TODO: https://developers.eventstore.com/clients/dotnet/5.0/migration-to-gRPC.html#persistent-subscriptions

Another example is GapMeasurement. The example included how to calculate the Gap but no code on how to integrate and use it. We did work this out and it took us some time, but the implementation should be in the documentation. https://developers.eventstore.com/clients/dotnet/5.0/migration-to-gRPC.html#knowing-when-live-processing-started

There are many more examples of this lack of documentation.

2) The new gRPC client is not testable. There is a limited use of interfaces. For example, the TCP client made use of IEventStoreConnection whereas the gRPC client uses EventStoreClient with no interface and Sealed. This makes the migration to the new client difficult to unit test and will require us to write lots of unneccesary code in order to test this. https://developers.eventstore.com/clients/dotnet/5.0/migration-to-gRPC.html#differences-in-connection-management

Thanks Stu

[alexeyzimarev]

The example included how to calculate the Gap but no code on how to integrate and use it.

Usage of the gap measurement heavily depends on a use case. For example, you can use it for a readiness probe or implement a gauge metric for it. Both cases would be handled differently, and we don't know what exactly is the use case you are implementing. In addition, we are still discussing if the live/catch-up mode signals should be available for gRPC subscriptions as well, and when (or if) if gets done, we'll update the docs.

Concerning testability, EventStoreClient is similar to HttpClient in this sense. The interface for IEventStoreConnection wasn't there for testability purposes.

[thefringeninja]

@stuharper,

Regarding 2),

Our recommendation is that generally, you don't write unit tests for EventStoreClient. Instead, define a business specific repository (e.g., ICustomerRepository) for each of your aggregates, and a single generic repository for each type of data storage (EventStoreRepository<T>, InMemoryTestRepository<T>). Then, implement ICustomerRepository for each type of storage where the implementation wraps the generic repository. Use the InMemoryTestRepository<T> for tests. This way you only need to write one set of integration tests using a docker container for the generic EventStore implementation.

For an example, please see the Transacto sample project.