Before we get into comparing Aphiria against other frameworks, remember that each framework is just a tool. Some tools are better suited to some problems than others. This sort of comparison is inherently subjective, although we will do our best to keep things objective. If you feel we've misconstrued or missed anything, please feel free to submit an issue or pull request to the documentation to improve it.
Before we get into library comparisons, let's compare the frameworks at a high level.
- Expressive syntax for building REST APIs
- Unopinionated, ie it doesn't prescribe how to do something - it places that completely in the developers' hands (akin to an Android phone)
- Favors code-based configuration over magic string-based configuration
- Can easily convert to-and-from PSRs
- Thorough, searchable documentation
- Little community support
- Does not natively use some PSRs
- No built-in support for background processing of data
- An established history and huge community support
- Lots of functionality baked into the framework, eg eventing
- Some of its libraries are the back-bone of other very popular libraries and frameworks
- Configuration is usually string-based
- Perceived by some to be difficult to get up and running with
- The documentation is difficult to navigate through
- Lots of community support and tutorials
- Arguably one of the easiest frameworks to get up and running with
- Lots of functionality baked into the framework
- Thorough, searchable documentation
- Pretty opinionated, eg it works best if used as designed (akin to an iPhone)
- Some complain that there is too much "magic", eg unintuitive logic that powers some of its core libraries
Routing is how you map a URI to an action, frequently a controller method.
- Fluent syntax makes defining routes very simple
- Supports defining routes via attributes
- Supports custom constraints, which make it possible to do things like versioned endpoints
- Trie-based solution makes it one of the fastest routing libraries out there (~200% faster than FastRoute)
- Not tied to any library or framework
- Supports binding framework-agnostic middleware to routes
- Supports host, path, and header matching, which simplifies creating versioned endpoints
- Supports creating URIs from routes
- Does not support closure actions
- Supports defining routes via attributes
- Currently the fastest PHP routing library out there (barely edges out Aphiria)
- Supports host and path matching
- Supports URL generation
- Config-based route definitions are not easy to write without IDE plugins
- Middleware support is tightly coupled to Symfony HTTP and middleware libraries
- Does not support closure actions
- Intuitive syntax
- Supports URL generation
- Supports closure actions, although not when using route caching
- No support for custom constraints
- Route middleware are tightly coupled to Laravel's HTTP and middleware libraries
Controllers are the actions that are executed when a user hits a URI. They typically encapsulate all HTTP application logic, and transform it to and from the domain logic.
- Automatic content negotiation for request and response bodies
- Automatic validation of request bodies
- Automatic deserialization of route and query string parameters
- Expressive syntax that makes your controllers more intuitive to read and write
- Convenience methods for constructing various responses
- Works best with REST API requests/responses, not frontend endpoints
- Provides many baked-in convenience methods for constructing responses
- Automatic deserialization of route and query string parameters
- Works well for REST API and frontend endpoints
- No automatic content negotiation
- Has many functions that make it easy to construct responses
- Has built-in support for automatically creating controller methods for various HTTP methods
- Works well for REST API and frontend endpoints
- Only supports negotiating Eloquent models automatically, and does not support all standard means of content negotiation
PHP's abstractions around HTTP requests and responses are pretty bare bones. Most frameworks find it necessary to build out classes and helper to better construct and read from requests and responses.
- Clean abstractions of HTTP messages
- Helper classes to simplify common tasks with messages, eg setting cookies, determining if a request is JSON, constructing multi-part requests, etc
- Contains support for content negotiation and media type formatters
- Can convert to-and-from PSR-7
- Does not use PSR-7 natively
- Does not contain an HTTP client
- Contains an HTTP client to send and receive messages
- Can convert to-and-from PSR-7
- Requires additional libraries for handling things like reading and writing cookies easily
- Does not use PSR-7 natively
- Lots of convenience methods for common tasks
- Can convert to-and-from PSR-7 because it extends Symfony's HTTP library
- Not necessarily a con, but trades off proper abstractions for convenience
- Does not use PSR-7 natively
A dependency injection (DI) container lets a developer tell the application "When you need dependency IFoo, use this instance of IFoo". On top of that, many DI containers support auto-wiring, which is the process of reflecting a class constructor and resolving all the parameters recursively so that the container can automatically instantiate the class.
- Support for auto-wiring
- Supports binders for registering dependencies for modules
- Supports automatic lazy execution of binders so that binders that aren't used are not executed
- Straightforward methods to bind and resolve dependencies from the DI Container
- Supports targeted bindings
- Can convert to PSR-11
- Does not use PSR-11 natively
- Support for auto-wiring
- One of the fastest DI container libraries
- Although it supports code-based binding of services, it mostly relies on string-based configuration
- Must manually mark services as lazy
- Support for auto-wiring
- Supports service providers for registering dependencies for modules
- Supports targeted (contextual) bindings
- Supports PSR-11 natively
- Must manually mark service providers as deferred
A console library permits a user to enter a command via a console application and map that command to an action in the code base.
- Trivial to get up and running on its own
- Provides support for output formatting, eg padding/table/progress bar formatting
- Support for password masking
- Support for attribute-based commands
- Little community support
- Easy to get up and running on its own
- Provides support for output formatting, eg padding/table/progress bar formatting
- Supports password masking
- Powers other popular console libraries, even Laravel's
- No built-in support for command attributes
- Integration for background running of console commands
- Auto-completion for command input
- No built-in support for command attributes