I am currently assigned to create a ReactJS + Laravel + TailwindCSS stack ERP system while maintaining a Multi-Tenant/Modular Architecture, so far I've created the ReactJS and the Laravel parts separately.
Was wondering if it's better to keep going with 2 Separate Projects or Join them into one using Inertia.
Bare in mind I've used Inertia with VueJS not ReactJS back in the day and I don't know if its going to hinder the performance since I have some features like POS that needs Quick and almost instant responses.
Please give me guidance on what should be best, also I've encountered some issues with the API authentication so I was wondering if using the StarterKit would help.
If I had a working SPA + API app, I wouldn't refactor the whole thing unless I had a real reason to do so.
For new projects, I'd always go with Inertia. It's just a nicer experience. Having an API-only backend won't be faster: if you need to hit a Laravel backend for data, it doesn't matter if you get an Inertia response or a plain JSON one.
In my situation I have the luxury to refactor the code as I wish, but I'm concerned about the performance/scalability aspect of my project, as an fresh ERP with basic functionality it's fine as I've tried Inertia in a smaller project, but would it impact my project if the System is too complex?
It's basically an accounting ERP system with the possibility to expand different modules based on future requirements.
@BaselAJ Will the system be simpler if you have two separate repositories instead of one, and you have to wire them together yourself and maintain separate routers?
There are many ways to scale an app. What are you thinking, and how would two projects help there?
@JussiMannisto Basically In the ReactJS side I'd have to configure the routes by hand which is annoying, as for would the system be any simpler of course not.
I would love to have a package to work the charm Inertia does, but I'm reluctant to use it as some people I know said it might effect performance to have everything squashed together it's better to have everything separated and to talk through APIs as intended from Vue and React.
As I mentioned before my app is going to be Multi-Tenant/Modular approach which makes me even more reluctant since ReactJS is new to me and I don't know if It might work with TenancyForLaravel package that I'm using in the Backend.
some people I know said it might effect performance to have everything squashed together
You should ask yourself: does this make sense? Does it explain anything?
If squashing things together adversely affects performance, why have one React project — why not have three or four?
Just because someone says something, it doesn't mean it's sensible. Ask them to explain what they mean. If they can't do it, you know the advice is nonsense.
You're still running React on the front end. You're still sending JS requests to the server. The front-end source code just lives in the same code repository.
@BaselAJ I don't really know your architecture — just that it'll be a multitenant app with React and Laravel.
I've built and maintained multitenant apps, but I haven't used any packages for multitenancy as I've always implemented it myself. Our larger apps use a mix of UI technologies for different parts of the app: React + Inertia, Angular, or just plain Blade. The choice of UI tech doesn't impact scaling that much, as long as you use a CDN and cache aggressively.
@JussiMannisto CDN is on my to-do-list after finishing the main features, got a little list of final touches I'mma be doing afterwards, thanks for the help
I’d stick with whatever keeps your flow simple. If you want tighter integration and shared routing, Inertia can help, but separate projects stay cleaner for strict modular or multi-tenant setups.
