Hi there everyone,

Ruben's here once more (but first writing in to my personal blog). If you didn't notice I'm mostly about posting some micro-content on Twitter, but now I'm here using Hashnode to ease up my developer life.

Anyway, enough chatting. We're here to talk about serious business, specially now with the Laravel framework.

Before blaming it, you guys should know that I'm proudly contributing to its community by creating some open source packages extending Laravel, sending some commits fixing stuff on some of the Laravel's projects, but most importantly sponsoring it.

I'm fully working on a big project which is being running a full Laravel refactoring since 2019. But we've come to many troubles like: Upgrading Laravel major versions (not a big deal <3), scaling our application to some extend (thanks mostly to Laravel Vapor and Laravel Octane), refactoring some parts of it to be on newer PHP versions also required by Laravel upgrades.

You know a developer's life is never easy when you hear all this kind of day by day problems (and there are not just those).

I get that the Laravel team is now focused on what they can maintain, and they don't rely fully on what users contribute or send them via Github pull requests.

Bootstrapping your application

With Laravel we've all the power of Artisan, which is an extension of Symfony's Console, but more sweet (as everything on Laravel), BUT...

All the artisan make commands aren't just that quick to start with, sometimes on bigger projects you want to open that file that artisan just created. Or create a new file using a custom folder structure (like a Domain Driven Design, or DDD).

Hopefully this will be solved on a package I'm working on 😄

Magical stuff = IDE problems

Laravel has still a lot of magic methods (like Eloquent's model attributes), which this could be solved doing something a little bit more like Doctrine does, which uses the models to completely different thing that most of you will use Eloquent ones.

From this side I see Symfony more prepared for larger architectures out of the box, not that Laravel cannot work in large projects but just it doesn't make it easier for the developer.

Btw most of this can be solved by the laravel-ide-helper package, check it out.

Queues for heavy work but don't abuse them

Yes, queues are a great thing specially for that kind of work that must be done in the background, yet they can be engineer to do work acting as a user but here is the thing:

First, they don't come prepared to do this kind of thing so... you can imagine sending the current authenticated user on all your queued jobs? Nah, instead you could use this (btw, not in the Laravel documentation yet)

Anyway, scaling your heavy stuff with queues has its downsides, specially sending model instances that are being serialised to be saved in a memory-database like Redis (don't know if any of the other engines like RabbitMQ will need this)

So your heavy work will be done before querying more stuff which is all the models the framework serialised when you dispatch the job to the queue.

That said imagine having 1000 jobs triggered in a batch from another job that works duplicating stuff (first querying it, then inserting the modified replicated model instances)... 🤯

Not to say that also error handling on these is another thing you should engineer yourself.

TL;DR

Anyway, I don't want to make this article eternal.

Laravel is the best in terms of small projects although it can be engineered to achieve great things at scale (bigger projects) but things starts to get complicated once you leave the opinionated framework way of structure applications.

Happy coding!