PHP is a powerful language, with a wide range of offerings that make utilizing it for anything from basic websites to complex APIs a very strong proposition. It’s got a wonderful low barrier of entry, a gigantic ecosystem of solutions, and a variety of framework implementations that can make it do almost whatever you dream.
That’s also somewhat of an issue — with so many people utilizing PHP, the issue is not “there aren’t enough frameworks,” but “there are too many frameworks.” Accordingly, sifting through the sea to find a few pearls is a good place to start when developing a REST API.
In this piece, we’re going to discuss five lightweight PHP frameworks for building REST APIs. We’ll discuss a bit of their history, highlight their pros and cons, and discuss some alternatives that you can start implementing today.
The PHP Framework For Web Artisans
Laravel is an open source, free PHP framework from Taylor Otwell based around the model-view-controller (MVC) architectural concept. The framework was first released in beta form in June of 2011, and has since been continuously developed and expanded from its initial versions.
First and foremost, Laravel is extremely configurable and extendable. Due to the fact that it’s open source, free, and very popular, Laravel has a variety of derivatives, forks, manipulations, and extensions that make it pretty much able to do whatever you might have it do.
Additionally, Laravel has a top-tier series of documentation media, including screencasts, books, and webpages that cleanly and clearly walk through the subtle minutiae of the framework. Because of this, Laravel is often a point of entry to the greater PHP framework world, as it’s both popular and easy to reference. For many first-time PHP adoptees, you would have a hard time finding a better option.
A great benefit of Laravel is the fact that it supports PHP 7. While this might seem like a minor selling point to some, PHP 7 brings with it a dramatic increase in performance, with some estimates suggesting increases of up to 70%. According to Zend Technologies, when PHPNG, the branch that would eventually become PHP 7’s core, was first implemented, the WordPress homepage required 9.4 billion CPU instructions to execute. After implementation of PHP 7, it reduced these instruction requirements to 2.6 billion, a 72% reduction.
Perhaps even more important is the fact that Laravel is PSR 7 compliant, meaning it adheres to the PHP standard recommendations from the PHP-FIG group and the RFC 7230, 7231, and 3986 descriptions.
Laravel, as with most of the solutions in this piece, is packaged with several special features. Laravel Scout is a driver based solution for database management that synchronizes database search indexes with the packaged Eloquent ORM ActiveRecord implementation. Additionally, Laravel includes a Laravel Echo solution which broadcasts data updates over WebSocket connections to implement realtime user interfaces.
Finally, and perhaps one of the strongest selling points for Laravel, there’s an included authentication package for APIs in the form of Laravel Passport. Passport is a full OAuth 2.0 server implementation that is touted as being configurable in “minutes”.
With all that being said, Laravel does have some issues that might make it hard to adopt. Laravel is far too dependent on database queries, often calling in a manner that some devs would consider “excessive.” While this isn’t really a problem with larger services, as a lightweight framework, this does become a problem, causing backend congestion.
Additionally, while its support for reverse routing (in which a URL is derived from a given route, rather than a route deriving from a given URL) is in some cases a good thing, the actual methods used to invoke the reverse routing can be somewhat complex, making for overhead on a microservice.
The biggest thing that hurts Laravel, however, is the fact that it lacks a lot of community support that is enjoyed by other solutions. While third party implementations are great, they still pale in comparison to Ruby gems, Python PIPs, and Node.js NPM’s. What this ultimately means is that Laravel is powerful, but limited by its relatively shallow community support in comparison to its competitor support systems.
The stunningly fast micro-framework by Laravel
Lumen is intimately related to Laravel, having been developed by Taylor Otwell to quickly build Laravel microservices in a rapidly deployable way. Since 5.2, however, it has moved in a slightly different direction, eschewing a lot of the holdovers to become much sleeker than Laravel.
Notably, Lumen as of version 5.2 no longer includes sessions and views as part of its framework, relegating that to Laravel alone. This results in a much leaner framework than Laravel, and shifts the focus more towards stateless APIs.
Lumen is basically Laravel, but fast. By getting rid of a lot of the extra components that don’t mesh well with stateless APIs, Lumen has managed to slim down considerably, making it an extremely fast and lightweight solution over other frameworks.
Due in large part to this and other design choices, Lumen is a great choice for microservices and optimizing APIs for a quick response time. The framework has been designed from day one to be fast more than anything else, so it’s often quoted as an optimal choice for speed dependent implementations. Additionally, Lumen is simple in its syntax, allowing for ease of deployment.
The intimate relation to Laravel also gives a few benefits to Lumen that other frameworks don’t have. While Laravel’s third party support isn’t as great as other solutions, and it’s community is relatively narrower than others, it still boasts a pre-set range of extensions and appliances that other solutions may not have.
One of the greatest strengths of Lumen is a non-measurable entity — the fact that it was designed by Otwell, who has quite a bit of experience in microservices framework, is something to be mentioned. Additionally, Lumen projects can simply be dropped into a Laravel installation for instant functionality, meaning that anything written for Lumen can function with all the benefits and features in Laravel proper.
Interestingly enough, most of the cons of Lumen are actually derived from the same place its pros are — its intimate relationship with Laravel. While much has diverged in development, there’s still a lot of small hangons from Laravel that make Lumen imperfect.
A big point here is that if you dislike Laravel’s syntax or approach to database querying, you’re going to dislike Lumen just as much, as much of its practices are similar. That being said, Laravel is slower than Lumen by a wide mile, so this might be a non-issue when weighed against the possible benefits.
However fast Lumen is, it’s not the fastest on the block, as is often claimed. As such, if developers dislike the syntax or approach and merely wish to adopt for the speed, this should be somewhat tempered with the knowledge that there are other, even faster frameworks with which to work.
Open Source API-centric PHP Micro-framework
Wave is so much more than it implies in its documentation, however — while it’s true that Wave is small and well-optimized, it has some real internal strengths governing its functionality.
Perhaps the biggest draw of Wave is that it is very, very small, but gets so much done with so little. Wave boasts some pretty impressive support that other frameworks don’t, notably supporting full UTF–8 and jQuery natively. Additionally, Wave supports a wide range of data return types, including XML, CSV, JSON, HTML, native PHP, and more.
For this reason alone, many devs love Wave. There’s an even greater reason to support it, however — Wave utilizes a top-tier security cypher, 256 Rijndael, to encrypt its entire data transmission process. While other frameworks can utilize this through a variety of additional implementations or extensions, Wave does this natively, and does it exceedingly quickly.
Wave Framework also boasts some other great features on its GitHub repo. Firstly, Wave has a great integration for documentation generation, which reduces much of the load of developers when it comes to creating these documents for users. Additionally, Wave Framework has an integrated API testing suite which could help allow rapid development, testing, and iteration of APIs.
The biggest negative, however, is the fact that it’s so different from other implementations. With so many frameworks being based on previous efforts, such as Laravel and Lumen, having a novel approach is both a blessing and a curse, requiring developers to essentially relearn what would otherwise be implied in other frameworks.
Additionally, while it supports an impressive amount of data types and formats, it does lack a lot of additional functionality some developers might expect from their implementation. While this is largely determined by the scope and scale of your project, this does present a problem in terms of long-term scalability. Not every project is designed from the beginning with the end state in mind, and so as development continues and the project scope increases, utilizing this framework might result in a lot of “but the framework doesn’t support this” conversations.
You can certainly get around this by adding additional implementations, extensions, etc., but at a certain point this becomes untenable. This isn’t necessarily a problem with the framework itself, of course, but it’s definitely something to consider. Wave Framework, perhaps more than any other framework on this list, is truly a “micro” framework.
The PHP micro-framework based on the Symfony Components
Silex is a bit interesting. Written in PHP and based on Symfony, Silex is scalable in every sense of the word — the design concept from the very beginning was to make the framework as lightweight as you need it to be, enabling additional functionality through base extensions.
As such, Silex currently exists in two forms. There is the “fat” version, which includes a template engine, Symfony components, database abstraction, a Twig wrapper, and more, and then there is the “slim” version, which contains just the basic routing engine and the various methods of tying in additional functionality through extensions.
Judging Silex is very hard to do in a general sense when we discuss lightweight frameworks, because so much of it depends entirely on which version you use.
With the fat version, the integration of Symfony’s HttpKernel to abstract requests and responses aids drastically in application testing, which can speed up time to market by leaps and bounds. The use of Pimple for dependency injection makes for Application classes which can be used as if they were arrays, making Silex classes extremely flexible.
Some of that is ported to the slim version as well, but slim is more about the speed of its routing. With less overhead and features, Silex slim is predictably very fast, which is attractive to smaller services or services depending on basic processing of large amounts of data.
There is something to be said for having a choice in terms of how large you want your framework to be, though. Having the choice between a fat or slim version of the codebase and the option to later expand upon it in an officially sanctioned way is really powerful, and opens a lot of options up for developers.
A great argument for Silex is that it’s so very extensible. Pimple is functionally a microservice container, allowing third party libraries the ability to tie in, making it both feature-empty and feature-rich in some sort of awesome superstate of quantum feature availability.
With all of that being said, the double choice is somewhat of an issue as much as it’s a feature. Depending on which version you get, Silex might not actually do what you want it to do out of the box, and discovering this only after a long process of attempting to get it to do what you want is perhaps one of the most frustrating things a developer can experience.
Even ignoring that, which is not so much an issue of the framework and more an issue of the developer, there is the obvious issue of speed. Yes, Silex is very fast — in its slim mode. As you add additional functionality, the speed can drop off, making it harder to scale with greater amounts of data. Since we’re talking about being lightweight, this becomes a serious issue.
All that being said, the real issue here lies in poor planning of the microservice itself — if the developer plans poorly, they will run into a greater amount of issues in Silex related to their poor planning than in other languages, and at the end of the day, they might run into a situation where the framework they adopted for speed is no longer fast due to their own poor planning.
A PHP micro framework for rapid web development and prototyping
Limonade is, like Wave, all about simplicity and lightweight functionality. Stated by the developers to be “inspired by frameworks like Sinatra or Camping in Ruby, or Orbit in Lua,” Limonade is relatively easy to implement and use, and is very attractive to developers looking for a simple, straight forward implementation.
Limonade’s main draw is the fact that it’s entirely self contained. Limonade arrives in a single file, and because of how it’s structured, everything is done within the contents of the lib folder. Limonade is designed to be extremely lightweight, and it really comes through in how it’s packaged and how developers interact with it.
As part of that, everything you do within the framework is just as simple. Limonade is designed to be minimalistic, and thus is extremely easy to use.
Unfortunately, that minimalism is part of the problem. Limonade is extremely small, both in terms of size and in what it can do compared to its contemporaries.
And while this would generally not be a problem with something like Silex, which can be expanded upon, Limonade is self contained and has no “fat” and “slim” version. This has resulted in a situation where, even though Limonade is just as useful as it was when it was first published, it’s been drastically overshadowed by more modern frameworks.
Additionally, Limonade relies far too heavily on global functions. Limonade doesn’t actually contain a class, but instead defines the functions which can be used. This results in very messy workarounds for basic functionality that might not be expressly provided for by the framework, and can create long-term issues within the microservice design concepts on the developer side.
That’s not to say these five entries are the only PHP frameworks available for microservices/API development. There are many, many frameworks the average developer has access to. Some are more fully featured than others, and some are specific in functionality to a given use case, but the wide range of frameworks available to developers is simply dizzying:
- API Platform (PHP): The self-defined “ultimate PHP framework to build modern web APIs.” Includes support for a wide variety of Symfony bundles.
- Apigility: Developed using Zend Framework 2, and thus runs on top of the Zend Framework MVC stack.
- Flight: designed first and foremost to be extensible and simple. Great for rapid development and deployment cycles.
- Bullet: Utilizes nested routing callbacks, and offers a Composer for package management and autoloading. Automatically conforms to the HTTP specification requirements.
- Phalcon: Full-stack framework designed as a C-extension. Built upon the model-view-controller pattern, and designed specifically to be “high-performance.”
- Frapi: Frapi is designed to not be a “general purpose framework,” and is instead, according to their documentation, aiming “at removing the whole front end layer complexity that handling REST calls can bring.”
- Recess: Rather than focusing on speed or optimization, Recess is designed to be “fun.” While it still is just as fast as its contemporaries, it’s specifically designed to do more with less code, with the idea of taking the developer out of the command line and deploy loop.