Frontend with Laravel

1) The frontend engineer’s role in a Laravel context
Laravel is more than a PHP framework—it is an opinionated platform that streamlines conventions around routing, data shaping, authentication, and security. For frontend engineers, this means faster integration cycles and fewer ambiguities, provided we align with Laravel’s strengths: predictable endpoints, first-class authentication primitives, and a clear asset pipeline (Vite).

2) Choose an integration model that fits your product
There is no single best approach. Decide based on team expertise, delivery speed, and the nature of the UI.
- Blade + Progressive Enhancement (e.g., Alpine/Stimulus/htmx): Server-rendered HTML with small, focused JS. Ideal for admin panels, content sites, and workflows where SEO and simplicity matter.
- Livewire: Server-driven components with minimal custom JS. Great for CRUD-heavy internal tools, forms, and data grids when you want reactive behavior without a full SPA.
- Inertia.js (Vue/React/Svelte): SPA experience with Laravel routing, controllers, and middleware retained. Ideal for teams wanting SPA ergonomics without building and maintaining a separate API layer.
- API-first SPA/SSR (Next.js/Nuxt/SvelteKit): Fully decoupled frontend consuming Laravel APIs. Best for complex frontends, multi-channel clients, and organizations standardizing on Node.js SSR and edge rendering.

Decision prompts:
- Product velocity: Blade/Livewire/Inertia typically ship fastest with smaller teams.
- Complex state management, offline features, or micro-frontends: lean API-first.
- SEO + dynamic interactions but minimal JS complexity: Blade or Inertia.

3) Data contracts: keep them explicit and stable
Use Laravel API Resources to normalize JSON responses, hide internals, and version your output. This narrows the surface for breaking changes and gives frontend devs a dependable shape to code against.
- Favor Resource classes over raw arrays.
- Standardize pagination, error formats, and dates.
- Document payloads (OpenAPI/Stoplight) and generate types for the frontend.

Minimal example (two lines shown for shape only):
return new UserResource($user);
return UserResource::collection(User::paginate());

4) Authentication and session model
Prefer Laravel Sanctum for first-party SPAs and Inertia apps—it provides cookie-based auth with CSRF protection and simpler DX than OAuth for same-origin/frontends on the same top-level domain.
- Enforce HTTPS, SameSite, and short-lived tokens.
- For third-party or mobile clients, use OAuth (Laravel Passport) and explicit scopes.
- Align on a single login flow; avoid mixing multiple auth models unnecessarily.

Minimal example with axios and Sanctum (two lines):
axios.defaults.withCredentials = true;
await axios.get('/api/user');

5) Routing, URLs, and discoverability
- Keep route names canonical; expose them to the frontend where helpful (e.g., Ziggy for JS route generation).
- If API-first, version routes (/api/v1) and constrain breaking changes to new versions.
- Use consistent query conventions for filters, sorting, includes, and sparse fieldsets.

6) Real-time, uploads, and media
- Broadcast domain events via Laravel Echo (Pusher/Soketi) for notification UIs and live dashboards; agree on channel names and payload shapes.
- Use signed URLs for uploads/downloads to keep S3/GCS direct interactions secure.
- Define clear limits for file size and MIME types; return actionable error messages.

7) Internationalization, time, and formatting
- Share the active locale and timezone from Laravel to the frontend (headers or bootstrap payloads).
- Normalize times to ISO 8601 UTC in APIs; format in the client for the user’s locale.
- Keep translation keys consistent; avoid hard-coded copy in components.

8) Collaboration routines
- Contract-first mindset: define or update Resources/OpenAPI before UI implementation.
- Add sample responses and fixtures to the repo for frontend tests.
- Use ADRs (Architecture Decision Records) to capture why a particular integration model or library was chosen.

1) Tooling stack aligned with Node.js and Laravel
- Vite as the standard asset bundler via laravel-vite-plugin. Use ES modules, TypeScript, and modern CSS tooling (PostCSS/Tailwind if applicable).
- Keep Node on active LTS; standardize on a package manager (pnpm or npm) and lockfile.
- Directory conventions: resources/js for app code, resources/css for styles, public/build for compiled assets. Add a simple alias for clean imports.

One-line idea: alias '@' -> 'resources/js' to simplify imports.

2) Developer experience
- Type safety: TypeScript by default; generate API types from OpenAPI or from backend Resources (e.g., spatie/laravel-typescript-transformer) to prevent drift.
- Linting/formatting: ESLint + Prettier; enforce on CI.
- Environment management: .env for Laravel, .env.* for frontend. Document required variables and provide .env.example.
- Local environment: Laravel Sail or a Docker Compose profile; seeders and factories that generate realistic UI data.

3) Framework choices and patterns
- Inertia: co-locate pages/components under resources/js/Pages; SSR is optional but helpful for TTI and SEO. Keep controllers lean; move presentation logic into components.
- Livewire: define component boundaries carefully; avoid heavy DOM diffs; offload expensive work to queues where possible.
- API-first SPA: maintain a thin client for requests (axios/fetch wrapper) that centralizes auth, retries, and error normalization.

4) Testing and quality gates
- Backend: feature tests (Pest/PHPUnit) validate endpoints, Resources, policies, and error formats.
- Frontend: unit tests with Vitest/Jest + Testing Library; E2E with Playwright/Cypress. Supply fixtures from backend factories to ensure realism.
- Contract tests: run a schema check (OpenAPI validation) in CI; detect breaking changes early.
- Visual and a11y: Storybook with snapshot/contrast checks; axe for accessibility.

5) Build and CI/CD
- CI steps: install PHP deps, install Node deps, run tests, build assets (vite build), cache results.
- Use asset versioning (vite manifest) and immutable cache headers at the edge.
- Blue/green or zero-downtime deploys; run database migrations with compatibility in mind (add new fields first, then ship UI; remove fields last).
- For monorepos: define separate pipelines for API and frontend apps; share a UI library via workspaces.

6) Observability in development
- Laravel Telescope for request introspection; turn off in production.
- Request IDs: propagate an X-Request-ID from Laravel to the client logs; correlate frontend errors (Sentry/Bugsnag) with server logs.
- Feature flags: Laravel Pennant to roll out UI changes gradually and reduce risk.

7) Performance-by-default
- Code-splitting with Vite dynamic imports; lazy-load heavy views.
- Images: pre-generate responsive variants; use modern formats (WebP/AVIF) and a CDN.
- API pagination and server-side filtering to minimize payloads; prefer includes over many round-trips.
- On the server: cache configuration/routes, tune database queries, and use response caching for read-heavy endpoints.

1) Production readiness: performance and resilience
- Frontend bundles: monitor size and composition; set budgets in CI and fail builds when thresholds are exceeded.
- Caching: immutable assets with long TTLs; HTML/API responses with smart cache headers (ETag/Last-Modified) and edge caching where appropriate.
- Real-time: choose a managed or self-hosted WebSocket layer (Pusher/Soketi) and test reconnection/backoff behavior.
- Degradation strategy: design views that tolerate partial data, slow endpoints, and feature flag rollbacks.

2) Security posture
- CSRF protection via Sanctum for first-party SPAs; Blade auto-escaping for server-rendered views.
- CORS: restrict origins and methods; prefer cookie-based auth for same-site apps.
- Rate limiting on public APIs and sensitive endpoints; add captcha or proof-of-work where abuse is likely.
- CSP headers (e.g., spatie/laravel-csp) to reduce XSS risk; avoid unsafe-inline.
- File safety: validate MIME types on server; use temporary, signed upload URLs.

3) Internationalization, accessibility, and compliance
- Locale negotiation at the edge or in middleware; pass locale/timezone to the client and cache per locale.
- Accessibility gates in CI; document WCAG standards as non-negotiable.
- Privacy: map data events to consent states; ensure analytics scripts respect user choices and CSP.

4) Change management and compatibility
- Backward-compatible API changes by default; version-breaking changes deliberately and communicate timelines.
- Use Resource transformers to deprecate fields gracefully; keep a changelog for clients.
- Staged rollouts: introduce additive server changes, deploy frontend that uses them, remove deprecated paths last.

5) Monitoring and feedback loops
- Capture errors and performance traces on both client (Sentry/Bugsnag) and server (logs/APM). Correlate via request IDs.
- Establish SLOs for latency and error rates; alert on regressions.
- Add product analytics with event schemas reviewed by engineering and privacy teams.

6) Practical checklists
- Before merge: contracts updated, types regenerated, tests green, bundle size within budget.
- Before deploy: database migrations compatible, feature flags ready, roll-back plan documented.
- After deploy: dashboards monitored, error budgets reviewed, user feedback channels watched.

Key takeaway: pick the integration model that matches your product and team, invest in explicit contracts (Resources + types), leverage Laravel’s batteries (Sanctum, Vite, Resources, queues), and apply disciplined frontend engineering practices (testing, performance budgets, observability). This blend yields predictable delivery and enterprise-grade reliability.