Sessions

The problem

Click the counter button from the last lesson. Now open a new tab and visit the same page. Your count is gone. HTTP is stateless — every request is a stranger. The server doesn't know that the person who clicked 5 times is the same person loading the page now.

This is by design. HTTP was built for documents, not applications. But you're building an application. You need the server to remember who someone is across requests.

Sessions: name badges for the web

Think of a store where customers wear masks — the clerk can't tell them apart. Sessions work like name badges:

1. First visit: the server hands the browser a name badge (a cookie containing a session ID)
2. Next visit: the browser wears the badge. The server reads the ID and opens a personal file folder with that visitor's data
3. The badge is just an ID — the actual data stays on the server, safe from tampering

Sessions in traditional PHP

session_start();
$_SESSION['name'] = 'Alice';
echo $_SESSION['name']; // "Alice" — even across page loads

session_start() reads the session cookie, loads the session file, and populates $_SESSION. At the end of the request, PHP writes $_SESSION back to disk. The data persists.

The ZealPHP twist: coroutines

In traditional PHP, each request runs in its own process. $_SESSION is safe because no two requests share the same process at the same time.

ZealPHP is different. One worker process handles many requests simultaneously using coroutines. If two users make requests at the same time, they run in the same process. If both wrote to $_SESSION, their data would leak between requests.

// ZealPHP coroutine mode — the right way
$g = \ZealPHP\G::instance();
$g->session['name'] = 'Alice';
echo $g->session['name']; // "Alice" — per-coroutine, safe

The API is almost identical. $g->session behaves like $_SESSION, but it's scoped to the current coroutine. When the request ends, the framework writes it to a session file (just like PHP does), and the next request with the same cookie picks it up.

Putting it together

Here's how the counter from Lesson 5 persists across requests — it stores the count in the session:

// The counter endpoint (route/learn.php)
$app->route('/api/learn/demo/incr', function ($request, $response) {
    session_start();
    $g = G::instance();
    $g->session['demo_counter'] = ($g->session['demo_counter'] ?? 0) + 1;
    return App::renderToString('/components/_counter_button', [
        'n' => $g->session['demo_counter'],
    ]);
});

The counter now survives page reloads, tab closures, and even server restarts (because the session is written to disk).