[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-nuxt-3-end-of-life-ssr-ssg-hybrid":3,"blog-nav-nuxt-3-end-of-life-ssr-ssg-hybrid":27},{"slug":4,"title":5,"description":6,"body":7,"category":8,"readTime":9,"tags":10,"coverImage":14,"coverImageAlt":15,"heroImage":16,"heroImageAlt":15,"metaTitle":17,"metaDescription":18,"ogImage":19,"noindex":20,"published":21,"publishAt":22,"sortOrder":23,"updatedAt":22,"status":24,"path":25,"bodyHtml":26},"nuxt-3-end-of-life-ssr-ssg-hybrid","Nuxt 3 is end of life. Choose a rendering mode on Nuxt 4","Nuxt 3 support ended 31 July 2026. Stay on Nuxt 4, pick static, server, or client per route, and do not ship a Nuxt 5 preview.","Nuxt 3 reached end of life on **31 July 2026**. The Nuxt team said so in the [4.5.0 release notes](https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt\u002Freleases\u002Ftag\u002Fv4.5.0). By October, a production site still on Nuxt 3 is already off that support line.\n\nThe replacement is Nuxt 4, not a preview of Nuxt 5. On 13 October 2026, npm `latest` is **4.6.1**. There is no Nuxt 5 dist-tag. The [upgrade guide](https:\u002F\u002Fnuxt.com\u002Fdocs\u002Fgetting-started\u002Fupgrade) still describes Nuxt 5 as in development, with `future.compatibilityVersion: 5` as a way to try breaking changes early.\n\n## Do not ship the preview\n\n`compatibilityVersion: 5` is for finding what will break. It is not a production target. Stay on the 4.x line until Nuxt 5 is released and the modules you actually use have caught up. Feeling current is not a deploy plan.\n\n## Pick the mode per route\n\n[How we build scalable web applications](\u002Fblog\u002Fhow-we-build-scalable-web-applications) already puts Nuxt on the public side of a Laravel system. It does not say how each route should render. That choice is the one that changes cost, crawlability, and what the user sees before JavaScript runs.\n\n| Mode | Use it when | Do not use it when |\n|------|-------------|--------------------|\n| Prerender \u002F static | Brochure pages, docs, prices that change when you deploy | The HTML must include live stock or the logged-in user |\n| Server render | Public pages that must be fresh and readable without waiting on the client | Every authenticated click, if you are paying for HTML nobody indexes |\n| Client only | Admin and tools behind login | The marketing homepage |\n\nHybrid means those rules live on routes in one app. The public site can be prerendered or server-rendered. The logged-in tool can be client-rendered. You do not need a second frontend to get that split.\n\n[What a 95+ Lighthouse score actually means](\u002Fblog\u002Fwhat-95-lighthouse-actually-means) measures the result. This article is which renderer you asked for. A slow server render is not fixed by calling the page static, and a static page is the wrong tool when the data is the product.\n\n## Moving off Nuxt 3\n\n1. Follow the upgrade guide and run the app on Nuxt 4 in staging before you touch production.\n2. List routes. Mark each as public content, live data, or an authenticated tool.\n3. Set route rules to match that list. Do not flip the whole site to a client-only app because one dashboard needed it.\n4. Re-check the pages that matter in a browser, including a mid-range phone. The mode is not an excuse for a heavy client bundle.\n\n## Straight next step\n\nIf the public site and the logged-in tool are one Nuxt app and you are not sure which routes should be static, [send the route list](\u002Fcontact). We will mark the mode per route. We will not propose a Nuxt 5 upgrade that has not shipped.","Engineering",7,[11,12,13],"Nuxt","Rendering","Web","\u002Fimages\u002Fjournal\u002Fnuxt-3-end-of-life-ssr-ssg-hybrid-cover.webp?v=20261013b","HTML and SVG markup on a screen","\u002Fimages\u002Fjournal\u002Fnuxt-3-end-of-life-ssr-ssg-hybrid-hero.webp?v=20261013b","Nuxt 3 Is End of Life. Rendering on Nuxt 4 | PrimeCode","Nuxt 3 support ended 31 July 2026. How to choose SSR, static, or hybrid on Nuxt 4, and why Nuxt 5 is not the October upgrade.","\u002Fimages\u002Fjournal\u002Fnuxt-3-end-of-life-ssr-ssg-hybrid-og.webp?v=20261013b",false,true,"2026-10-05T01:00:00.000Z",47,"live","\u002Fblog\u002Fnuxt-3-end-of-life-ssr-ssg-hybrid","\u003Cp>Nuxt 3 reached end of life on \u003Cstrong>31 July 2026\u003C\u002Fstrong>. The Nuxt team said so in the \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fnuxt\u002Fnuxt\u002Freleases\u002Ftag\u002Fv4.5.0\" rel=\"noopener noreferrer\">4.5.0 release notes\u003C\u002Fa>. By October, a production site still on Nuxt 3 is already off that support line.\u003C\u002Fp>\n\u003Cp>The replacement is Nuxt 4, not a preview of Nuxt 5. On 13 October 2026, npm \u003Ccode>latest\u003C\u002Fcode> is \u003Cstrong>4.6.1\u003C\u002Fstrong>. There is no Nuxt 5 dist-tag. The \u003Ca href=\"https:\u002F\u002Fnuxt.com\u002Fdocs\u002Fgetting-started\u002Fupgrade\" rel=\"noopener noreferrer\">upgrade guide\u003C\u002Fa> still describes Nuxt 5 as in development, with \u003Ccode>future.compatibilityVersion: 5\u003C\u002Fcode> as a way to try breaking changes early.\u003C\u002Fp>\n\u003Ch2>Do not ship the preview\u003C\u002Fh2>\n\u003Cp>\u003Ccode>compatibilityVersion: 5\u003C\u002Fcode> is for finding what will break. It is not a production target. Stay on the 4.x line until Nuxt 5 is released and the modules you actually use have caught up. Feeling current is not a deploy plan.\u003C\u002Fp>\n\u003Ch2>Pick the mode per route\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"\u002Fblog\u002Fhow-we-build-scalable-web-applications\" rel=\"noopener noreferrer\">How we build scalable web applications\u003C\u002Fa> already puts Nuxt on the public side of a Laravel system. It does not say how each route should render. That choice is the one that changes cost, crawlability, and what the user sees before JavaScript runs.\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Mode\u003C\u002Fth>\n\u003Cth>Use it when\u003C\u002Fth>\n\u003Cth>Do not use it when\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Prerender \u002F static\u003C\u002Ftd>\n\u003Ctd>Brochure pages, docs, prices that change when you deploy\u003C\u002Ftd>\n\u003Ctd>The HTML must include live stock or the logged-in user\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Server render\u003C\u002Ftd>\n\u003Ctd>Public pages that must be fresh and readable without waiting on the client\u003C\u002Ftd>\n\u003Ctd>Every authenticated click, if you are paying for HTML nobody indexes\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Client only\u003C\u002Ftd>\n\u003Ctd>Admin and tools behind login\u003C\u002Ftd>\n\u003Ctd>The marketing homepage\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>Hybrid means those rules live on routes in one app. The public site can be prerendered or server-rendered. The logged-in tool can be client-rendered. You do not need a second frontend to get that split.\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"\u002Fblog\u002Fwhat-95-lighthouse-actually-means\" rel=\"noopener noreferrer\">What a 95+ Lighthouse score actually means\u003C\u002Fa> measures the result. This article is which renderer you asked for. A slow server render is not fixed by calling the page static, and a static page is the wrong tool when the data is the product.\u003C\u002Fp>\n\u003Ch2>Moving off Nuxt 3\u003C\u002Fh2>\n\u003Col>\n\u003Cli>Follow the upgrade guide and run the app on Nuxt 4 in staging before you touch production.\u003C\u002Fli>\n\u003Cli>List routes. Mark each as public content, live data, or an authenticated tool.\u003C\u002Fli>\n\u003Cli>Set route rules to match that list. Do not flip the whole site to a client-only app because one dashboard needed it.\u003C\u002Fli>\n\u003Cli>Re-check the pages that matter in a browser, including a mid-range phone. The mode is not an excuse for a heavy client bundle.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>Straight next step\u003C\u002Fh2>\n\u003Cp>If the public site and the logged-in tool are one Nuxt app and you are not sure which routes should be static, \u003Ca href=\"\u002Fcontact\" rel=\"noopener noreferrer\">send the route list\u003C\u002Fa>. We will mark the mode per route. We will not propose a Nuxt 5 upgrade that has not shipped.\u003C\u002Fp>\n",{"prev":28,"next":46,"related":62},{"slug":29,"title":30,"description":31,"category":32,"readTime":9,"tags":33,"coverImage":37,"coverImageAlt":38,"heroImage":39,"heroImageAlt":38,"metaTitle":40,"metaDescription":41,"ogImage":42,"noindex":20,"published":21,"publishAt":43,"sortOrder":44,"updatedAt":43,"status":24,"path":45},"php-82-security-support-ends-december-2026","PHP 8.2 security support ends on 31 December 2026","PHP 8.2 security fixes stop on 31 December 2026. You can move the runtime and stay on Laravel 12. The framework calendar is a different decision.","Trends",[34,35,36],"PHP","Laravel","Upgrades","\u002Fimages\u002Fjournal\u002Fphp-82-security-support-ends-december-2026-cover.webp?v=20261013b","Source code on a computer monitor","\u002Fimages\u002Fjournal\u002Fphp-82-security-support-ends-december-2026-hero.webp?v=20261013b","PHP 8.2 Security Support Ends 31 Dec 2026 | PrimeCode","PHP 8.2 security fixes stop on 31 December 2026. What that means if you stay on Laravel 12, and when PHP 8.3 or 8.4 is the move.","\u002Fimages\u002Fjournal\u002Fphp-82-security-support-ends-december-2026-og.webp?v=20261013b","2026-10-02T01:00:00.000Z",46,"\u002Fblog\u002Fphp-82-security-support-ends-december-2026",{"slug":47,"title":48,"description":49,"category":8,"readTime":9,"tags":50,"coverImage":53,"coverImageAlt":54,"heroImage":55,"heroImageAlt":54,"metaTitle":56,"metaDescription":57,"ogImage":58,"noindex":20,"published":21,"publishAt":59,"sortOrder":60,"updatedAt":59,"status":24,"path":61},"modular-monolith-vs-microservices","When a modular monolith is the better system","One Laravel deployable with explicit modules, until a boundary must ship and fail on its own. A shared database plus a network call is not scale.",[51,35,52],"Architecture","Modules","\u002Fimages\u002Fjournal\u002Fmodular-monolith-vs-microservices-cover.webp?v=20261013b","Software team working together around laptops","\u002Fimages\u002Fjournal\u002Fmodular-monolith-vs-microservices-hero.webp?v=20261013b","When a Modular Monolith Beats Microservices | PrimeCode","When one deployable Laravel application is the better system, and the few cases that justify a second service.","\u002Fimages\u002Fjournal\u002Fmodular-monolith-vs-microservices-og.webp?v=20261013b","2026-10-07T01:00:00.000Z",48,"\u002Fblog\u002Fmodular-monolith-vs-microservices",[63,80,95],{"slug":64,"title":65,"description":66,"category":8,"readTime":67,"tags":68,"coverImage":71,"coverImageAlt":72,"heroImage":73,"heroImageAlt":72,"metaTitle":74,"metaDescription":75,"ogImage":76,"noindex":20,"published":21,"publishAt":77,"sortOrder":78,"updatedAt":77,"status":24,"path":79},"idempotency-keys-webhooks-side-effects","Idempotency keys: one webhook, one side effect","Retries are normal. Store the key with the result and enforce it with a unique constraint so a second delivery cannot create a second row.",6,[69,70,35],"API","Webhooks","\u002Fimages\u002Fjournal\u002Fidempotency-keys-webhooks-side-effects-cover.webp?v=20261013b","Person writing on a printed form","\u002Fimages\u002Fjournal\u002Fidempotency-keys-webhooks-side-effects-hero.webp?v=20261013b","Idempotency Keys for Webhooks | PrimeCode","How an API stores an idempotency key so a retried webhook updates one record instead of creating a second side effect.","\u002Fimages\u002Fjournal\u002Fidempotency-keys-webhooks-side-effects-og.webp?v=20261013b","2026-10-19T01:00:00.000Z",53,"\u002Fblog\u002Fidempotency-keys-webhooks-side-effects",{"slug":81,"title":82,"description":83,"category":8,"readTime":67,"tags":84,"coverImage":86,"coverImageAlt":87,"heroImage":88,"heroImageAlt":87,"metaTitle":89,"metaDescription":90,"ogImage":91,"noindex":20,"published":21,"publishAt":92,"sortOrder":93,"updatedAt":92,"status":24,"path":94},"api-rate-limiting-before-traffic","Rate-limit the API before the expensive routes exist","Login, OTP, search, webhooks, and unbounded page size are the routes to limit first. OWASP API4:2023 is the control, not a new security product.",[69,85,35],"Security","\u002Fimages\u002Fjournal\u002Fapi-rate-limiting-before-traffic-cover.webp?v=20261013b","Padlock resting on a laptop keyboard","\u002Fimages\u002Fjournal\u002Fapi-rate-limiting-before-traffic-hero.webp?v=20261013b","Rate-Limit the API Before Traffic Grows | PrimeCode","Where a Laravel API needs rate limits first — login, OTP, search, and webhooks — and what OWASP API4:2023 actually asks for.","\u002Fimages\u002Fjournal\u002Fapi-rate-limiting-before-traffic-og.webp?v=20261013b","2026-10-16T01:00:00.000Z",52,"\u002Fblog\u002Fapi-rate-limiting-before-traffic",{"slug":96,"title":97,"description":98,"category":8,"readTime":67,"tags":99,"coverImage":101,"coverImageAlt":102,"heroImage":103,"heroImageAlt":102,"metaTitle":104,"metaDescription":105,"ogImage":106,"noindex":20,"published":21,"publishAt":107,"sortOrder":108,"updatedAt":107,"status":24,"path":109},"queues-work-outside-the-http-request","Queues: work that does not belong in the HTTP request","The request commits the booking or the order. Mail, PDFs, webhooks, and exports belong on a worker, and that worker must be safe to retry.",[35,100,51],"Queues","\u002Fimages\u002Fjournal\u002Fqueues-work-outside-the-http-request-cover.webp?v=20261013b","Warehouse aisles of packed orders waiting to move","\u002Fimages\u002Fjournal\u002Fqueues-work-outside-the-http-request-hero.webp?v=20261013b","Queues: Work That Leaves the HTTP Request | PrimeCode","Which web-app tasks belong in a Laravel queue — mail, webhooks, exports — and why a timeout is the wrong place to notice.","\u002Fimages\u002Fjournal\u002Fqueues-work-outside-the-http-request-og.webp?v=20261013b","2026-10-14T01:00:00.000Z",51,"\u002Fblog\u002Fqueues-work-outside-the-http-request"]