An application state refers to an application with all the config, variables, objects and so forth previously stored.
Chevere is designed to provide systems that will load an already made application state and performs n tasks under this context. The application state is made to be re-used, allowing to re-run (or loop) the application without the expensive bootstrapping required to build the state from scratch.
# States in Chevere
Conventional PHP applications usually rely in just one big application state. For example, an
index.php entry point serving under an HTTP web server all the incoming requests.
In Chevere we do the opposite, building many different application entry points for n application states where each state is optimized for it single given task.
🧔🏾 You see, it's all about loading only what you need at runtime and to have states that we can run in the event loop.
Thanks to this, a Chevere application may have one state for public HTTP traffic, another state for background processing, another for logged users, etc. Each state is built around the same business, it just changes how it will be used and where it will run.
# Working with States
The following conventions applies:
- must exists isolated in its own unique folder at
- must provide a
load.phpfile (loads the state)
- must provide a
make.phpfile (makes the state)
The example belows shows hows a
./states tree looks like. Both
api are application states.
./states ├── web │ ├── cache/ │ ├── load.php │ ├── make.php └── api ├── named-cache/ ├── load.php └── make.php
# Learn By Example
🧔🏾 The exact same state is used to showcase HTTP resolving, Swoole and RoadRunner examples