Blink: a Swoole-backed PHP framework that keeps state between requests

The request lifecycle problem Blink attacks

Blink's stated reason for existing is resource allocation in the classic PHP deployment models. Under php-fpm or mod_php, everything a request creates, including objects and database connections, is destroyed when that request ends. For a small application that is fine. For a large one, the README puts it plainly: the performance impact of reallocating those resources on every request is huge.

Blink's answer is to stop the request from ending the process. Instead of one PHP process per request, a worker stays alive and handles request after request, so a connection pool, a compiled service container or a warm cache is built once and then reused. That is the entire mechanism, and it is why the project describes itself as both a micro web framework and an application server.

The audience follows from that. Blink is for teams running PHP at volume on infrastructure they control, where the operating system image can be modified and where an operator is comfortable supervising a long-running daemon instead of a pool of short-lived workers. It is a poor fit for shared hosting, and the README says as much by positioning the project as an alternative to php-fpm and mod_php rather than as a drop-in replacement for them.

Swoole does the networking, Blink does the framework

The two halves of the project are separated by dependency. The networking layer is the Swoole extension, a C-level PHP extension that provides the event loop, the worker processes and the socket handling. Blink does not implement an event loop of its own; it builds on top of Swoole, which means the extension has to be installed and enabled in the PHP runtime before anything Blink does will run.

Above that sits the framework layer, and this is where the README lists the design: dependency injection with a service locator, routing aimed at RESTful APIs, an authentication and authorization abstraction, a session management abstraction, middleware for requests and responses, a plugin system and PHPUnit integration for unit tests. The stated inspiration is Yii2 and Laravel, and the stated goal is an expressive API with a pleasant development experience rather than a novel programming model.

One line in the README deserves scepticism. It claims the framework can make a PHP application 100% faster in just a blink. Nothing in the documentation substantiates that figure with a benchmark, a workload or a before-and-after measurement, and a 100% improvement would mean the application is not the bottleneck at all. Treat it as a slogan. The mechanism behind the realistic gains is the one described above: fewer allocations, fewer connections opened, less garbage collected, and that is a property of the execution model rather than of the framework code.

Installing a Blink application from the seed project

Blink ships a skeleton project so that a new application arrives with the directory layout and configuration the framework expects. The README gives one command for it:

composer create-project --prefer-dist blink/seed your-app

The --prefer-dist flag tells Composer to take release archives rather than cloning from source, which is the faster and more reproducible option for a first run. After the command completes, your-app holds a Composer project with the Blink framework as a dependency and a structure you can start editing.

Documentation is published in two languages and for specific versions. The README links English and Simplified Chinese documentation for v0.4, hosted on the rethinkphp.com documentation site, and points readers of v0.3 to a separate tree for that release. That version split is worth noticing before you start: the branch you deploy decides which documentation applies, and mixing instructions across the two trees is an easy way to waste an afternoon.

The project also lists companion repositories under a related projects heading, including a Redis component, a Sentry integration and a notejam demo application. Those are separate packages rather than parts of the framework, but they show the intended extension shape, which is a component that plugs into the framework rather than a service the framework talks to over the network.

Static analysis and tests through the Makefile

The repository includes a Makefile that wraps the two checks a PHP project needs to stay honest, and it is worth reading because it shows the expected local workflow. Both commands call binaries inside vendor, so a Composer install has to have run before either target will work.

target?=src tests

phpstan:
	vendor/bin/phpstan analyse --memory-limit=512M --level 5 $(target)

lint: phpstan

unittest:
	vendor/bin/phpunit tests $(params)

test: unittest

The default target variable is src tests, so make phpstan analyses the source directory and the tests directory together at level 5 with a 512 megabyte memory limit. The lint target is an alias for the same run, and the test target depends on unittest, which runs PHPUnit against the tests directory with any extra parameters passed through the params variable. That indirection is a small convenience: you can add a filter without editing the file.

The corresponding configuration lives in phpstan.neon.dist, which is where the level 5 rules and any paths are set, and in phpunit.xml for the test suite definition. Because the config file is named with a .dist suffix, it is meant to be copied and edited locally rather than committed, which is the usual convention when a project expects contributors to vary the analysis strictness.

What Blink asks of your infrastructure

There are two requirements that a team should price in before choosing this framework, and neither is about PHP syntax.

The first is the Swoole extension. It is a compiled extension with its own build and lifecycle, and it has to match the PHP version in use. That rules out a large class of hosting where you cannot install extensions, and it means your deployment story now includes an extension that can differ between machines. The second is that the application server is a long-running process, which brings supervision, graceful restarts and memory growth into your operational picture in a way that a php-fpm pool never did.

The second requirement has a design consequence worth spelling out. In a process that survives requests, any state you leave on an object, in a static field or in a global is still there on the next request. Code written for php-fpm, where everything is rebuilt per request, can quietly leak memory or leak one user's data into another user's response once it runs under Blink. Migrating an existing application means auditing shared state, not just swapping the framework calls.

The alternative approach is to keep the classic process model and use a Yii2 or Laravel style application on php-fpm, which gives you the familiar API without Swoole and without the operational overhead. The difference is exactly the resource reuse Blink was built for: you give up per-request cleanup, and in exchange you stop paying to rebuild objects and connections on every hit.

Release history, branch layout and licence

The release tags and the repository activity tell two different stories, and any adoption decision should weigh the first more heavily than the second. The tagged releases are v0.4.1 on 2019-07-28, v0.4.0 on 2018-06-23 and v0.3.2 on 2018-04-06, and the README links its latest stable version badge to Packagist rather than to a release list on GitHub. Against that, the last push to the repository was on 2026-09-09, and the README states that Blink is still in active development and welcomes participation.

The branch layout adds a wrinkle. The default branch is v1, while the README's build badge points at a master branch, and the documentation site publishes separate trees for v0.3 and v0.4. A reader looking for the current work has to work out which branch is which, and a user installing from Packagist gets the tagged v0.4 line rather than whatever is on the default branch. That gap between the two is the real risk: an active repository with no release since 2019 can change behaviour without a version bump that your composer.lock would catch.

Licensing is the cleanest part. The framework is released under the MIT licence, with a LICENSE file at the repository root and the README repeating the same terms. MIT is permissive, with no copyleft obligations and no requirement to publish changes you make to the framework itself. That matters here because Blink is designed to be modified: the plugin system and the service container are there for you to extend, and MIT leaves you free to do that in a proprietary codebase.

Editorial conclusion

Adopt Blink if you already run PHP on a machine where you can install the Swoole extension, you have traffic high enough that per-request resource allocation shows up in your profiles, and you want a Yii2-style or Laravel-style API on top of it. Do not adopt it for shared hosting, for a small internal tool, or on the assumption that a framework with a 2019 tag is a safe long-term dependency. Verify first that the Swoole extension is available on your target runtime, read the version documentation that matches the branch you deploy, since the site publishes separate v0.3 and v0.4 trees, and check the composer.json requirements of the blink/seed project against your PHP version before creating the project.

Frequently asked questions

Official sources

1. bixuehujin/blink on GitHub
2. License: MIT
3. Project website
4. README
5. Releases