DEV Community: Kamran Khan

5 Laravel API conventions that save you a week on every project

Kamran Khan — Sat, 10 Oct 2026 01:48:50 +0000

5 Laravel API conventions that save you a week on every project

Every client project I take on used to start the same way: a day wiring up auth, another day on roles and validation, a third day arguing with myself about response shapes. After the third project I extracted the patterns into a starter kit and stopped paying that tax. Here are the five conventions that did the most work.

1. One auth controller, kept boring

All authentication lives in a single Api/AuthController with exactly four methods: register, login, logout, me. Tokens come from Laravel Sanctum — createToken('auth-token')->plainTextToken — and that's it. No Passport, no OAuth dance, no JWT package to maintain.

The auth layer is isolated in one controller, so if you ever outgrow Sanctum you're swapping one file, not rewiring the app. (Honest note: there's no password reset or email verification wired up yet — the User model has the MustVerifyEmail import stubbed and commented, ready for you to enable when you need it.)

2. Validation lives in FormRequest classes, never in controllers

Every endpoint validates through a dedicated FormRequest. Controllers stay thin and readable. One place per endpoint where the rules live. When the frontend team asks "what does this endpoint accept?", the answer is a single file, not a hunt through controller logic.

3. API Resources shape every response

No endpoint ever returns a raw model. A UserResource decides exactly what the client sees — id, name, email, role, timestamps. This is the difference between "it works" and "it's safe" — no password hashes or remember tokens ever leaking because someone returned $user directly.

4. Roles without the ceremony

A role string column on the users table (default 'user') plus one tiny middleware covers 90% of SaaS needs. Aliased as 'role', used like Route::middleware(['auth:sanctum', 'role:admin']). And one detail that matters: registration hardcodes 'role' => 'user' — the role can never be self-assigned through the public endpoint. I didn't pull in a full permissions package on day one. That's a week-two problem, and bolting it on later is easy when the middleware pattern is already there.

5. Routes grouped by who can touch them

routes/api.php reads like an access-control document: public auth endpoints, authenticated endpoints, admin-only endpoints. Three groups. A new developer can see the entire security model of the API in thirty seconds.

None of this is exotic. That's the point — these are the unglamorous decisions that turn "week zero" from five days into an afternoon. I packaged all of them, plus a React dashboard frontend wired to this API, into a starter kit because I was tired of rebuilding it on every project:

Laravel + React SaaS Starter Kit — $19, one-time: https://kamranofficial.gumroad.com/l/mhekoig

Questions about any of these conventions? Drop a comment — happy to dig in.

React dashboard architecture: how I organize a real SaaS frontend

Kamran Khan — Sat, 10 Oct 2026 01:48:24 +0000

React dashboard architecture: how I organize a real SaaS frontend

I've inherited too many React frontends where fetch calls were scattered across components, tokens were read from localStorage in twelve places, and adding one protected page meant touching five files. When I built the frontend for my SaaS starter kit, I set five structural rules. Here's how they work, with the real code.

1. One API client module — components never touch HTTP directly

Everything goes through a single axios instance in src/api/client.js: base URL from env, a request interceptor attaching the Bearer token from localStorage, and a response interceptor that on 401 clears the token and redirects to /login (skipping /login and /register themselves). Base URL from env, token attached automatically, expired sessions handled globally. When an endpoint changes, you edit one file. Components import this client and call it — they never construct URLs or headers themselves.

2. Auth state lives in one context

A single AuthContext owns the session: user, token, loading state, and login/register/logout functions. On mount it restores the session from the stored token. Logout is best-effort by design — the session is cleared locally no matter what the server says. No component ever reads localStorage directly. If you change how sessions work, there's exactly one place to change it.

3. Route guards, not scattered checks

Protected pages are wrapped, not conditionally rendered inside page components: a ProtectedRoute that shows a spinner while loading and redirects to /login without a session, plus an AdminRoute adding a role check. The loading state matters more than people think — without it, the app flashes the login page on every refresh while the session restores.

4. Layout is a component, pages are just content

The dashboard shell — sidebar, topbar, content area — is a single Layout component. New pages are just content dropped into it. Adding a settings page means writing the settings content, not rebuilding navigation for the tenth time.

5. Demo mode that doesn't pollute the real code

The kit ships with a clickable demo that runs without a backend. The trick is a seam in exactly one place: const client = isDemoMode() ? createDemoClient() : axios.create({ ... }). A demoMock.js implements the same interface against in-memory data. The rest of the app can't tell the difference. One conditional at the client boundary, zero demo hacks scattered through the UI.

Boring on purpose. Every file has one job, and a new developer can map the whole frontend in an afternoon.

I packaged this frontend together with its Laravel API backend — Sanctum auth, roles, REST conventions, seeders — into a starter kit, because rebuilding this setup on every project was costing me a week each time:

Laravel + React SaaS Starter Kit — $19, one-time: https://kamranofficial.gumroad.com/l/mhekoig

What would you organize differently? Genuinely curious — drop a comment.

How I Structured My Laravel + React SaaS Starter Kit

Kamran Khan — Fri, 09 Oct 2026 18:54:02 +0000

Every SaaS project I take on starts with the same unglamorous week: authentication, user roles, a settings page, a dashboard shell, and arguing with myself about API response shapes. On my third client project I stopped copy-pasting from old repos and built the setup properly — once. This is how it's structured.

The split: API backend, SPA frontend

The reason is practical: sooner or later a dedicated frontend dev touches the project, and a clean API boundary makes that handoff painless.

Auth: Sanctum, kept boring

Laravel Sanctum with token-based auth. Login, register, logout, and a /me endpoint — the standard Sanctum token flow. Password reset and email verification aren't wired up yet (the User model has the MustVerifyEmail import stubbed and commented, ready for you to enable), so the auth surface stays small and honest. I chose Sanctum over Passport deliberately: for a typical SaaS the token flow is simpler and there's less machinery to maintain. The auth layer is isolated, so if you ever outgrow it, you're swapping one controller and a middleware, not rewiring the app.

On the React side, a single axios instance handles everything: base URL from env, an interceptor attaching the token, and a 401 interceptor that clears the session and redirects to login. Auth state lives in one context — components never touch tokens directly.

API conventions: one envelope, no guessing

Responses are plain, predictable Laravel JSON — auth returns the user resource plus the token, and validation errors use Laravel's standard shape keyed by field, which maps 1:1 onto frontend form validation. I kept the response shapes boring on purpose: no custom envelope to learn, no guessing what an endpoint returns.

Roles without the ceremony

A simple role column plus a middleware covers 90% of SaaS needs. The kit ships with admin and user roles and a seeder so you can log in as either immediately.

The React API layer

API access lives in one place — src/api/client.js, a single Axios instance with a token interceptor and a 401 interceptor that clears the session and redirects to login. Components and hooks go through this client; they never construct URLs or headers by hand. When an endpoint changes, you edit one file.

Billing: bring your own Stripe

There's no billing code in the kit — no subscriptions table, no webhooks, no Stripe SDK. That's deliberate: I've seen too many projects drag in payment machinery before they have a single user. When you're ready to charge, Laravel Cashier plus a subscriptions migration slots straight into the auth and user scaffolding that's already here.

I packaged all of this into a starter kit because I was tired of rebuilding it. If you'd rather skip week zero and start on your actual product, it's here:
Laravel + React SaaS Starter Kit — $19, one-time: https://kamranofficial.gumroad.com/l/mhekoig
Questions about any of the structural choices? Drop a comment — happy to dig in.