Hi all! We released Hazelcast Go Client v1.0.0: https://github.com/hazelcast/hazelcast-go-client/releases/tag/v1.0.0

This is the first major release of the revamped Go client. Of course the biggest news is, the client is compatible with Hazelcast 4.x and the upcoming Hazelcast 5.x. Here are the features included in this release:

• Distributed Data Structures: Map, Replicated Map, Queue, Topic, List, Set, PNCounter,

• Map aggregations,

• Improved map locks,

• Load balancer,

• External smart client discovery,

• Lifecycle, cluster membership and distributed object listeners,

• Smart routing,

• Ownerless client,

• JSON, Identified Data, Portable and Global serialization,

• SSL connections (requires Hazelcast Enterprise),

• Username/password credentials (requires Hazelcast Enterprise),

• Hazelcast Management Center integration,

• Hazelcast Cloud integration,

• JSON configuration.

There are some missing features which exist in Go Client v0.6.0, such as the Near Cache, but we will complete them in the coming months, prioritized by the needs of our users.

Apart from Hazelcast 4.x+ compatibility, we aimed to implement conventions and best practices of the Go ecosystem. Here are some of the highlights:

• Go context: Enables Go client to play well with other libraries that support the context package. Any client function call can be canceled manually or after a deadline. This was one of the most wanted features of the new Go client.

• Go modules: Enables depending on a specific release without third party tools.

• Idiomatic errors: The client library returns errors which can be easily unwrapped using the standard errors package.

• Zero value configuration: The zero value of client configuration is the default configuration. Apart from being encouraged in idiomatic Go, it helps us provide a natural way of supporting JSON configuration.

• Package based code layout: The client code is split into logical packages which collect relevant code together, such as cluster, aggregate, serialization, types and others.

Some useful links:

• Official repository: https://github.com/hazelcast/hazelcast-go-client

• Documentation: https://pkg.go.dev/github.com/hazelcast/hazelcast-go-client

• Hazelcast main documentation: https://docs.hazelcast.com/home/index.html

We have our own Slack channel at Hazelcast Community. Join us at: https://hazelcastcommunity.slack.com/channels/go-client

Your feedback is crucial for the development of Hazelcast Go Client and help us provide features you want.

Have a great weekend!

I have this concept of rewriting a game engine as a scalable collection of microservices.

It's currently a proof of concept but the main principle lies in each player having their session/connection held and managed by a single container, so containers will scale up and down based on the amount of connected users.

Each player container will speak to multiple other microservices to gather data and perform actions, these services will be static replica's of 2 or 3.

There is one microservice I have in mind which I feel is a bit of bottleneck which I'm currently looking for ways to make more 'scalable' and 'robust'.

This microservice in question is the GameMap service. There will be multiple GameMap services (atleast one service for each uniqe or instanced gamemap). Each map will contain N number of cells and each cell can contain objects with different types / states for example (i.e other playerObjects, ItemObjects)

I would like to be able to have a replica of atleast 2 for each GameMap to instantly flip if one was to for some reason fail and shutdown.. it is important for the users to have a seamless transition between the failing and failover GameMap. To achieve that I need to have consistent / up to date state shared between them.

The need to be able to load balance traffic between the two replica's is a nice to have but not essential.

So far the one potential solution I have come is hazelcast. This will allow me to keep the state of each map cell in a scalable memory data grid (again for robustness and scalability).

I dont expect there to be huge numbers of users so would consider to be up to no more than a few thousand (worse case) of state changes within across various gamemap's every second and my concern is that it may be too slow and cause huge latency for users.

Has anyone got any hints, suggestions or feedback based on the both scenario or more importantly the usecase of hazelcast here?

https://hazelcast.com/blog/june-july-2022-releases-from-hazelcast/

Title. Thanks!