DEV Community

Discussion on: Lightweight Laravel - deconstructing a full stack framework

Collapse
 
matthewbdaly profile image
Matthew Daly

To be honest, that's not the point of the exercise. I'm inclined to agree with Taylor Otwell in medium.com/@taylorotwell/benchmark... in that all the major PHP frameworks are fast enough for any application you or I are ever likely to build. If there are performance problems, they're almost never things that necessitate a rewrite, and it's likely to be easier to resolve them by refactoring queries, implementing eager loading, adding appropriate caching headers and so on. And this is an application with no database queries and heavy caching of the responses already in place.

Will you see a speed boost by eliminating unused middleware, service providers and so on? Yes, undoubtedly, but for a stateless application like this, then it makes sense for Nginx to heavily cache the responses anyway, in which case the majority of responses will be served straight from Nginx without Laravel getting involved at all. So the performance improvements from doing this aren't that big of a deal, given that in a production environment only a handful of requests should be directly handled by Laravel anyway.

The message of this post is more that it's possible to break the framework down in this way, if you need to, in order to get a smaller, lighter application.