Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

RealWorldDev's avatar

Inertia project + sanctum authenticated API

Hello all

I've have a Laravel 12 inertia app up and running using a starter kit but my client wanted to connect a mobile app and a desktop app to it. So, I added an API to the project and added sanctum so the mobile and desktop apps can call the API and users can be authenticated. All of this is working perfectly but my question is if anyone else has done anything similar? I ask because I'm wondering if there are pitfalls that will hit me further down the line that others have experienced.

Also, with the web app and api all being in the same project with (with different authentication methods for the two routes), I'm hoping that the traffic hitting both, and the therefore the database as well, will be able to cope with it all. Previously, I've had just an API project with frontends using it in a normal way but this was different as the client originally only wanted a web app so I went with inertia. MySql is pretty good at massive amounts of traffic so I should be ok...right?

Interested in hearing some thoughts on this...

Cheers! Michael

0 likes
4 replies
LaryAI's avatar

Certainly! Here’s a breakdown of considerations and advice for your setup:

1. Combining Inertia (Web) and API (Mobile/Desktop) in One Laravel Project

This is a common approach and is supported well by Laravel. Many teams use a single Laravel backend to serve both a web frontend (via Inertia.js or Blade) and APIs for mobile/desktop clients.

2. Authentication: Sanctum for API, Session for Web

  • Web (Inertia): Uses session-based authentication (default Laravel auth).
  • API (Mobile/Desktop): Uses token-based authentication via Laravel Sanctum.

This is the recommended approach. Sanctum is designed to work alongside session-based auth, and Laravel handles this separation well.

3. Potential Pitfalls & Best Practices

  • Route Grouping:
    Keep your web and API routes clearly separated in routes/web.php and routes/api.php. Use route middleware to enforce the correct authentication guard.

    // routes/web.php
    Route::middleware(['auth'])->group(function () {
        // Inertia routes
    });
    
    // routes/api.php
    Route::middleware(['auth:sanctum'])->group(function () {
        // API routes
    });
    
  • CORS:
    Ensure your API is properly configured for CORS (Cross-Origin Resource Sharing) so mobile/desktop clients can access it.

  • Rate Limiting:
    Protect your API routes with rate limiting to prevent abuse:

    Route::middleware(['auth:sanctum', 'throttle:api'])->group(function () {
        // API routes
    });
    
  • User Model:
    If you need to distinguish between web and API users, consider adding a column or using Laravel’s guard system.

  • Testing:
    Write tests for both web and API authentication flows to ensure they don’t interfere with each other.

4. Performance & Scaling

  • Database:
    MySQL can handle significant traffic, but performance depends on query optimization, indexing, and hardware. Monitor slow queries and use Laravel’s query logging/profiling tools.

  • Caching:
    Use Laravel’s caching (Redis, Memcached) for frequently accessed data to reduce DB load.

  • Queueing:
    Offload heavy or slow tasks (emails, notifications, etc.) to queues.

  • Horizontal Scaling:
    If traffic grows, consider scaling your app servers and database (read replicas, clustering).

5. Security

  • API Tokens:
    Sanctum tokens should be stored securely on the client (never in localStorage for web, use secure storage for mobile).

  • CSRF:
    Web routes are protected by CSRF middleware; API routes are not (since they use tokens).

6. Documentation

  • Keep your API well-documented (Swagger/OpenAPI, Laravel API resources, etc.) so mobile/desktop teams can integrate smoothly.

Summary:
You’re on the right track! Many Laravel projects combine Inertia (web) and Sanctum (API) in a single codebase. Just keep your routes, authentication, and middleware clearly separated, monitor your database, and be proactive about performance and security. As traffic grows, you can scale both your app and database as needed.

If you have specific concerns or run into issues, feel free to ask!

martinbean's avatar

with the web app and api all being in the same project with (with different authentication methods for the two routes), I'm hoping that the traffic hitting both, and the therefore the database as well, will be able to cope with it all. Previously, I've had just an API project with frontends using it in a normal way but this was different as the client originally only wanted a web app so I went with inertia. MySql is pretty good at massive amounts of traffic so I should be ok...right?

@realworlddev We can’t really answer without knowing your traffic patterns and server load, unfortunately. You’ll need to add monitoring to your application that can then alert you if users start experiencing errors.

1 like
RealWorldDev's avatar

@martinbean That's a very fair point. It's currently heating peaks of 120 (ish) concurrent users with 20,000 - 30,000 API calls a day. This will increase slowly though as more clients come on board but not by a huge amount, probably about 20% - 25% increase.

I've read a few posts in the past of some developers thinking the API should be completely separate so it's best to prepare for scaling which sounds plausible and I may have done it that way if this was the original spec but I'd rather not have to undo lots of work. I'm thinking that it if doesn't grow massively, then having this current approach of the API and Inertia frontend being in the same project is fine. Obviously they are routed differently.

Was just keen to hear thoughts or pitfalls that others may have experienced if they had the same scenario.

martinbean's avatar

It's currently heating peaks of 120 (ish) concurrent users with 20,000 - 30,000 API calls a day. This will increase slowly though as more clients come on board but not by a huge amount, probably about 20% - 25% increase.

@RealWorldDev There are 86,400 seconds in a day. 20,000 to 30,000 API calls a day is less than one every three seconds on average. I’m sure it’ll be fine.

Please or to participate in this conversation.