octane VS Laravel

The web server my app uses is not too slow, after load testing with wrk **the RPS on a single 512MB dyno with database queries is 474 requests per second. While running this test, I could still use the app but the response times were higher (400ms-800ms instead of the usual <110ms).

Re Octane, yes it's WIP https://github.com/laravel/octane/pull/764 there were some performance issues found which don't seem to affect non-Laravel apps which is weird/confusing so that's still being looked into. But, soon.

I was hoping that Octane would add support, but the person running the Octane github is one of those people who quickly closes every issue that isn't considered a bug. So no traction is ever built up like on https://github.com/laravel/octane/issues/110 .

Laravel was recently updated to support serverless deployments, alongside the launch of Vapor[1].

Octane[2] is also very exciting. Using Swoole[3] (or another similar driver), Laravel applications can be run entirely in-memory. Early benchmarks showed Octane increased concurrent requests from ~500/sec. to ~6,000/sec.

[1] https://vapor.laravel.com/

[2] https://github.com/laravel/octane

[3] https://openswoole.com/

Another feature of Laravel you might want to take a look at, just became available since the last Laracon. It's called Octane, and it's currently in a beta version, but its potential for optimization, compared to a normal Laravel app, is pretty great. Note that it requires PHP 8.0.

Taylor Otwell already showed a glimpse of Laravel's latest open-source package, Octane, during his Laracon Online talk - but today, the new package is available on GitHub for everyone to beta test.

New 0.7.3 release includes a rule that can check Laravel Octane compatibility of your application. It basically automates the things mentioned in the official docs. You can give it a try now! And let me know what do you think!

Recently the Laravel Octane package was released. It was created to make Laravel with Swoole and RoadRunner more friendly. We are using RoadRunner instead of php-fpm in dev.family for some time now, and we decided to share our experience and to reveal what advantages it has.

Hope this saves a future team from unexpected behavior resulting in (potential) production data loss.

When using Postgres, Laravel's default method for truncate uses the cascade option, which will ignore foreign key constraints and potentially wipe large amounts of data with no confirmation or warning.

It was originally introduced in 2018: https://github.com/laravel/framework/pull/26389/files

Here are two threads on it if you are curious: https://github.com/laravel/framework/issues/29506

I am just exploring middleware in this post, but as you can see this is quite a different approach than we've seen historically. I sat there scratching my head, "How do I set up my own middleware? How do I change the defaults?" I had to explore the Illuminate\Foundation\Configuration\Middleware class to find out.

For example check out this issue I reported on their side: https://github.com/laravel/framework/issues/49089

It does not mean you should absolutely use it everywhere, but it can make sense for your case. Many frameworks, like Laravel use it to compose new projects.

https://github.com/laravel/framework/blob/00894b89e42a9d707c...

Even Tinker is a few lines of code to extend PsySH and credit is barely given.

Taylor Otwell is a fiend for creating wrappers around solid open source libraries, using PHP magic and encouraging bad practices, all just to breed an ecosystem ultimately to land him a Lambo, fuelled by amazing open source foundations that have barely been contributed back to by him.

This same system has been used in Laravel since version 4.0* albeit in the more PHP plain way, using call_user_func_array (Laravel Model Class).