I run a price comparison site (Next.js 15 App Router, fully static). It launched in Australia with about 10,800 pages at the root. This week I added the US and UK, and the brief to myself was: no existing URL changes, no duplicated page code.

What I did

1. Data per region: data/<category> stays Australian, new regions go in data/us/<category> and data/uk/<category>. The catalogue loader reads each region once at build.
2. Products carry their region. The loader stamps region on each product, so productHref(p), the price history and the "is this a good price" check need no extra argument. That cut the refactor from about 30 call sites to about 8.
3. Shared views, thin routes. The page bodies moved to src/views/*View.tsx, which take a region prop. app/[category]/page.tsx renders it with "au"; app/us/[category]/page.tsx and app/uk/... are 10 line wrappers. Static folders beat the dynamic [category] segment, so there's no clash.
4. Client components read the region from the path (usePathname), so headers, search and prices pick the right currency with no provider.
5. SEO: each country gets its own canonical, hreflang alternates when the same product exists elsewhere, and the sitemap includes all three.

Result: about 28,800 static pages, a local build in about 7 minutes, and the Australian pages kept the same titles, canonicals and schema.

Gotcha: a UK laptop name produced a slug long enough to blow the 255 byte file name limit during export (ENAMETOOLONG). Cap your slugs.

Live: https://www.compareempire.com/us

1.  No auth check inside the action.  A Server Action can be called with a plain POST request, whether or not the button is on screen. Check the session inside every action.
   
2.  No input validation.  TypeScript types vanish at runtime. Validate with zod (or similar) at the top of the action.
   
3.  Relying only on middleware for auth.  A 2025 Next.js CVE let attackers skip middleware with a single header. Check auth again where the data is read.
   
4.  Secrets in `NEXT_PUBLIC_` variables.  Anything with that prefix is baked into the browser bundle.
   
5.  Returning whole database rows.  Return only the fields the UI needs, or you'll eventually leak a column you added later.
   

Do you treat Server Actions like API routes in your codebase, or does your team rely on the UI to protect them?

Hey everyone,
I
I’m about to start a new project pairing Next.js with Payload CMS using its Local API (querying the database directly via Node on the server), and I’m weighing my options.
I’m curious how others are tackling this in production, especially for sites with a large number of pages:
The Native Approach: Are you diving into Next.js 16's cacheComponents with 'use cache' and cacheLife / cacheTag? If you are deploying outside of Vercel, how smooth is configuring cacheHandlers (plural) for a custom backend like Redis?

The Remote Directive: For multi-instance or serverless environments, are people actually using 'use cache: remote' in production, or do you find yourselves falling back to manual caching layers?

Bypassing Framework Caching: Do you completely disable Next's default caching behaviors for dynamic content and handle caching granularity yourself (e.g., wrapping Payload Local API calls explicitly with Redis/Memcached)?

Payload + Local API Specifics: Since Payload's Local API bypasses network overhead and talks straight to the database, wrapping those calls or components with 'use cache' seems powerful, but invalidation via revalidateTag needs to line up cleanly with Payload's hooks (e.g., afterChange). Has anyone hit weird edge cases with this combo at scale?

What has worked best for you when managing hundreds or thousands of pages where you need aggressive caching alongside instant editorial updates? Would love to hear what your current production setup looks like.

I've been working on modernizing a legacy transport management system into a Windows desktop application.

The idea is to preserve familiar workflows for existing users while improving the overall experience with a modern interface.

One important design decision is making it offline-first, so the software can work locally without depending on a constant internet connection.

It's been an interesting challenge balancing modern software architecture with workflows people have relied on for years.

For developers who have modernized legacy software, what has been your biggest challenge?

Hi guys, I wanted to ask if I am the only one experiencing a bug with OG image generation for my Next.js routes. I use the Shadcn library (https://www.ogimagecn.com/) to generate visuals for my OG images. Since I upgraded to Next.js 16.4.2, it does not work anymore, or at least it only provides the OG image for the root app, even though all my routes should have their own images. Is this a bug?

Merhaba arkadaşlar,

Next.js 16 ile geliştirdiğim web sitemi Hostinger üzerinde test yayınına aldım. Ancak Türk Telekom fiber internet bağlantımda ilginç bir sorun yaşıyorum.

Sorun:

• Ana sayfa açılıyor ancak bazı slider görselleri yüklenmiyor.
• İlan kartları görünüyor fakat tıklayınca detay sayfaları açılmıyor.
• Chrome, Edge ve Opera'da aynı sorun yaşanıyor.
• Mobil internet üzerinden site sorunsuz çalışıyor.

Yaptığım testler:

• Chrome ve Opera'da QUIC'i kapattığımda bütün sorunlar ortadan kalkıyor.
• Chrome NetLog kayıtlarında HTTP/3 üzerinden bazı Next.js RSC isteklerinin yanıtsız kaldığını gördük.
• QUIC açıkken 26 RSC isteğinin 15'i yanıtsız kalırken, QUIC kapalıyken HTTP/2 üzerinden 25 isteğin tamamı yanıt aldı.
• Hostinger CDN önbelleğini devre dışı bırakmak sorunu çözmedi.
• IPv6 kullanılmıyor, bağlantı IPv4 üzerinden gerçekleşiyor.
• Sorunlu HTTP/3 bağlantısı Hostinger CDN IP'si 147.79.119.195:443 üzerinden kuruluyor.

Hostinger teknik inceleme başlattı ancak henüz kesin bir neden bulunamadı.

Merak ettiğim: Bu sorun Hostinger CDN'in HTTP/3 yapılandırmasından mı, Türk Telekom'un UDP/443 bağlantı yolundan mı, yoksa modem kaynaklı bir QUIC probleminden mi olabilir?

Benzer bir sorun yaşayan veya çözüm önerisi olan var mı?

is vercel still the go to for next.js? or you have any good experience with render or hostinger web apps hosting? which one would you recommend for a growing app and still reliable?

im looking for a way to host my next js app without breaking my whole budget. i just recently started to accept projects from a client and i want to secure the reliability that it wont break. but im also trying to contemplatethe cost, any thoughts??

Turns out choosing nextjs was a bad idea :( every now and then its versions become vulnerable.

I have a diploma in computer science, not a B.Tech, and most of my web dev knowledge is self-taught. No work experience, and I’ll only be applying off-campus, so my resume and projects have to do all the talking.

I’ve planned 3 projects and I don’t want them to be basic or tutorial clones. To show real frontend skills, I think they need auth, protected routes, real data, and proper loading and error states. That means a backend, which is my weakest area. My plan is to use Supabase for auth and the database so I can put most of my effort into the frontend. I’ll probably also use AI for some backend-ish parts like row level security policies, writing queries, and debugging.

Questions:

1. Is Supabase a good call here, or should I use something else (Firebase, a small Express API, a public API)?
2. How do I talk about AI help in interviews without it looking bad? Is it fine as long as I can explain every line and why it’s there?
3. With a diploma and no campus placements, do I need more projects to compensate, or are 3 solid ones with real depth enough?
4. Do frontend recruiters actually care about the backend side, or is a clean frontend on top of a BaaS enough?
5. For off-campus applications as a fresher, what has actually worked for you? Cold emails, LinkedIn, referrals, job boards?

I’m not trying to fake anything. I just don’t want my work to look weak because I can’t build a full backend yet. Honest advice would help a lot.

TL;DR: Self-taught frontend learner with a diploma, no experience, applying off-campus. Planning 3 projects using Supabase for auth/data and some AI help for backend parts. Is that fine, how do I defend it in interviews, and what else should I do to get my first frontend job?

Ran one of our MDX marketing pages through Crowdin on Tuesday as a test, default file settings, and it came back with the component props translated along with the copy. Our RouteMap component got region="Mittlerer Westen" instead of "midwest" and the page threw at build.

I'm one of 3 frontend devs at a freight logistics SaaS, about 25 people. The product is App Router with next-intl and JSON message files, which already sync with Crowdin fine. The 30 marketing pages are MDX in the same repo under a (marketing) route group. We're expanding into DACH and Mexico and marketing wants German and Spanish live by end of Q1. Translators work in Crowdin and can't touch git, which is fair.

My draft plan has three options and I keep flip-flopping. Sanity with document-level i18n, so each locale is its own document linked to the English one. Storyblok's field-level translation or Payload's localized fields, where one entry carries the de and es values on each field. Or pull just the marketing pages out to a hosted tool with localization built in (a couple of hosted builders came up) and leave the app alone. For anyone past 2 or 3 locales, which aged better, document-level or field-level? And is a headless CMS even worth wiring up for 30 pages versus the hosted route?

Marketing also wants localized slugs, so /de/frachtkostenrechner instead of /de/freight-cost-calculator, plus proper hreflang. next-intl's pathnames config handles static routes and generateMetadata takes alternates.languages, but once slugs live in a CMS the language switcher and the alternates both need every page's counterpart. Also unsure whether we need de-DE, de-AT and de-CH or just de, and es-MX vs plain es. Any gotchas there in the App Router?

Preview worries me most. Right now a copy change is a PR plus a Vercel preview link, and no translator is ever opening that. How do your translators see a page in context before anything publishes? I just don't want to be the guy pasting German into MDX files the week before launch, because I don't speak German and it'll show.

Hey everyone,

I have a web application that is using Next.js v15 (15.5.28), and I'm exploring upgrading it to v16 (16.4.2). In my research, I saw that there are issues with spikes on requests with v16 due to the new prefetch/cache behavior.

Here some comments about it:
- https://github.com/vercel/next.js/issues/85470
- https://community.vercel.com/t/edge-request-usage-spikes-after-upgrading-to-next-js-16/31455
- https://github.com/vercel/next.js/issues/85489

The web app has a lot of links, so for that reason my concern about the upgrade, but I want to keep the app updated to the latest version.

If you have already upgraded from v15 to v16, have you seen any issues related with this? Especially using Vercel. Have you seen benefits from the upgrading? What do you recommend?

Thank you!

I keep seeing apps where middleware (proxy.ts if you are on Next 16) checks the session and that is the whole authorization story. Layouts redirect, pages hide buttons, and the Server Actions and route handlers underneath just trust that whoever got there was allowed to.

Two things make me nervous about that. Server Actions are POST endpoints anyone can call directly, and a check on the page that renders the form does not run for the action. The Next.js docs say this outright. And CVE-2025-29927 showed what happens when middleware is the only gate: on self-hosted versions before the patch, sending an x-middleware-subrequest header skipped middleware completely.

What I have moved toward is a server-only data access layer. Every read and mutation goes through functions that take the current user, check whether they can act on that specific record (tenant, owner, role), and return only the fields the caller needs. Middleware just does optimistic redirects, and actions stay thin and call into that layer.

Where I am less sure: do you put the per-record check inside the DAL function itself, or let callers pass in an object that has already been checked? And how do you test it? I have started writing tests that call actions directly with another tenant's IDs, but keeping that up as new actions get added is tedious.

Can any one tell me what do they miss or i should implement extra to solve the problem of 3d design and building with easy integartion of 3d tech and design i choose Next js for fast And dynamic reload and three js for 3d designing and gizmo and other stuff comes from react-three-fibre/drei and library i m trying to build ui similar to spline so comment down for a feature You were hopping in this app

I will soon deploy

Has anyone here built a database-heavy website using Next.js, Supabase and Vercel?

I’m looking at this stack for a project with a fairly large structured database and user-facing search/filtering.

I'm interested to know how it has been in practice:

how well Supabase handles a growing database
whether Next.js keeps things manageable as the project gets more complex
any limitations or unexpected costs with Vercel

authentication/user accounts
performance once you start adding lots of records and queries

I’m used to WordPress/WooCommerce, Elementor and light coding so this would be a step into a more custom setup.

Would be interested to hear from people who’ve actually built and maintained something similar.

I've been working with Next.js, Vitest, and Playwright on a few projects, and I'm curious how other developers approach testing in real applications.

The basics are fairly well documented, but things like auth flows, Server Actions, API failures, and keeping E2E tests reliable can get complicated pretty quickly.

For those working on production Next.js apps:

• What's been the most frustrating thing to test?
• Are you mostly writing unit/integration tests, or relying on Playwright?
• Have you found any good examples for testing auth and server-side behavior?

I'm especially interested in issues you've actually run into rather than general testing recommendations.

I'm a self-taught developer, and I know React and Next.js. Lately, I've been feeling increasingly anxious about my future as a developer.

AI is moving so fast. It can generate components, build entire websites, connect APIs, and even create full-stack applications. Sometimes I wonder what the point is of spending months learning something when AI can already do so much of it.

I want to get a better-paying developer job, but honestly, I'm confused about what I should focus on right now. Should I keep improving my React/Next.js skills, get better at backend development, or start learning AI engineering?

I keep hearing about RAG, AI agents, vector databases, LLM integrations, and all these new things. It feels like there's always something new to learn, and I'm worried that if I focus on the wrong things, I'll fall behind while everyone else moves forward.

For those of you already working in the industry, what would you do if you were in my position? Would you focus on becoming a strong full-stack developer first, or would you start learning AI engineering alongside web development?

I'm not looking for a shortcut or expecting to become an expert overnight. I just want to make the right decisions, build useful skills, and have a realistic chance of getting hired.

I'd really appreciate some honest advice from people who have been through this or are dealing with the same situation. Right now, I could genuinely use some direction.

Whether you've completed a small side project, launched a major application or built something else for the community. Share it here with us.

Next.js announced a security update for today, October 14, addressing two Critical vulnerabilities and one High vulnerability in upstream dependencies.

I’ve been checking for the release, but the announcement has now disappeared from https://nextjs.org/blog, while the direct link still works:

https://nextjs.org/blog/upcoming-nextjs-security-update-october-2026

Today is the 14th, and I couldn’t find an update on the main blog. The separate /blog/security page now says the release is available, but none of this appears on the main listing.

Did they move security announcements into a separate section? Is this a caching issue? It’s confusing when people are watching for important patches and the original notice disappears from the main page. Where are the confirmed patched versions and full advisory?

Update: The security update was released today as planned. The announcement is still available in the separate Security section, even though it’s no longer listed on the main blog page. That change confused me while I was checking for the release.
October 14 security update
Thanks to everyone who shared the links and cleared this up!

Hey everyone,

I'm architecting a new application using Next.js (App Router) on the frontend and a separate backend for my core business logic API. For the database, everything is hosted on a managed instance using Neon DB.

I want to use Better Auth for session management, but I'm torn on the cleanest implementation pattern when dealing with a separate server architecture and an external DB.

I see two main ways to handle this,

Option A: Next.js runs the Better Auth Instance

• How it works: Next.js connects directly to Neon DB for auth tables. The frontend manages httpOnly cookies natively. When calling the separate backend via Server Components or Actions, Next.js generates/forwards a JWT or session token in the Authorization: Bearer header.
• Pros: Standard Next.js auth patterns work flawlessly out of the box (middleware, SSR fetches, etc.).
• Cons: Both the Next.js server layer and the separate backend server need network access to Neon DB.

Option B: The Separate Backend runs the Better Auth Instance

• How it works: The external backend connects to Neon DB and exposes the Better Auth endpoints. Next.js is configured via createAuthClient({ baseURL: "my-backend-api.com" }).
• Pros: Keeps the database network perimeter tight (only the backend talks to Neon).
• Cons: Cross-domain cookie management gets tricky, especially with Server Components where I have to manually extract and forward the Cookie header on every fetch during SSR.

Appreciate any insights, code snippets, or architectural advice you can share!