Back

Hey Laravel devs, a question! 👋

For big projects containing a presentation website + app + ..., do you go full monolith or do you create separate Laravel repos for each part (and if so, how do you deal with repeated models, jobs, etc.)?

4 • •

420

•
  • No matching results...
  • Searching...

/ 1000

I think in most of the times a single monolith would be best. I used the dual system back + front but I think is an useless duplication of code and multiplication of failure points. Also depending on how you implement it, a dual system it can add a lot of latency.

• •

44

•

Monolith all the way. With Livewire and Inertia there's no need to create a problems for your future self.

• •

76

•

I'm actually about to build a tool for Laravel that might help with this. It's going to allow you to quickly integrate web pages and a blog into your Laravel project, without getting in the way of what you are building so you don't need to learn another framework or way of doing things.

For me it's meant to solve this exact problem where I want an app and blog and a few about pages that are all built into one monolithic app.

1 • •

63

•

What features would your tool add to the framework? Because in case of a monolith I'd simply register a new routes file, add a Controllers sub-directory for the presentation website and/or blog, and that's it.

If you don't care to share, of course! :)

1 • •

33

•

I have 2 things in mind.

1) instant setup of the back end for the blog and pages, so you don’t have to create the CRUD stuff yourself and can get started quicker. You won’t need to create the WYSIWYG because all creation will happen on a central website that will then sync your blog posts to your own site. You won’t have to worry about connecting an S3 bucket for any images you upload to save space on your server either.

2) centrally manage all of your blog posts for multiple sites in one place (assuming you have multiple projects and each has their own blog).

That is for the primary planned features, but I also want to apply the same simplicity to other things that you may want to easily install into your app, such as a bug tracker, or forums. But as those are way more complex than a simple blog it will require some more thought on how I can do that.

The goal is 1) let you get started right away without distraction if building more stuff, and 2) don’t get in the way of your app

• •

26

•

I'm a fan of the monolith. It's just so nice to have everything together and then you don't have to deal with separate hosting set ups either.

1 • •

148

•

That's one of the main reasons I was thinking about in favor of the monolith. However, working as a team, separate repos could maybe offer less compatibility issues or maintenance overhead, allowing to upgrade each part at its own pace.

1 • •

149

•

Ah, didn't realize you had separate teams. In my experience, I haven't found maintainability to be the issue–you just have branches for upgrades and it works out.

That said, if you have frontend devs who are used to working in JavaScript frameworks, there is a learning curve for them to step into a Laravel project. But, if you spend a week helping them get set up, then most of them are good to go pretty quickly.

• •

84

•