# State
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.
TIP
🧔🏾 Is all about loading only what you need at runtime and to have states that we can re-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
# Conventions
The following conventions applies:
- must exists isolated in its own unique folder at
states/
- must provide a
load.php
file (loads the state) - must provide a
make.php
file (makes the state)
The example belows shows hows a ./states
tree looks like. Both web
and api
are application states.
./states
├── web
│ ├── cache/
│ ├── load.php
│ ├── make.php
└── api
├── named-cache/
├── load.php
└── make.php
# Learn By Example
The example at 03.Http/00.router-make.php creates an state at 03.Http/cache, which is used by all the other examples in that scope.
🧔🏾 The same state is used to showcase HTTP resolving, Swoole and RoadRunner examples