Laravel Inertia vs Laravel + REST API + Vue/React: When to use each one

▶

If you work with Laravel and Vue, sooner or later you ask yourself this question:

Should I use Inertia or set up a REST API directly?

It is not a theoretical doubt. It is an architectural decision that affects development time, maintenance and, above all, how easy (or difficult) it will be to evolve the project in the future. I have been asked this several times and I have personally gone through both approaches in real projects.

In this article, I am not going to repeat textbook definitions. We are going to see what changes in practice, what problems each option avoids, and when a seemingly "convenient" decision ends up being expensive.

The real dilemma: Inertia or REST API in Laravel projects

Why this doubt appears in almost all projects with Vue

• The Laravel + Vue combination is very powerful, but it presents a clear fork in the road:
• Staying in a comfortable monolith using Inertia

Separating backend and frontend with a classic REST API

Inertia is especially attractive because it eliminates friction: there is no need to design endpoints, manage tokens, or duplicate routes. Everything flows. And that is precisely why many people adopt it without thinking too much about the medium-term scenario.

The mistake of considering the decision only for the short term

The problem is that most comparisons focus only on "what is faster now," and almost no one talks about the cost of changing the decision later.

That is where the real problems begin.

Practical example

For example, in a project I have with Laravel Inertia, in the detail view we receive contact_general_id as a prop. If we look at the controller, we will see that this data is sent directly to Inertia, without the need to consult a Rest API to fill the information. This works the same whether it is a prop or a variable defined in the data section; the important thing is that the data reaches the component.

A very common query is: "If I want to make a request to get certain information, should I use Axios or Rest API?" The answer is: not necessarily.

How Laravel Inertia works in practice (without REST API)

Direct communication between controller and Vue component

Inertia works as a direct bridge between Laravel and Vue. Instead of returning a Blade view, the controller returns a Vue component along with the data.

There is no intermediate endpoint, no "public" JSON:

Laravel talks directly to Vue.

Props, state, and navigation without Axios or fetch

A very common question is:

“If I need new data, do I use Axios?”

In most cases, it is not necessary. With Inertia you can render lists, forms, and complete views by passing data from the backend, without firing extra requests from the frontend.

This greatly simplifies development:

• Less code
• Fewer intermediate states
• Fewer points of failure

What you gain in development speed:

• Session-based authentication ready from the start
• Centralized routes in Laravel
• Fewer technical decisions

For pure web applications, the pace is very high. You advance quickly and with a sense of total control.

What a REST API provides that Inertia does not cover

Real separation between frontend and backend

A REST API forces the definition of a clear contract between backend and frontend. This adds work at the beginning, but it also imposes order.

Each endpoint has a clear purpose. Each response has a defined format. This is especially noticeable as the project grows.

Reusability for mobile, desktop, and third parties

In my Academy project that I developed, I decided to directly create a REST API even though the initial application was web-based.

Thanks to that, when I later migrated the application to Flutter, I already had the entire foundation built. I didn't have to rethink the architecture or redo the business logic. In real terms, it saved me at least 40% of the work.

If I had used Inertia from the beginning:

• I would have created the web app with Inertia
• Then I would have had to create another API
• And duplicate logic, validations, and structures

That is the hidden cost that almost no one mentions.

Total control over responses, errors, and formats

With an API you decide exactly:

• What errors you return
• What structure each response has
• What data you expose and what you don't

This facilitates debugging, testing, and scaling, especially when the frontend is not just Vue.

Inertia vs Axios

When we use Inertia, it is not necessary to make additional requests with Axios or fetch. For example, if we are building a listing component, we can fill the information directly with the props sent from Laravel. This saves time and simplifies communication between the backend and Vue.

Mind you, the response we get when sending data via Inertia can be more limited than that of Axios; we don't have, for example, a full list of form errors. But this is fine, because the goal of Inertia is to avoid implementing a full Rest API and making multiple requests from the frontend.

router.post('/users', form)

Inertia vs REST API: key differences that really matter

Initial time vs future cost

• Inertia: less friction when starting
• API: more initial work, fewer surprises later

Inertia speeds up the startup. A well-thought-out API reduces the cost of evolution.

Logic duplication and maintenance

If you know the project will have more than one client (web + mobile, for example), Inertia ends up being an intermediate step that later has to be undone.

And undoing architecture is always more expensive than doing it right from the start.

Authentication, state, and scalability

• Inertia leverages sessions: convenient, fast, proven
• API usually uses tokens: more complexity, more control

Neither is "better" in the abstract. It depends on the context.

Testing and debugging

With an API, you can easily inspect each call in the browser's Network tab or from external tools. In my experience, this greatly speeds up development when the frontend is not exclusively Vue.

Thinking about the future of the project: the question almost no one asks

What happens if tomorrow you need a mobile app

This is the key question I always ask:

Are you 100% sure that your application will be web-only?

If the answer is not a resounding yes, a REST API starts to make a lot of sense.

Migrating from Inertia to API: what it actually involves

Migrating is not impossible, but it involves:

• Creating endpoints from scratch
• Reorganizing controllers
• Adjusting business logic
• Changing the frontend data flow

In medium or large projects, this change is not trivial.

When Inertia becomes an intermediate step

If you know there will be multiple platforms, Inertia is not the final destination, it's a transition. And every transition has a cost.

When to use Inertia and when a Rest API?

Another important point is deciding whether it is better to use Inertia or directly create a Rest API. My personal opinion is that it depends on the future of the application.

Use Inertia if…

• If the application is going to migrate to another technology, such as a mobile or desktop application, it is recommended to create a Rest API.
• If the application remains web-only, Inertia is sufficient and saves us a lot of work.
• You want to move fast without extra complexity.
• You don't plan for mobile apps or external integrations.

Use REST API if…

For example, in my Academy project, which is developed in Laravel with Vue, I opted to create a Rest API. This allowed me to later migrate the application to Flutter and saved me at least 40% of the work.

• I already had the structure of the Rest API and could reuse the resources.
• I could easily check the format of the queries through the Network tab in the browser.
• It allowed me to quickly build new screens in Flutter, without the need to replicate the Vue logic with Inertia.
• You need to expose data to third parties.
• You prefer to invest more now to save later.

If I had used Inertia, I would have had more work:

• Create the application in Vue with Inertia.
• Create the Rest API to migrate to Flutter.
• Replicate components and methods, generating redundancy and more maintenance.

That's why, in cases where migration or having multiple platforms is planned, I consider it better to create a Rest API from the start.

If, on the other hand, you don't plan to migrate the application and only want direct communication between Laravel and Vue, using Inertia is sufficient and avoids making unnecessary Axios requests.

Can Inertia and REST API be combined?

In what cases it makes sense:

Yes, and in fact, it is quite common:

• Inertia for the web app
• API for specific functionalities or external consumption

When you are complicating the project unnecessarily:

• If you end up using the API for almost everything "just in case," you probably should have opted for an API from the start.

Frequently asked questions about Inertia and REST API in Laravel

• Does Inertia replace a REST API?
  • No. Inertia avoids creating a full API, but it is not suitable for exposing data to other clients.
• Does Inertia work for large applications?
  • Yes, as long as they are web applications and do not require multiple clients.
• Is it a bad idea to start with Inertia?
  • No, as long as you are clear that it might not be the final approach.
• Can I migrate to a REST API later?
  • Yes, but it involves extra work. The larger the project, the higher the cost.

Conclusion: my honest recommendation after using both approaches

There is no universal answer.

But after working with Inertia and with REST APIs in real projects, my criteria are clear:

• Inertia is excellent for closed web applications
• The REST API is an investment in the future

In my case, for my project, betting on an API allowed me to evolve the project without redoing work. If I had chosen Inertia, I would have moved faster at the beginning... but I would have paid for that saving later. Especially given my developer profile—I like to take projects to mobile—usually Inertia is NOT for me since I believe that everything that can be seen in a web app can also be seen in a native app.

That's why, before deciding, don't just think about what you need today. Think about what you don't want to have to redo tomorrow.