Implementing GenServer Behavior

Welcome back! In the previous lesson, we learned about Erlang's OTP behaviors. One of the most important is the GenServer.

• A GenServer is a generic server that handles requests.
• It manages internal state and processes messages in a sequential manner.
• Think of it as a standardized way to build reliable, fault-tolerant server processes in Erlang.

It's the foundation for many Erlang applications.

To implement a GenServer, you define a module that exports specific callback functions. These functions are called by the gen_server behavior at different stages.

• init/1: Initializes the server's state.
• handle_call/3: Handles synchronous client requests (expects a reply).
• handle_cast/2: Handles asynchronous client requests (fire-and-forget).
• terminate/2: Cleans up when the server stops.
• code_change/3: Handles hot code upgrades.

We'll focus on init, handle_call, and handle_cast in this lesson.

Every GenServer starts by initializing its state. This is done in the init/1 callback function.

It takes one argument (typically a list of arguments passed during startup) and should return {ok, State}, where State is the initial data your GenServer will manage.

Here's a basic init function:

To get our GenServer running, we need to start it. The common way is using gen_server:start_link/3 or gen_server:start_link/4. We'll add a start_link/0 function to our module.

The start_link function creates a new Erlang process and links it to the calling process, making it part of a supervision tree (more on this later!).

When a client needs a reply from the server, it makes a synchronous call using gen_server:call/2 or gen_server:call/3.

The GenServer handles these requests in its handle_call/3 callback. This function takes three arguments:

• Request: The message from the client.
• From: The sender's process ID (Pid) and a tag.
• State: The current internal state of the GenServer.

It typically returns {reply, Reply, NewState}.

Let's add an increment function to our counter. This will be a synchronous call, meaning the client waits for the new count.

Try running this code. First, compile it (`c(my_counter).`), then start it (`my_counter:start_link().`). You can then call `my_counter:increment().` to see the counter increase.

Sometimes, a client doesn't need a reply and just wants to send a message without waiting. This is an asynchronous call using gen_server:cast/2.

The GenServer handles these messages in its handle_cast/2 callback. It takes two arguments:

• Message: The message from the client.
• State: The current internal state of the GenServer.

It always returns {noreply, NewState} because no reply is sent back to the client.

Let's add a reset function to our counter. This will be an asynchronous call, as the client doesn't need to know the new count immediately.

Compile and start the module as before. Call `my_counter:increment().` a few times, then `my_counter:reset().`. You'll notice `reset` returns immediately without a value.

The power of GenServers lies in how they manage state. The State argument is passed into each callback, and the callback returns a NewState.

• This ensures that only one process (the GenServer itself) ever modifies its state, preventing race conditions.
• It makes the server's internal logic easier to reason about.
• The state can be any Erlang term: an integer, a list, a map, a record, or a complex data structure.

This sequential processing of messages and explicit state passing is key to Erlang's concurrency model.

Which of the following statements about GenServer calls are TRUE?

You've successfully built your first GenServer! Here's what we covered:

• GenServers are standard OTP behaviors for building stateful servers.
• The init/1 callback initializes the server's state.
• gen_server:start_link creates the GenServer process.
• handle_call/3 handles synchronous requests (client waits for reply).
• handle_cast/2 handles asynchronous messages (client doesn't wait).
• GenServers manage their state by passing it between callbacks, ensuring sequential updates.

Next, we'll see how supervisors can automatically restart failed GenServers!