Comet: a PHP framework assembled from Slim, Guzzle and Workerman

The framework is a composition, not a from-scratch design

Comet's central idea is visible in the README's own framing. It combines the capabilities of Slim PHP, Guzzle and Workerman, and the topics attached to the repository name those three explicitly, alongside psr-7, rest-api and http-server.

Each piece has a distinct job. Slim is described as a micro-framework for writing web applications and APIs on modern PSR standards, and the README states that Comet allows you to use all the classes and methods of the Slim framework natively, with a link to the Slim v4 documentation. Guzzle supplies the HTTP/1.1 and HTTP/2 client components. Workerman is the asynchronous, event-driven framework underneath the server, which is the part that determines how connections are handled rather than how routes are matched.

So a request path in Comet is roughly: Workerman accepts the connection, the request is turned into a PSR-7 request object, Slim's router dispatches it, and the returned PSR-7 response is written back. Comet's own contributions sit on top of that, namely the embedded web server for static files, its own HTTP client, the session abstraction, and the validation integration.

The library also states that it is PSR compliant with native implementations of all the PSR-7 interfaces plus a PHP sessions abstraction, which means you are not forced to bring your own PSR-7 objects.

The performance numbers are the project's own claims

The README makes a throughput claim of 100K HTTP requests per second with roughly 0.1 ms latency on commodity cloud hardware, and describes Comet v2 as up to 20 to 30 percent faster than the first version. The response is to state plainly what these numbers are: they are the maintainer's claims, presented in charts in the `docs/` directory, and the README itself points to a separate benchmark repository at https://github.com/gotzmann/benchmarks so that readers can reproduce them.

The methodology described in the captions is worth noting before you accept the comparison. The charts compare "stripped versions of frameworks with no ORM under 1,000 concurrent connections", and the latency chart covers "minimal versions of popular PHP frameworks under series of serial web requests". So the comparison is between minimal skeletons, not between full applications, which is the only fair way to compare frameworks but also means the numbers say nothing about your own code.

The architectural argument behind the numbers is the interesting part and it does not depend on the charts. A traditional PHP deployment runs the application inside a process that is recreated for each request under many configurations, and the event-driven server keeps worker processes alive with the application already loaded. That is where the sub-millisecond response claim comes from.

One structural detail in the container image corroborates the direction. The Dockerfile installs the libevent extension, with a comment describing it as a way to speed up the framework, which is consistent with an event loop rather than a per-request model.

A first Comet app is one file and one command

Installation is a single Composer requirement, and the README states that Comet requires PHP 7.2 or newer:

$ composer require gotzmann/comet

The application itself is deliberately small. The README asks for a single `app.php` in the project root that autoloads, constructs the application, registers a route and starts the server:

<?php
require_once __DIR__ . '/vendor/autoload.php';

$app = new Comet\Comet();

$app->get('/hello', 
    function ($request, $response) {              
        return $response
            ->with("Hello, Comet!");
});

$app->run();

Starting it is another command:

$ php app.php start

After that, opening http://localhost shows the response. The default address is the one the README names, so there is no port to pick for the first run.

The route signature is the familiar one from Slim, with a request and a response handed to the callback and the response returned, so an existing Slim application is close to portable. The `with` method on the response is how a payload is attached, and the returned object is what gets written to the client.

Host, port and JSON responses come from the constructor options

The next example changes two things at once, the listen address and the payload format. The application is constructed with an options array carrying `host` and `port`, and the route attaches an array instead of a string, which the README describes as a JSON payload:

<?php
require_once __DIR__ . '/vendor/autoload.php';

$app = new Comet\Comet([
    'host' => '127.0.0.1',
    'port' => 8080,
]);

$app->get('/json', 
    function ($request, $response) {        
        $data = [ "message" => "Hello, Comet!" ];
        return $response
            ->with($data);
});

$app->run();

The README then says to start the browser or Postman and see the JSON response from `GET http://127.0.0.1:8080`. Note that the route in this example is registered as `/json`, so the path actually requested includes that segment, and the README's address line is abbreviated on that point.

For an application that needs to return a specific status code, the validation section shows the same response object used with a second argument, where errors are returned with a 400 status. That is the pattern for anything other than a success payload.

Validation is Rakit Validation under a Comet namespace

Comet does not implement its own validation rules. The README states that the validation engine is based on the Rakit Validation library, and the entry point is imported into your own namespace with a single statement:

use Comet\Validator;

The usage pattern then follows Rakit's: define a rules array keyed by field name, define a messages array, call `validate` with the payload, and inspect the result. In the README's example the rules include `required`, `required|uuid` and `required|alpha_dash` checks, and a date rule whose format is chosen at runtime because the example notes that PHP before 7.3 does not support RFC3339_EXTENDED and would produce broken milliseconds. The errors are then returned through the response object with a 400 status.

That is the practical shape of the integration. Your validation rules and error messages are Rakit's, and Comet supplies the transport into the response, which keeps the number of concepts low.

The date handling in the example is a small warning sign about the project's age. The README still branches on PHP 7.2 versus 7.3 for a date format constant, while the current requirement is stated as PHP 7.2 or newer. The example code is documentation, not a compatibility promise, but it shows the framework's README was written against a PHP version range that has since moved on.

The container image builds a PHP 7.4 runtime with libevent

The Dockerfile is a complete development and runtime image in one file, and it is worth reading closely because it shows what the framework expects. It starts from `ubuntu:20.04` and takes the PHP version as a build argument defaulting to 7.4.

The installed pieces are a development toolchain (`software-properties-common`, `build-essential`, `git`, `unzip`), the pear and event headers needed to build extensions, and the PHP packages `php${PHP}-dev`, `php${PHP}-mbstring`, `php${PHP}-curl` and `php${PHP}-pgsql`, so PostgreSQL support is present in the image.

The libevent extension is installed by a `pecl install event` command driven by a printf-fed answer script, and enabled by writing an `event.ini` file into the CLI extension directory. The composer install step uses `--optimize-autoloader --classmap-authoritative --no-dev`, and the final command is `CMD php app.php start`.

Two observations. The image is Ubuntu 20.04 with PHP 7.4, which are versions that have reached the end of their upstream support, so this file describes a reproducible build rather than a current one. And the image is a development image in practice: it carries the build toolchain and the composer installer script in the same layer as the runtime, which is fine for local work and for CI, and is more than you would ship to production.

Where the documentation stops, and what fills the gap

Several parts of the README are cut off mid-topic, and the gaps are informative. The Controllers section begins with the instruction to create `src/Controllers/SimpleController` and then stops, so the controller base class, how it is bound to routes, and how it differs from closures are not documented in the text available.

The top level of the repository is consistent with that. There is no `tests/` directory, no `docs/` site configuration and no CI workflow, only `.gitignore`, `Dockerfile`, `LICENSE.md`, `README.md`, `composer.json`, `composer.lock`, `docs/` and `src/`. There is a `composer.lock`, so a reproducible dependency set is pinned for the project itself.

The authorization story is a separate repository by design. The README points to Comet\Auth at https://github.com/gotzmann/auth for user registration, email checking, password management and role-based access, and asks you to refer to that library's own documentation. So the authentication surface is a companion package rather than part of the framework, which keeps the core small but means the two versions have to move together.

On the version question, the README describes what is new in Comet v2, including the embedded secure web server, extended session support and the auth integration, and the autoload example still asks for `gotzmann/comet` at `^1.0`. The repository has no GitHub releases attached, so the tag history in the repository is where the version list has to come from, and the last push was on 2026-06-30.

Editorial conclusion

Use Comet when you want PSR-style routing and a PSR-7 response object on PHP 7.2 or newer and you value the event-driven server over the maturity of a larger ecosystem. Do not adopt it if you need a broad body of third-party integration, documented upgrade paths, or published release history, since the repository has no GitHub releases and the last push was on 2026-06-30. Verify first that the Composer package you pull matches the version of the API you are coding against, because the README describes a v2 with new session and web server features while the autoload example still requires gotzmann/comet at ^1.0.

Frequently asked questions

Official sources

1. gotzmann/comet on GitHub
2. Issues
3. License: MIT
4. README