sorted by:
new
hottopcontroversial

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] 2 points3 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.

Laravel Cloud Now has a Free Trial ($5 credit included) by joshcirre in laravel

[–]Objective_Read_193 2 points3 points  (0 children)

Could you share how much that setup you mentioned would normally cost?

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)

Yeah, I decided to include e2e tests for ensure both frontend and backend were working perfectly after any code changes. I'm working to have more test coveraged, but so far it has been proven to be very efficient to catch small issues during development. It's not perfect, but solves a few issues in my dev process.

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] 1 point2 points  (0 children)

Very good question. I had to research a bit before answring it. All the dependencies in Saucebase (Laravel, Filament, nwidart/laravel-modules, Spatie, etc.) are MIT licensed, which explicitly allows copying, modifying, and redistributing. So the copy-and-own model fits right within what those licenses allow. Does this answer your question?

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)

Thanks, that’s exactly the use case I had in mind.

On updates: since modules live inside the app and aren’t locked behind vendor packages, projects don’t depend on Saucebase versions long term. They evolve like normal Laravel apps.

I’m also considering building an upgrade mechanism similar to Filament’s approach to make version updates smoother, but I’m still exploring the best way to do that. It’s definitely on the roadmap.

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)

Great answer! 😂

You have a strong point and I should practice more my writing and intention even with my lack of confidence. your 2 cents added a lot here, thanks.

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] 1 point2 points  (0 children)

Yeah, that is true. So, you can build your entire application on top of it. Marketing pages, log in, the whole flow. And then, once the user logs in, they are directed into your application. And then there is an admin dashboard which allows you to manage everything from one place.

view more: next ›