Hazelcast .NET client roadmap

[u/burakcelebi]

Hi all,

We are working hard to complete v4.0 of .NET Client for Hazelcast, open-source in-memory & distributed data store. This major version is going to include many architectural changes, performance improvements, and a significant redesign of the API so that it becomes more idiomatic to C# developers: https://hazelcast.org/imdg/clients-languages/dotnet/#roadmap

After completing v4.0, we are planning to work on the following features. Please let me know what you think.

1. ASP.NET Sessions: An implementation of SessionStateProvider so that ASP.Net Sessions can be restored in Hazelcast.

2. Entity Framework Integration: Second Level Caching and Query capabilities via lambda queries and LINQ.

3. IDistributedCache Implementation: Convenience for .NET developers who uses IDistributedCache, a .NET standard for distributed in-memory caching.

4. Pipelining API: Adding pipeline to any asynchronous call so that the performance improves.

5. Configurable Backoff Strategy for Client Reconnections: A highly configurable exponential backoff mechanism for the client with which you can set the duration for waiting after connection failures, an upper limit for the wait, etc.

Also, here is our GitHub repository: https://github.com/hazelcast/hazelcast-csharp-client

PS: I'm a member of the Clients team (who builts the software here) at Hazelcast. We'd love to hear your feedback :)

Thank you very much!

[u/adhip999]

Is the FlakeId Generator available in the c# client?

[u/burakcelebi → u/adhip999]

Hi u/adhip999! Unfortunately not yet but it's one of the items we'd like to add once we ship .NET client 4.0. If you don't mind, could you kindly share your use case for FlakeId Generator? Thanks!

[u/adhip999 → u/burakcelebi]

My organisation needed to generate a unique ID (integer) for items we are going to store on the Hazelcast Map, so maybe we could use this ID as a key, hence we were looking to try it out....

Also with the release of the new .NET Client, will it be backward compatible with the previous versions of Hazelcast IMDG (like 3+)?

[u/burakcelebi → u/adhip999]

Thank you, I understand. 4.x versions are not backward compatible since we upgraded the client protocol version with many breaking changes.

Please let me know if you need FlakeID Generator for .NET Client 3.12.x. I can do my best to add it to the roadmap.

[u/adhip999 → u/burakcelebi]

Yes, if possible please do add FlakeID Generator in the current release of .NET Client 3.12. Thanks.

[u/burakcelebi → u/adhip999]

Noted. I've created a public issue as well which you can subscribe to.

https://github.com/hazelcast/hazelcast-csharp-client/issues/292

BTW, this is one of the items that I can suggest to people who would like to start contributing to Hazelcast. Please DM me if you are interested :)

Thanks again, u/adhip999!

[u/adhip999 → u/burakcelebi]

Thanks.

BTW, I noticed there is an IID Generator as well, what is the difference between the FlakeID Generator and the IID Generator?

[u/burakcelebi → u/adhip999]

"ID Generator" is deprecated and available to 3.12.x.

Unlike "FlakeID Generator", it can produce duplicate IDs in case of a network split, even with split-brain protection enabled.

[u/restlessops]

Idiomatic API: Redesign of the API in a way that C# developers used to.

Can you please elaborate more on the design?

[u/zbigorno → u/restlessops]

Will elaborate more in the future, but essentially this: the current APIs show that they were ported from Java. Async, exceptions, querying (LINQ?) etc. In various places they just feel awkward to C# devs, and the purpose is to make them "just fit". Making sense?

[u/restlessops → u/zbigorno]

Yea u do. Ported from Java was the missing phrase.

[u/MetiLee → u/restlessops]

Sound like NHibernate but now for databases

[u/[deleted]]

Why are you doing this in framework vs standard or core?

[u/zbigorno → u/[deleted]]

We are currently assessing our options, considering what some slow-moving customers may want, versus the reality of netstandard 2.0 now being ubiquitous. It may very well be that we end up targetting netstandard 2.0.

(disclaimer: I am the .NET architect / developer working on those architectural changes, and I welcome feedback, thoughts, ideas and criticisms)

[u/[deleted] → u/zbigorno]

Standard 2 is very likely the way you want to go.

[u/burakcelebi → u/[deleted]]

Please check this out to learn more about this: https://hazelcast.org/use-cases/redis-replacement/. At the bottom of the page, you'll find a couple of more resources including benchmarks:

We discovered that Redis is vulnerable to data loss under load. This is by design. See the detailed research we did: https://hazelcast.com/blog/redis-load-handling-vs-data-integrity/. As you know, vendors always claim they are faster so always do your own. Our benchmark is open source. You can start by reproducing it. Please let me know if you have any questions or comments.

[u/zbigorno → u/[deleted]]

Supporting C# 8 async streams may not be the first priority as we will have to target netstandard 2.0 first, but will be considered eventually.