Download the PHP package rkistaps/the-app without Composer

TheApp

TheApp is a small PHP micro-framework for two jobs:

• Web: it routes PSR-7 requests through PSR-15 middleware to your request handlers.
• Console: it maps command-line arguments to command handlers.

It's built on PHP-DI, so handlers, middleware and commands are resolved from the container with their dependencies autowired. It doesn't include a PSR-7 implementation, so you can use any one. The examples below use nyholm/psr7, and Acme\ stands for your own project's namespace. Classes in TheApp\ come from this package.

• Requirements
• Installation
• Web application
  • Routes
  • Front controller
  • Route paths
  • Generating URLs
  • Middleware
  • Error handling
  • Building responses
• Console application
  • Output
  • Exit codes and errors
• Versioning and support
• Development
• License

Requirements

• PHP 8.3 or later
• For web applications, a PSR-7 and PSR-17 implementation, such as nyholm/psr7. Both psr/http-message 1.x and 2.x are supported.

Installation

For web applications, also install a PSR-7 implementation and a way to build the request from PHP globals:

Web application

TheApp doesn't expect any particular files or directories. It needs a PHP-DI container, your route definitions, and an entry point that runs the app.

1. Routes

Routes are registered by router configurators, which are classes implementing RouterConfiguratorInterface. You pass them to the app in the front controller.

A route handler is either a class name or a callable:

• Class name: the class must implement PSR-15 RequestHandlerInterface. It's fetched from the container, so its constructor dependencies are injected.
• Callable: it receives the request as its first argument. Any other type-hinted parameters are resolved from the container.

The router has a method for each HTTP method: get(), post(), put(), patch(), delete() and options(). get() routes also answer HEAD requests. any() matches every method, and map() takes a list, as in $router->map(['GET', 'POST'], '/search', SearchHandler::class). Routes are checked in the order they were registered, and the first match wins.

2. Front controller

AppFactory::web() and AppFactory::console() take an optional PHP-DI container. Without one, they build a default container, which is enough when your handlers need no container definitions. TheApp uses PHP-DI to autowire handlers and to call callables with their dependencies, so the container must be a DI\Container.

How the setup methods behave:

• Arguments: withRouterConfigurators(), withMiddleware() and withErrorHandler() accept class names, which are resolved from the container, or ready-made instances. withMiddleware() also accepts callables.
• Immutable: each returns a new app and leaves the original unchanged.
• Type checks: a class that doesn't implement the expected interface throws TheApp\Exceptions\InvalidConfigException.
• Lists in a file: a long list of configurators can live in a file of your choice that returns an array of class names, such as ->withRouterConfigurators(require __DIR__ . '/routes.php').

Build the container however and wherever suits your project. For bigger apps that usually means a separate file of definitions.

Point your web server at the front controller for every request that isn't a real file. To try it locally, run php -S localhost:8080 index.php.

Route paths

Paths are matched while still URL-encoded, so an encoded / (%2F) never ends a segment. Parameter values reach the handler decoded: /pages/J%C4%81nis gives name the value Jānis.

To put routes under a common prefix, register them in a group. group() passes your callback a router that adds the prefix, and returns the group, so you can add middleware to all of its routes at once (see Middleware). Groups can be nested: prefixes add up. The prefix is added to normal paths but not to * or @ paths.

For a prefix without a group, withBasePath() returns a router that adds the prefix and registers into the same route list, as in $router->withBasePath('/api')->get('/users', UserListHandler::class).

Generating URLs

Give a route a name as the last argument, then build its path with Router::url(). Names are unique: registering a second route with the same name throws InvalidConfigException. The router is available to handlers and middleware as the Router::class request attribute.

Values are URL-encoded, and optional parameters you leave out are dropped. url() throws InvalidArgumentException in these cases:

• no route has that name
• a required parameter is missing
• a value doesn't fit its parameter type (for example, abc for [i:id])
• the route's path is * or an @ regex

Middleware

Middleware can be added at three levels:

• App: WebApp::withMiddleware([...]) runs on every request, before routing, so also for requests no route matches. Use it for CORS, sessions, security headers or request logging.
• Group: addMiddleware() on the group that Router::group() returns runs for every route in the group, including routes registered before the call.
• Route: addMiddleware() on a route runs for that route only.

A request goes through them from the outside in: the app's middleware, then the groups' from the outermost in, then the route's, each in the order it was added. Like handlers, a middleware can be given in three ways:

• Class name: the class must implement PSR-15 MiddlewareInterface and is resolved from the container. Any other class throws InvalidConfigException.
• Instance: a ready-made MiddlewareInterface object.
• Callable: it receives the request and the next handler.

When an error handler is set, a route's exception, or a 404 or 405, becomes the error handler's response inside the app's middleware. So app middleware gets that response and can add headers to it too, such as CORS headers on an error. An exception from the app's middleware itself goes to the error handler as well. Without an error handler, exceptions pass through the app's middleware and are rethrown from run().

Error handling

WebApp::run() catches every exception, including TheApp\Exceptions\NoRouteMatchException when no route matches. It passes the exception and the request to the handler set with withErrorHandler(), as shown in the front controller. Without one, the exception is rethrown from run(). TheApp doesn't register any global error or exception handlers.

The request lets the error response depend on it, for example JSON for API paths or for clients that send Accept: application/json. Once a route has matched, the request also has the route parameters.

When a route matches the path but not the HTTP method, the router throws MethodNotAllowedException. It extends NoRouteMatchException, so check for it first, as above. Error handlers that don't check for it keep returning 404.

For a debug page during development, install Whoops with composer require --dev filp/whoops. Then register it in the front controller only in development, and skip withErrorHandler() so exceptions reach it:

Building responses

ResponseBuilder is a fluent wrapper around a PSR-7 response. It needs a ResponseFactoryInterface in the container. Create it with make() so each response starts from a fresh builder. The builder is mutable, and get() would return a shared instance.

Console application

Commands are registered by command configurators, which are classes implementing CommandConfiguratorInterface. As on the web side, TheApp needs no container definitions of its own.

A command handler is either a callable or a class name:

• Callable: command-line options are matched to its parameters by name and converted to the parameter's type. Parameters not passed on the command line use their default value, or are resolved from the container if they have a class type. It can return an int exit code; any other return value, or none, counts as 0.
• Class name: the class must implement CommandHandlerInterface, and its handle() method receives all options as an array of strings and returns the exit code. A flag without a value is true.

The entry point passes the configurators and $argv to the console app:

withCommandConfigurators() works like withRouterConfigurators(). It takes class names or instances, returns a new app, and accepts an array loaded from a file, such as require __DIR__ . '/commands.php'. Command names are unique: adding a second command with the same name throws InvalidConfigException.

Pass the command name first, then options as --name=value, or --name alone for a flag:

--command=user/greet also works in place of the first argument.

For callable commands, option values are converted to the parameter's type:

Output

Commands write through OutputInterface: write() and writeln() to standard output, and error() to standard error. Errors on standard error stay out of the command's real output when it's piped or redirected, as in php console.php user/export > users.csv. A command gets the output from the container: a command class as a constructor parameter, a callable as a parameter, as in the examples above. echo keeps working, and writeln() and echo keep their order, because by default both go to the same channel.

By default the output is a StreamOutput to standard output and standard error. To use another, pass it to withOutput(), or define OutputInterface in your container. The console app sets the output it uses in the container as OutputInterface, so commands and the error handler get the same one.

In tests, a BufferedOutput keeps what a command wrote, with standard output and standard error apart:

Exit codes and errors

run() returns the command's exit code. It returns 1 when the command isn't found or its input is invalid, and writes a message such as Command not found, Missing required option --name or Option --times expects an integer to standard error.

Any other exception from a command goes to the handler set with withErrorHandler(), which reports it and returns the exit code. Without one, the exception is rethrown from run(), and PHP prints it and exits with code 255.

Versioning and support

TheApp follows semantic versioning. Minor and patch releases don't break the public API; breaking changes come only in a new major version, with upgrade notes in the changelog. The public API is every class, interface and method in TheApp\ except those marked @internal. Internal classes, such as RouteRepository, MiddlewareStack and the Callable* adapters, can change in any release.

Require TheApp as ^1.0 to get every 1.x release.

Supported versions:

• PHP: 8.3, 8.4 and 8.5. Support for a PHP version is dropped only in a major release, and only once that PHP version no longer receives security fixes.
• TheApp: the latest 1.x release receives bug and security fixes. The 0.x releases don't.

To report a security vulnerability, see SECURITY.md.

Development

PHP runs in Docker, so you only need Docker and a Bash shell (such as Git Bash on Windows).

License

TheApp is released under the MIT License. You can use it for any purpose, including commercial projects, as long as you keep the copyright notice.