Laravel vs Nuxt: Scalability and Backend Separation in Full-Stack Development
Let me put it this way:
Imagine you have an idea, and you're eager to start building it as soon as possible. You have two options: Laravel and its entire ecosystem, or Nuxt.js. Both allow you to develop your MVP quickly, though Laravel might be slightly faster since you don’t have to choose from a vast array of services—Laravel's ecosystem is fully supported by its own team.
Now, let’s say your hypothesis is validated, and your project begins to scale, along with your development team. If you chose Laravel, you could easily use what you've already built as your backend and introduce a new frontend, perhaps with Vue (whether in JavaScript or TypeScript).
But what if you chose Nuxt.js? How would you handle the same scenario? Would you need to make any significant changes? What if server actions become the new standard, eliminating the traditional separation between backend and frontend? What if you could split a Nuxt.js project into distinct server and client components?
In the Laravel scenario, introducing a frontend later is straightforward. However, if I chose Nuxt.js, I might eventually need to introduce a backend. To me, introducing a backend feels more risky and complex than introducing a frontend.
I apologize if this sounds confusing or frustrating. I'm genuinely trying to understand and learn more about these concepts.
25 Replies
Building API first might mitigate need eventually introduce a backend.
We might have different experiences, but I never saw a horizontal split (e.g. frontend team / backend team / infra team) that works naturally and preserves development speed. You don't have to split backend and frontend if you scale and if you really need to waste resources, Nuxt offers "layers" and "modules", so you can let frontend experts take care of Design System and reusable components while small army of junior/mid developers execute specific websites and dedicated functionality. If backend devs won't join the party, there is a freedom behind API gateway 😉
What if server actions become the new standard, eliminating the traditional separation between backend and frontend?It's not going to fly for any large scale project. If anything it might be "hyped" a bit, but standards take long time to establish and if it would really make noticeable different for your project, you will be happy to pay the price of migration.
I might eventually need to introduce a backend. To me, introducing a backend feels more risky and complex...I have the opposite feeling. Backend is usually strongly typed, dumb database proxy that consists of ACL annotations, DTO » DbModel mappers and validation. But sure, if your typical project have 5x more code in backend and you hit "PHP holds us back, we need to rewrite to Python", then the risk is definitely greater. My past projects have usually the ratio of 5-10x more frontend code, so the risk/cost of changes is much greater
Wow, thank s for the insights!
A bit of background:
I am proficient in Python and intend to use it primarily for data analysis, OCR, and machine learning. I plan to utilize FastAPI to create APIs that access this logic. However, I also need to build a frontend, and I’m debating whether to use PHP (Laravel) or TypeScript (Nuxt.js). Python will be a part of the stack regardless. So, the key decision is where to invest—PHP or TypeScript.
What challenges might I face if I choose PHP, and similarly, what obstacles could arise with TypeScript? For example, with Laravel, I feel that I could maintain a monolithic architecture longer than I might be able to with Nuxt.js. I'm trying to understand how long this would be feasible and whether it truly matters in the long run.
I'm trying to decide between two approaches for my project. Should I choose PHP with Laravel for the backend and later introduce Nuxt as the frontend? Or should I start with Nuxt and then build a backend? In the first scenario, I would need to work with two languages (PHP and TypeScript), while in the second, I'd primarily focus on TypeScript. However, I'm really drawn to the Laravel ecosystem because it's well-maintained, stable, and thoroughly documented. And this is mainly because I dont understand good enough the Nuxt ecosystem. For example what could I use as a backend if I choose the Nuxt path? Nitro? Then does Nitro have all these add ons that laravel has?
Well.. "a tool that has it all built in" is hardly a selling point nowadays. I still remember how painful it is to setup environment for a PHP project. Nuxt has "just enough" and anything extra comes as large library of modules. This way it works very well for many use cases and hosting scenarios.
Then does Nitro have all these add ons that laravel has?Think about capabilities rather than add-ons. Granular caching & routing, web sockets, background tasks, it checks all the boxes for me 🙂 I think, overall you angle is still a bit... unusual. People tend to think about project priorities (speed, costs, scalability), ecosystem health and engineers availability. Maybe it would help if you could do steps instead of jumps. You can setup Nuxt "under" Laravel to generate static assets for SPA frontend that talks to PHP tasked with delivering REST API or GraphQL endpoint. This way both could compliment each other. I used such architecture for the past 4 years with .NET backend.
All these solutions we’ve discussed offer similar benefits in terms of speed, costs, scalability, ecosystem health, and engineer availability. My question is whether I should stick with one main language, TypeScript, or opt for a dual approach using both PHP and TypeScript. I’m reaching out to people with more experience in this area to get their insights.
Specifically, if I choose Nuxt for the MVP and later add a backend, will that actually be faster? It seems like it might not be, due to the potential issues with packages and modules that could become unsupported, forcing you to fix them instead of focusing on shipping. On the other hand, if I choose PHP with Laravel, everything is in one place and tends to be more reliable, since it’s mostly maintained by a core team and is consistently supported.
So, the question boils down to this: Should I start with Nuxt and then add a backend later (which could be anything, even .NET), or should I go with Laravel from the start because it has Blade for templating and is a full-fledged backend framework, and then add Nuxt later?
It can be that I understood you wrong so please correct me if it is so.
Both can coexist. There’s no reason to question which language you pick, in the same sense you wouldn’t expect to write HTML and CSS in TypeScript or PHP. Each language plays a role in the overarching product.
I think what you’re asking is, do I write server side code in PHP or do I write it all in Nuxt? Given Nuxt is an SSR application, there’s no reason to suggest you need PHP to deliver any server side HTML. But you may still need it for your “backend” to facilitate your frontend, such as datasets, authorization, underlying configuration, etc. All of which can be answered by the needs and requirements of your project (which, to my knowledge, nobody knows anything about at the time of writing).
Personally, I’d build the product, with server side rendering in mind, in Nuxt as that is precisely the designated role it plays. Perhaps your product has one of the aforementioned requirements, therefore Laravel may facilitate this. I can tell you, however, you cannot put Nitro and Laravel in the same category. Laravel has been present for a LONG time. It has a huge community and ecosystem. Its security features and performance optimizations are shoulders above JavaScript.
Thank you for your clarifications! 😊 So, it seems that using PHP (with Laravel) for the backend might be a better choice than using TypeScript. However, this would require me to learn PHP as well. My project, like 95% of web apps, needs features like datasets, authorization, and underlying configuration. If I choose PHP for the backend, it makes sense to start with Laravel. Then, as the project grows, I can add Nuxt to separate the frontend. This would mean working with two languages.
I feel like starting with Laravel and later converting it to an API-only backend while adding Nuxt for the frontend might be quicker overall compared to starting with Nuxt and then building the backend.
This is what I'm trying to understand: What is the better approach? Should I start with Nuxt or Laravel, and why?
And if I want to stat with Nuxt, and then there will be a tiem to add more fucntionality which will force me to add a backend. What are the choices for a TypeScript backend?
I think I’d make that distinction before starting the project. Understanding what role each “framework” plays is crucial to scaling your application. I’m curious to know what you consider to be frontend and backend. Because I wouldn’t build a web app in one language only to move parts of it to another if I knew from the outset that it would be inevitable.
I consider forntend to be that apart where im building the UI for my user. That what React and Vue was build for. Nuxt does the frontend jobs very well. Backend is where I write mostly my logic of how the things shoudl work based on what the user clicks on the UI. THings like crud to databse, authorisation, analysis of data, convert files, create files, parse files, process some data throught my ml process which can be another external microservice(for example a pytohn fastapi api).
How I can make that disctinction if I dont know much(in detail, the limitations etc) about the "framework"? So i came hear to find people that know more than me
Maybe I miss soemthing :/
idk
From that excerpt alone, I would highly suggest building the backend in a language you’re comfortable in, maybe Laravel is something you’ll ultimately decide on, and let Nuxt manage the frontend. Not all those backend needs you mention are “easily” manageable in a single language or application like Nuxt, you’ll learn that eventually. I also don’t consider, in my humble opinion, Nitro and Nuxt to be a good bearer of such brunt when it comes to the scale of such an application. Lest we forget, you’ll be distributing all of this on a single threaded language, something you may later live to regret. Long story short, design your backend in something like Laravel, build your beautiful app in Nuxt (which I’m sure you’ll enjoy), connect the two and pour yourself a beer.
Thank you mate <3.
And good luck on your learning journey. Expand your horizon, you’ll be giving everything a try at some point. For what it’s worth, I have a project I’m working on that has a Laravel backend, a Go backend, a Deno backend and a Nuxt front end. All of which coexist and written in their respective language for a reason. And because why not? Have fun!
I want to suggest looking into InertiaJS which has a Laravel blade like Vue SPA like frontend which is very fast to develop inside your Laravel backend. The rest is already been said. Have fun with building 👍
So if you did not ask from a PHP lover standpoint, let me add a few more cents of advice like it's 2024. If I would start a new project and have a freedom of choice for the stack (and no arguments like "I coded in X for 10 years so I stick to what is tried and true") I would think about the costs of performance and scalability much earlier.
While making enterprise software for enterprise clients is still bending any logic – i.e. they usually (over)pay tons of money, for a crap and commit to long contracts – the typical SaaS products actively create market and in doing so, burn money on the free tiers and trials. This means if you bet on traditional monolithic PHP backend that generates AWS bill for around $2000 ~ $5000 per month, you will struggle to make it all sustainable.
We kinda wish successful MVP could easily transition from monolith to microservices behind API gateway once it gains traction, but it's 2024 and everyone should know microservices are good on paper, but in fact only shift the complexity to the infrastructure and require DevOps enginers that don't come cheap - offsetting any savings from AWS bill. No.. let's be real. Unless you are backed by large company that can shift experienced engineers around, microservices are a death wish.
So assuming "typical SaaS" for a Startup company, the best bets in my opinion are Nuxt or Elixir.
- Nuxt for scaling on the Edge network if your backend would consist in 90% of CRUD operations
- Elixir for scaling heavy load on traditional VMs keeping the bill low as the user count grows to thousands
Also one comment on the Blade templating – only choose SSR/MPA if you have public pages that need to be crawled (for SEO). Otherwise you just waste resources, as most logged-in users' devices will be perfectly capable of loading JS/CSS bundles and only exchange JSON during typical workflow.
Look, I get where you're coming from with those 2 cents, but I gotta disagree big time.
Here's the deal with startups:
When you're doing a startup, you need to ship fast. Period. And yeah, you hope whatever tech you pick now will still work when you're big time. But Elixir? Come on. That's not it. Nuxt? Maybe. It's getting better, and I dig how balanced the Nuxt ecosystem is. But it's not always the best for starting out.
You're talking about bills and teams like we're already big. Let's get real.
For a startup, you need:
1. React on the frontend = huge dev pool
2. Something like Python or Laravel on the backend = another huge dev pool
Why? So later, when you actually need to scale, you can easily split it up, make an API, whatever. You've got options and people to hire.
- Nuxt can do the job, sure. But you'll spend more time setting stuff up than building features.
- Laravel? It's faster to get going. Everything you need is right there.
With Laravel, you can crank out any kind of SaaS fast. I'm talking ship a product in a week fast. Try that with Nuxt, and you'll spend most of your time configuring stuff Laravel gives you out of the box.
1. Start with Laravel. Ship something in a week.
2. If your product actually takes off, then think about bringing in Nuxt.
Nuxt is great when you know you're getting bigger and need that extra flexibility and stability. But for starting out? Laravel all the way.
You're choosing the path with the least barriers:
1. Ship fast
2. Find devs easily
3. Keep moving forward
That's what matters for a startup. Not some theoretical perfect tech stack that'll slow you down when you're trying to get off the ground.
And hey, if someone tells you to use Elixir for your MVP, just smile and nod. Then go back to your Laravel project and actually build something while they're still setting up their "perfectly scalable" system. Remember, you can't scale what doesn't exist!
This is just my perspective
I like that you have strong arguments for it.
One thing that could strongly influence the choice here is target audience.
I haven't seen yet a project where a few weeks could make a difference, as sales people spend months on converting prospects into clients (in the B2B context).
Life is already complex don't think so deeply about your app if you want to ship so fast use Laravel! if you're going to love to use JS use inertia with laravel! if you want to use it separately with the frontend (using nuxt) and backend that will not be faster than you think. Thank you
It will make difference for you getting the investment by showing actual activity (if u ship) . In stages like this target audience is yet to be discovered.
So I am OK with spending/investing more time in strong baseline. Then 1-3 devs can pull off a medium size project (e.g. 100 endpoints, 600 frontend components) with stable Kanban througput
Exactly for this reason im asking to find out what others perspectives are on this, how they think? What were their experiences?
May I ask, how much stronger the baseline will be in coparison to another one? Like what are the pros you see in your baseline than the others? This is a very interesting thought of you and I would like to understand it.
The baseline I would seek should include code to demonstrate CRUD on typical data structure with relations and row level security. Let's say: blog posts, comments, versioning, change/activity logs.
In the context of Nuxt for the backend, it would mean choosing input validation (zod), ORM (drizzle, prisma, or something NoSQL), including WorkOS for auth, etc., etc.
I get your point. It is a labor you can avoid - going through all these random docs of Nuxt modules, GitHub repos for examples - worrying about each of them being abandoned, versions not playing with each other, ... It's true and I sometimes wish we could have slightly more centralized docs like Nest.js does. But I am personally comfortable regardless, because I get enough time from clients/investors to do my best work.
Some people are not comfortable with bloated frameworks that potentially accumulate opinions, specialize in nothing and require few dozen online courses to start. I'm not talking about anything specific, but I get the appeal of Nuxt Hub.
I wouldn't touch AWS or Azure directly as a newcomer. It is so much pain... Netlify, Deno, Cloudflare are solving real problem here, helping ship faster and cheaper. Not sure if PHP plays well with them though..
Great inputs mate!
So here we have something like Backend for Frontend pattern, right?
Agree! Or a simple droplet from DigitalOcean.
Thanks for asking the interesting question. I used to put PHP in the "avoid at all cost" box next to Java, but it seems I was wrong. If it would be in this state (with Inertia.js) 4 years ago maybe I would not rewrite a project from Laravel to .NET+Nuxt 🙂 It was a poor execution with MVC with Vue, Bootstrap, tons of dead code.. nothing to salvage really.
I'm reading all of this and everyone is making good points and I'm wondering why you wouldn't just go for Django, since you are already python proficient. For any new project and rapid prototyping Django makes so much sense since it has the best DB migrations systems IMO that makes maintaining your DB's a breeze once you roll your project out to production.
My tech stack would be Django with Graphene (GraphQL) layer and Nuxt frontend.
Because, yes, Django is a very good framework, and I've built/sold apps with it, but in the end, I can't do everything with Django that I can do with Laravel for web development. I mainly use Python with FastAPI for tasks that Python excels at. In Laravel, there may be a bit of a struggle in the beginning to understand how everything works, but over time, the learning curve more than pays off. Plus, there's Laravel Eloquent (I’m referring to the Active Record pattern), Queues (please don’t bring up Celery—every Python web developer knows how painful it can be), and multi-tenancy. And I haven’t even mentioned Django’s async capabilities, haha.