<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Laravel on Gaurav.dev</title><link>/tags/laravel/</link><description>Recent content in Laravel on Gaurav.dev</description><generator>Hugo</generator><language>en-US</language><copyright>© 2026 Gaurav. Built with care and clean code.</copyright><lastBuildDate>Thu, 24 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="/tags/laravel/index.xml" rel="self" type="application/rss+xml"/><item><title>How to Choose a Modern Web Stack Without Regretting It</title><link>/posts/choosing-modern-web-stack/</link><pubDate>Thu, 24 Sep 2026 00:00:00 +0000</pubDate><guid>/posts/choosing-modern-web-stack/</guid><description>&lt;p&gt;The best technology stack is rarely the one with the longest feature list. It is the one your team can operate confidently while the product changes around it.&lt;/p&gt;&#10;&lt;h2 id="start-with-constraints"&gt;Start with constraints&lt;/h2&gt;&#10;&lt;p&gt;Before comparing frameworks, write down the facts: expected traffic, search requirements, real-time behaviour, integrations, compliance, team experience, delivery date, and operating budget. These constraints eliminate more options than a benchmark ever will.&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;Next.js&lt;/strong&gt; is a strong default for content-rich products that also need application behaviour. It offers flexible rendering, a broad React ecosystem, and a straightforward path to full-stack TypeScript. Its flexibility also means the team must be disciplined about caching and server/client boundaries.&lt;/p&gt;</description></item><item><title>Designing a Laravel API That Can Grow</title><link>/posts/laravel-api-at-scale/</link><pubDate>Sat, 12 Sep 2026 00:00:00 +0000</pubDate><guid>/posts/laravel-api-at-scale/</guid><description>&lt;p&gt;Laravel makes the first version of an API pleasantly fast. The architectural work is making the hundredth feature just as understandable as the first.&lt;/p&gt;&#10;&lt;h2 id="keep-transport-separate-from-business-rules"&gt;Keep transport separate from business rules&lt;/h2&gt;&#10;&lt;p&gt;Controllers should translate HTTP into an application request and translate the result back. Validation belongs in request objects; serialisation belongs in resources. Business decisions should live in focused application services or domain objects that can run without pretending an HTTP request exists.&lt;/p&gt;</description></item></channel></rss>