Overview

6.0-SNAPSHOT 5.5 5.4 5.3 5.2 5.1 5.0

Hazelcast clients and programming language APIs allow you to extend the benefits of operational in-memory computing to applications in these languages.

This topic explains how we use these terms and discusses the pros and cons of using clients or APIs.

Not all features are available in every client. For an overview of what each client offers, see the clients page.

Use a Client or API?

Hazelcast provides clients and programming language APIs to interact with Hazelcast clusters and leverage their distributed computing capabilities. The choice between using a client or an API depends on your specific use case, performance requirements, and the programming languages you’re using in your project. The following examines the key differences and considerations.

Clients refer to the Hazelcast libraries used to connect to a Hazelcast cluster and exchange data. Clients use a binary protocol for communication with the cluster and encode the data in various formats such as Compact, JSON, etc. Clients are available in various programming languages. APIs, by comparison, are the interfaces with the Hazelcast platform. These do not require the use of specific libraries to connect and are generally text based — for example, the REST interface.

Clients

Hazelcast clients must be installed locally to communicate with the server.

Benefits of using Hazelcast clients

  • Language flexibility: Hazelcast offers clients in multiple programming languages, allowing you to use Hazelcast in various environments. Clients are available for Java, .NET, Python, C++, Go, and Node.js

  • Independent scaling: in client/server mode, you can scale the Hazelcast cluster independently from your application. For details, see: Choosing an Application Topology

  • Polyglot applications: client/server mode allows you to write polyglot applications that can all connect to the same cache cluster

  • Decoupling application from data: the application and cached data are separated, which can be beneficial for management and security purposes

Disadvantages

  • More complex setup: client/server mode requires setting up and managing a separate Hazelcast cluster, which can be more complex than embedding Hazelcast directly in your application

Maximum number of client connections per member

The maximum recommended number of clients per member is 100. By default, members have core count * 20 threads that handle all the requests. For example, if a member has 4 cores, it will have 80 threads available to handle requests.

Serialization in client/server mode

In client/server topologies, you can serialize your data on the client side before sending it to a member. For example, you can serialize data in Kryo and add it to a map. This option is useful if you plan on using Hazelcast to store your data in binary. The serialization can be handled on the client-side without the members needing to know how to do so.

For details about why you need to serialize data and the options for doing so, see Serialization.

APIs

If you do not want to use a client, you can use APIs to configure Hazelcast in embedded mode, where Hazelcast members run in the same Java process as your application.

APIs are server-side and do not require to be installed. Instead, you simply enable the API on the cluster, and this allows you to be serverless.

Benefits of using APIs

  • Lower latency: for data kept in the embedded member, embedded mode offers faster data access because applications do not need to send requests to the cache cluster over the network

  • Simplicity: for Java applications, embedded mode is simpler to set up and use, because you only need to add the Hazelcast JAR to your classpath

Disadvantages

  • Permissions (such as for IMap read/write) cannot be enforced so the embedded member has access to everything

  • Limited to Java: embedded mode is only available for Java applications, limiting its use in other programming environments

  • Coupled scaling: in embedded mode, the application and the cluster must be scaled together, which may not be ideal for all use cases

  • Less flexibility: each instance of your application starts a Hazelcast member, which may lead to unnecessary cluster members if you don’t need them. However, you can avoid this by creating a member only when necessary

Hazelcast offers a Near Cache feature for clients which can reduce latency in client/server mode by storing frequently used data in the client’s local memory.

Next steps

For detailed information and code samples for each client, see:

For details about using Memcache to communicate directly with a Hazelcast cluster, see Memcache. For information about using the REST API for simple operations, see: REST.

lifebuoy

Help and support