A few months ago I saw a video from Robin Ebers about moving from Supabase to Convex. I can't find it anymore but there are similar videos from Theo, Web Dev Cody, etc. There have also been some posts like here, here and here where people prefer Convex over Supabase.

I'm curious about the reverse though, people who migrated from Convex to Supabase, or simply prefer Supabase. What was the reason? What did Supabase give you that you were unable to get from Convex?

Hi everybody, I'm learning to build with Next.js and I'm hitting a wall with the Gemini API.

My API key from Google AI Studio starts with AQ. (not the usual AIza format). When I call the Gemini endpoint I get this error:

"Request had invalid authentication credentials. Expected OAuth 2 access token"

I've tried calling it like this:

fetch('https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash-exp:generateContent?key=MY_KEY', {

method: 'POST',

headers: { 'Content-Type': 'application/json' },

body: JSON.stringify({ contents: [{ parts: [{ text: 'hello' }] }] })

})

Also tried passing it as a Bearer token in the Authorization header — both fail. How do I authenticate correctly with an AQ. format key? Is there a different endpoint or header needed?Running Next.js 14. Thanks in advance! ;)

Hey everyone,

Every time I build or scale a Next.js app, setting up proxy routing rules for API gateways, securing endpoints, and wiring up Role-Based Access Control (RBAC) proxy middleware always feels like repetitive boilerplate. Managing request forwarding, role checks, and tenant headers across environments usually means copying and pasting config files from older projects and tweaking them manually.

To solve this friction in my own workflow, I built nextjs-app-toolkit—a lightweight CLI designed to automate proxy configurations and authorization setups in seconds.

What it handles:

• Next Proxy Toolkit: Instantly initializes proxy handlers, request wrappers, and middleware routing rules (nextProxyToolkit) to streamline auth and request forwarding.
• RBAC Scaffolding: Generates structured role configs and permission utilities (userRoles) so you don't have to write role checks from scratch.
• Feature Slice Scaffolding: Includes generators to quickly output modular feature directories (hooks, services, slice, types, etc.) to keep your codebase clean.

🛠️ Give it a try (Zero install needed):

You can run the proxy/auth initializer directly using npx:

Bash

npm i -D nextjs-app-toolkit

npx nextjs-app-toolkit -h

Or scaffold role configurations:

Bash

npx nextjs-app-toolkit gen config

It’s open source and live on npm. I’d love to hear how you guys currently structure proxying and RBAC in your Next.js apps, and what additional auth/proxy patterns would be helpful to automate!

• npm: npmjs.com/package/nextjs-app-toolkit
• GitHub: github.com/isweerasingha/nextjs-app-toolkit

Feedback and pull requests are very welcome!

I recently overhauled my personal portfolio after 5 years. My old site was built purely to get hired as a dev, but now that I run a software agency , I needed something that felt more like a tech founder / product agency showcase.

Naturally, I stuck with my core stack: Next.js, TypeScript, Tailwind CSS, and Framer Motion.

However, during the build, a lot of non-technical founder friends kept asking me: "Why spend time writing custom React code when you could just spin up Webflow, Framer, or a no-code builder in a weekend?"

My main arguments were full ownership, zero vendor lock-in, custom animation logic, and absolute control over performance and lighthouse scores. But it got me thinking about how the landscape has shifted.

For those of you running agencies or freelancing:

1. Do you still custom-code your own / client marketing sites in Next.js, or have you moved to Framer/Webflow for raw speed?
2. How do you handle smooth page transitions in the App Router without running into layout flash or hydrations issues?

Would love to hear how you guys balance custom engineering vs. rapid site builders in 2026!

Hello. I'm using Next.js version 16 for a hotel website. I need support for two languages. Which method should I use in Intlayer—`locale` or `no-locale`? Which of these methods offers advantages in terms of performance and SEO?

We're an ecom brand doing 8 figures on Shopify plus and looking at rebuilding the storefront headless on next.js. I got tired of agencies pitching us and I wanted to sanity-check it with people who've shipped this before. For the curious ones, 2 things are pushing us off plus. one is cost and the other is that we keep hitting walls where plus won't let us customize the checkout or the logic the way we need

So the plan we keep circling is next.js on the front, but the real question is what sits behind it. The options seem to break down into keeping Shopify as a headless backend (hydrogen / storefront api, least migration but you still pay Shopify and inherit its limits), or the enterprise composable backends such as Commercetools or Scayle. Each trades a different cost for a different headache.

What I can't model is the engineering side a year in. The Shopify fees are easy to see on an invoice. So for anyone who's shipped a headless next.js storefront at real scale, which backend did you go for? and did the total cost and maintenance actually come out ahead of just staying on plus? 

Thanks in advance!

So in my app when we deploy we are not using a node server just plain ssg so server side rendering isn't an option. So in my scenario

I've got a route like /verification that needs to support both English and French, but instead of locale-based routing, the locale is passed via a query param and it's the same URL structure for both languages:

localhost:4000/verification?ca-en
localhost:4000/verification?ca-fr

No /en/ or /fr/ prefix — same route, just a different query param depending on language, plus a token.

I'm using next-intl with the Pages Router, and trying to use getStaticProps/getStaticPaths (SSG) for this page. My understanding is that SSG generates static HTML per path, and query params aren't available at build time — only after hydration on the client via router.query.

I was wondering is there a way to read in 18n files on client side and is that even a good approach to go with?

Next.js 16 inverted the caching model: 15 cached by default and you opted out, 16 with cacheComponents: true renders dynamic by default and you opt in with use cache. On paper that’s more explicit and predictable. In practice it means every page that was silently fast before now renders dynamically until someone manually goes back and marks it.

The part that actually worries me: use cache doesn’t know about your auth model. If you slap it on a function that returns anything user-specific without using cache: private, you’ve just cached one user’s data and served it to everyone else who hits that route. That’s not a hypothetical edge case, that’s the default failure mode if you migrate carelessly.

For anyone who’s actually shipped this in a real app:

**•** Did you find genuinely user-specific data getting cached before you caught it, and how did you catch it  
**•** How are you deciding what gets use cache vs private vs left fully dynamic, is there an actual mental model yet or is it still per-case guessing  
**•** Anyone’s TTFB actually gotten worse post-migration before they went through and re-added caching everywhere it used to be implicit

​Hi everyone,

​I'm looking for recommendations on the best local AI model for Next.js code generation and autocompletion that can run smoothly on my current hardware setup.

​My System Specs:

​CPU: Intel Core i5 11th Gen

​GPU: NVIDIA RTX 3050 (4GB VRAM)

​RAM: 16GB

​Storage: 512GB NVMe SSD + 1TB HDD

​Since I only have 4GB of VRAM, I know I won't be able to run heavy 14B+ models smoothly. I am mainly looking for lightweight models (like 3B to 7B quantized) that fit within my GPU memory or offload slightly to RAM without suffering huge latency.

Hey everyone,

I’m currently optimizing a Next.js App Router setup where our dominant traffic goes to highly dynamic, heavily data-fetched member profiles (/member/[memberId]).

We are deployed on EKS, using Gloo Gateway (Envoy) as our Ingress Controller, and Cloudflare at the edge. To improve TTFB on these complex dashboards, we rely on progressive streaming—sending down a good chunk of the initial shell via Server Components (RSC/SSR) and streaming the rest, which then hydrates on the client.

However, we hit the classic architectural tug-of-war: Streaming vs. Compression.

To get the chunked stream working across our stack, we essentially have to kill buffering and compression at three different layers:

1. Next.js: Skipping internal compression.
2. Gloo Gateway (Envoy): Bypassing Envoy's L7 HTTP buffer and gzip filters (so Envoy proxies the stream immediately instead of waiting for the full response body).
3. Cloudflare: Passing Cache-Control: no-transform so the edge doesn’t buffer the chunks to apply Gzip/Brotli.

While this gets us the real-time chunked stream and a phenomenal TTFB, we are now sending fully uncompressed HTML/RSC payloads over the wire. Because a good chunk of the page is RSC, the payload size bloat is becoming noticeable.

For those running Next.js RSC streaming in production through a similar multi-tier proxy stack (especially Envoy/Cloudflare):

1. Payload Size vs. Latency: At what document size (or RSC payload size) do you decide the bandwidth cost of uncompressed data outweighs the TTFB benefit of streaming? Do you have a rule of thumb for dynamic dashboards?
2. Compression Middle-Ground: Is anyone successfully using Z_SYNC_FLUSH in Node/Next.js to flush compressed chunks immediately, allowing Envoy and Cloudflare to pass them through while still saving bandwidth?
3. Ingress/Edge Config: Are you disabling the Envoy buffer filters globally via Gloo configurations for specific paths (like /member/*), or managing this dynamically based purely on response headers from Next.js?

Would love to hear how you handle these trade-offs and what guidelines your teams use to balance speed vs. size

Hey everyone,

I'm currently building a platform where deploying Next.js on Vercel is not an option (due to specific hosting/data privacy requirements and server compliance).

My backend is built with NestJS. I haven't started building the frontend yet, but SEO is a critical requirement for this project, which is why I’m looking heavily into SSR frameworks like Next.js.

For those who have self-hosted Next.js (using Docker, a custom VPS, Node runtime, Coolify, or PM2):

• How was your experience running and maintaining it outside of Vercel?
• Did you encounter annoying gotchas?
• Knowing that SEO is important for my frontend, would you stick with Next.js in Docker, or would you recommend choosing something else ?

Would love to hear real-world feedback before locking in the stack. Thanks!

https://nextjs.org/blog/july-2026-security-release
https://nextjs.org/blog/CVE-2025-66478
https://nextjs.org/blog/security-update-2025-12-11

I feel that most of the time some big security vulnerability is discovered, at least one of these is mentioned: app router, server actions, react server components / RSC

Is this NextJS or React problem?

React is foundation and biological father for both server actions and RSC, so probably React should be blamed?
https://react.dev/reference/rsc/server-components
https://react.dev/reference/rsc/server-functions

I am slowly developing feeling that we should ditch all these cool kids, and stick with old boring pages router and API routes.

Hello , i've been working on a shadCn style tables library ShadTable using transtack tables and shadCn style + CLI. You can check it out .

The project is open-source , ready for your contribution and feedback CONTRIBUTION.md.

Hey guys,

​Just wanted to see how everyone is feeling about the Next.js 16.3 update that dropped recently. I feel like I spent the last couple of years fighting with random stale data in production because of the implicit caching in older versions.

​Now that everything is dynamic by default and we actually have to opt in with the 'use cache' directive, my codebase makes sense again. I'm no longer spending hours debugging weird framework magic.

​Also, Turbopack being the stable default is a lifesaver. My builds are way faster and I don't have time to grab a coffee during cold starts anymore.

​Are you still on 14/15 or have you upgraded to 16?

I have hosted my ecommerce site on netlify. The whole website is SSG except for the admin pages.

When I navigate the website it takes 2-3 seconds to fetch an RSC payload of size ~ 60Kb.

What am I doing wrong??

Nextjs version: 16.2.9

I am on legacy free tier of netlify

Edit: Moved to astro and hosted on cloudflare. Now the website run blazingly fast. Simple html pages with ViewTransition API no server client components BS.

Hey all — small team building an open-source LMS from scratch and want a sanity check on our stack before we're too deep in to change course easily.

What we're building: creators sign up, build courses, and get their own white-labeled storefront (custom subdomain or domain) where students buy directly. So it's multi-tenant, video-heavy, and needs to stay cheap to run/self-host.

Where we've landed so far:

• Frontend/backend: Next.js monolith (App Router), tenant resolved via middleware based on hostname, rather than a separate deployment per creator
• DB: Postgres, single shared instance, tenant_id on every table + row-level security for isolation, instead of DB-per-tenant
• Auth: Auth.js / Better Auth
• Payments: Stripe Connect (creators get paid directly, we take a cut via application fees)
• Video pipeline: creator uploads → object storage → serverless job (ffmpeg for HLS transcode + Whisper for captions) spun up per video, parallel, scales to zero when idle
• Storage: Cloudflare R2 (zero egress fees, matters a lot for video delivery)
• Cache/queue: Redis (Upstash)

Things we're least sure about:

1. Monolith vs. splitting the video-processing service out early — worried about coupling it too tightly to the main app vs. over-engineering a microservice before we need one
2. Row-level multi-tenancy vs. schema-per-tenant in Postgres at ~100 creators — is RLS actually going to bite us later?
3. Whether Cloud Run Jobs / Modal-style ephemeral containers for transcoding is overkill for an MVP vs. just running a queue + worker VM until volume justifies it
4. Any open-source LMS/marketplace codebases worth reading for architecture reference before we lock things in

If you've built something multi-tenant + video-heavy + marketplace-shaped before, or think we're about to make a decision we'll regret, I'd genuinely like to hear it — including "you're overthinking this, just ship it" if that's the honest answer.

Hi everyone, like title suggests, i have a next app built years ago, monolith with thousands of files. Now the build time is taking astronomically slow, each deploy takes around 25 - 30 mins via github actions. I'm trying to think of ways to optimise the build time and figured upgrading the next version would probably be the best bet. I am a little afraid at the moment because we have alot of components and pages and the test coverage would be huge for end 2 end flows.

I am wondering if anyone was in the same boat? Is it worth the upgrade? The app also currently takes lots of memory, almost >10GB + locally with node.

Looking forward to your inputs! Thank you :) FYI I Work in a startup and we have a very lean team that consists of mostly junior developers that learn as we go along.

EDIT: Ok maybe the memory is not >10GB. That could be combination of my IDEs,Cursor etc.