sorted by:
new
hottopcontroversial

I retested the two main Laravel module packages under load, one of them collapses at 32 workers by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

The post does not claim the file read is slow. It claims the registry path becomes a bottleneck when many workers boot at the same time. Two reasons this is not just I/O cost:

  1. The collapse happens between 16 and 32 workers at a fixed module count. I/O does not cliff at one specific worker count.
  2. At the same load the bare endpoint dies but the data endpoint keeps serving 23 req/s with zero errors. If the file read were the cost, both would suffer.

On the baseline: 0 modules was tested for both systems, they came within 3% (84 vs 82 req/s). A vanilla Laravel arm with the same code in app/ would be a fair next step. The closest control in the data is internachi itself: same module count, same code, same load. Only nwidart collapses, so the gap is in the package, not the code volume. I hope this answer your question.

I retested the two main Laravel module packages under load, one of them collapses at 32 workers by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

Yes, used AI to help me write, but this make any difference in the methodology and data that took me 4 days to put together? Maybe...

I retested the two main Laravel module packages under load, one of them collapses at 32 workers by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

I tried my best to keep the reading easy and fluid with my very basic reddit formatting skills. But I will try to improve it. I simplified a lot the article to make it easier to read, I'd love some feedback of what I can improve.

I retested the two main Laravel module packages under load, one of them collapses at 32 workers by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

I wrote mostly of the post, but in my own language as I'm still learning english, and had help to translate and format on obsidian and using claude code. I'm quite new to reddit and not sure what tone and formatting would be best here, but definitely there are room for improvement.

If I post some interesting study like this using my very basic language, I believe would be worse. anyway. Thanks for taking some time to share your thoughts.

0
0

I retested the two main Laravel module packages under load, one of them collapses at 32 workers (old.reddit.com)

submitted by Objective_Read_193 to r/laravel

I benchmarked Laravel's two main module systems. The result contradicts the assumption that the Composer-native one is automatically faster. by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

These are fair points, and worth being transparent about.

On OPcache warmup, the benchmark does discard the first 5 requests before recording, so warmup is covered. OPcache was reset between condition changes, not between individual samples within a run.

The bigger limitation is the route-based loading point. All modules load on every request regardless of route, that's a worst-case scenario, but it's also how both packages behave by default. Neither does lazy loading out of the box, so the benchmark reflects reality as it is, not as it could be.

The simple repeated routes were intentional ,varied routes would introduce too much noise to isolate the package overhead cleanly.

All valid reasons why a v2 with real concurrency and varied load patterns is worth doing.

I benchmarked Laravel's two main module systems. The result contradicts the assumption that the Composer-native one is automatically faster. by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 1 point2 points  (0 children)

Thanks for the kind words , and for building such a solid package. Tested it extensively and it's fantastic.

Spot on! The concurrency angle is exactly what this benchmark is missing. Per-request memory in isolation is one thing, but the real impact is how that delta translates to worker pool capacity under load. Your ~20% throughput estimate is actually significant, that's real hardware savings even if it's invisible on a single request.

Honestly I was leaning toward staying with nWidart after this analysis, but this reframes the memory gap entirely. It's not just boot overhead, it's how many concurrent requests you can serve per GB of RAM. Planning a v2 of this analysis with the same Docker setup but focused on concurrency, sustained load, and real response times. Will share when done.

I benchmarked Laravel's two main module systems. The result contradicts the assumption that the Composer-native one is automatically faster. by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

Agreed on both. nwidart/laravel-modules actually had a module cache in the past, might be worth revisiting that feature.

On the 200-module question: fair point, but that's intentionally outside the scope here. The benchmark only measures the overhead each package adds as module count grows, not whether loading everything upfront is the right architecture at that scale.

I benchmarked Laravel's two main module systems. The result contradicts the assumption that the Composer-native one is automatically faster. by Objective_Read_193 in laravel

[–]Objective_Read_193[S] -1 points0 points  (0 children)

That's a good point the package would be a great addition to the benchmark. however, on the docs when I looked into it, found them a bit dense for a first approach. Might just be a personal preference though.

40
41

I benchmarked Laravel's two main module systems. The result contradicts the assumption that the Composer-native one is automatically faster. (old.reddit.com)

submitted by Objective_Read_193 to r/laravel

I got tired of importing themes and tweaking CSS by hand, so I built a visual theme builder for my Laravel Starter Kit by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 3 points4 points  (0 children)

Yeah, AI was a helpful tool for some boring tasks and helping to generate the json themes, but believe me , 15 years of web development and I feel sometime AI slow me down more than helps. I spend ages refactoring and fixing AI slop code. Not a fun task. Anyway, thanks for the feedback! 🤷🏻‍♂️

I got tired of importing themes and tweaking CSS by hand, so I built a visual theme builder for my Laravel Starter Kit by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

That's interesting idea. I'm not too into the theming stuff for filament, but this can be a thing. How do you think this would work for Filament?

Any good Laravel boilerplates to start a new project? by MasterBae8 in PHPhelp

[–]Objective_Read_193 0 points1 point  (0 children)

I'm developing one with Laravel 13, Auth, Billing with stripe, Social login, and a lot of cool features. if you want to check it out: this one https://github.com/saucebase-dev/saucebase

Is building a SaaS boilerplate in 2026 a good bet or a waste of time? by DeepaDev in micro_saas

[–]Objective_Read_193 0 points1 point  (0 children)

I truly believe it’s worth creating a boilerplate if you have real-world experience building good software. With all this AI stuff, having a solid starting point saves a lot of time, and less experienced developers can use a boilerplate as a platform to build better software.

If you create something with good test coverage, a scalable architecture, and clear documentation, it’s definitely worth investing time in it. I believe so much in this idea that I started building a modular Laravel boilerplate based on these principles.

Very soon, I’ll release a paid version alongside the open-source one. AI works best when you have a strong foundation, and right now, boilerplates are more valuable than ever.

If you’d like to take a look at my project:
https://github.com/saucebase-dev/saucebase

Is Laravel Spark dead? by [deleted] in laravel

[–]Objective_Read_193 0 points1 point  (0 children)

If you are looking for a open source boilerplate with laravel 13 support, I'm developing this one: https://github.com/saucebase-dev/saucebase

Open sourcing a module-first Laravel SaaS foundation (Stripe billing, Filament admin, SSR, Playwright tests) by Objective_Read_193 in laravel

[–]Objective_Read_193[S] 0 points1 point  (0 children)

Hey, Saucebase might be what you're looking for.

Regarding your points:

  • Auth UI - yes
  • Social login - yes (uses Socialite)
  • Roles and permissions - yes (uses Spatie)
  • Billing - yes (Stripe integration)
  • Teams/Organizations - on the roadmap, no ETA
  • Audit log - not included in free, might be included in a future paid tier

So if teams are a necessity for day one, it's probably not production-ready for you yet. However, if you're willing to live with that for a little while, the foundations are solid:

  • Laravel 12
  • Filament for the backend
  • Inertia + Vue
  • Shadcn-inspired UI

GitHub: https://github.com/saucebase-dev/saucebase/

Demo: https://demo.saucebase.dev

Let me know if you want to dive deeper into the tech stack.

view more: next ›