I'm building a small utility site with several tools that need input validation and a live preview. I want the pages to stay fast and share a consistent shell without turning each whole route into a client component.

For folks using the App Router for a set of interactive tools, what structure has worked best: keep the page/layout server-rendered and compose small client components for each tool, or make a reusable client-side workspace per tool? How do you handle shared state and validation without making the client bundle grow unnecessarily?

Side project started as a pure Next.js frontend on Vercel. Then it grew a Postgres db through the marketplace, file uploads and a queue worker that turns big CSV uploads into reports, and the worker is where it stopped fitting. The big ones run about 40 minutes, which is past the 30 minute beta on functions, and they don't split into Workflows steps. Daemons would probably run it but they're in public beta.

I moved it onto the box I keep for other projects and it fell over twice while I was asleep, so that's not the answer either. It's only a few users so far and I'd like to make this move once, with the app and the worker in one place. Been reading up on Railway, ample.computer and Render. For anyone who took a Next.js app with background jobs off Vercel, what did you move to?

For a while I assumed the normal setup was to host the frontend in one place and put the database somewhere else. It works, but for a small app it feels like a lot of separate dashboards and settings to keep track of. I am wondering if there is a real advantage to keeping everything separate when you are working on a personal project or an early stage product. Does the extra flexibility matter at that size, or would you rather have the whole thing in one place?

Looking for an easy way to track my vercel spending / build logs on the go. I use an iphone anyone has recommendations for things they use?

i was learning MERN/PERN stack and nextjs in development and plan to start freelance and made two project before i feel burnout and stopped programming for a while around 4-5 months and when i came back i found that all are saying it's not practical writing code with hands again

i tried to use ai agent to write code and i review it but the code ai is writing are so messy like i ask for simple function to do some kind of thing and i found it made around 5 helper function many of them are just normalizing or one return line that make some filter or mapping i really found it so hard and time consuming reviewing this messy code i can't really manage

at the same time i don't want to but some constraint or forcing ai to use my own coding style since it could have some bad practice, weak patterns or things like that and waste learning from ai

NOTE: i really appreciate any advice from anyone here about ai or anything else in coding since i consider my self extremely bad.

I've been exploring Phoenix LiveView lately, and it got me thinking.

We've spent years moving more state and logic into the browser. But what if we kept most application state on the server and used JavaScript mainly for rich interactions?

I'm not talking about replacing JS. Libraries like Monaco, AG Grid, and Chart.js are great and I'd absolutely want to keep using them.

Curious what frontend devs think. Would you consider a server-driven approach if you could still use your favorite JS libraries, or is there too much downside?

I've built a unique website for a local radio station which essentially replaces WordPress, spreadsheets, and manual processes with a station-hosted system matched to how community radio actually runs.

I've spent 165 hours on it, for free for my local organisation, and now have approached other more financed station's to see if they would like the package.

I'm community minded, and want this tool to help other community radio stations, but would also like to be paid for my time.

I'm a newbie (did website design at uni a while back, but never fully trained).

Stack

• Django 4.2 + Wagtail 6 (CMS for the public site)

• PostgreSQL in production (SQLite OK for local)

• Stripe for paid subscriptions

• Docker + Gunicorn + Caddy / WhiteNoise for deploy and static files

• Server-rendered templates (no separate React/Next front end)

How does one price this considering the state of how easy it is to built a usable product? I'm thinking a base rate for what the site is now, plus an houring rate for making it theres.

I'm based in Australia.

Would appreciate other peoples perspectives that may have been in a similar boat.

TIA.

why the hell I've been downvoted what's the wrong thing i said

i don't understand

that's so hilarious

everyone in comments section is recommending to find a less "awful" places to deploy your app

bro like what?

i already spent months building it on nextjs am i supposed to find another framework now?

i know there is another places to deploy a nextjs app but it's not as efficient and compatible as vercel

so what should i do

Honestly, pairing headless WordPress with Next.js feels like such an expensive way to double your infrastructure headaches just to use React, so l'm dying to hear from anyone whos actually lived with it long-term-did it genuinely solve your scaling issues, how do you handle plugins breaking every time a client wants a standard feature, and at what point does this setup ever make more sense than just sticking to a clean monolith or using a real headless CMS like Sanity?

For projects I'd rather run on my own machine, I built hoist: point it at a repo and every push runs your build and swaps the new version in, with instant rollback from a small dashboard. A failed build never replaces what's live. Public HTTPS comes from a Cloudflare Tunnel, so no open ports.

For Next.js you give it the start command, e.g. --cmd 'npm run build && npm start' (the app reads PORT). Branch previews are supported: every branch can get its own URL, removed when the branch is deleted.

Not a Vercel replacement for anything serious (one machine, no edge network), but nice for side projects and demos.

Built with AI assistance (Claude), tested by me.

https://github.com/nikhilcherry/hoist

My Next.js 16.3 Docker build failed on `pnpm run build` with a wall of errors like this:

[next]/internal/font/google/inter_c271339c.module.css:232:8
Error: Module not found: Can't resolve '@vercel/turbopack-next/internal/font/google/font'

Looks like a bundler bug. It isn't. What's actually happening: Turbopack fetched the CSS from fonts.googleapis.com fine, but then failed to download the .woff2 files from fonts.gstatic.com.

Each failed font file shows up as a "Module not found" on its src: url(...) line.

If Google Fonts is unreachable entirely, you get a clear "Failed to fetch Inter from Google Fonts" message instead — only this partial failure gets the misleading one.

Easy to reproduce: block just the font file host during the build and you get the exact same error, down to the line numbers: docker build --add-host fonts.gstatic.com:127.0.0.1 .

Without the flag, the same build compiles fine. In my case it was a one-off network blip: when I checked afterwards, both the CSS and an actual woff2 downloaded fine from a container. So if you hit this in CI/Docker: retry first, then check that the build container can reach fonts.gstatic.com (DNS, proxy, firewall).

Long-term fix: I self-hosted the fonts with next/font/local (woff2 from fontsource, latin only), so the build doesn't touch the network at all:

import localFont from "next/font/local";

const inter = localFont({ src: [ { path: "../public/fonts/inter-latin-400-normal.woff2", weight: "400" }, { path: "../public/fonts/inter-latin-700-normal.woff2", weight: "700" }, ], variable: "--font-inter", display: "swap", });

Has anyone opened an issue about the misleading error message?

Edit: known issue #97378, fixed in canary by #99574

(16.5.0-canary.2+). Stable 16.4.x still shows "Module not found".

Hi! so I am practically new in programming world particularly web dev.. I learned react, typescript and stuff.. so far I am enjoying it and wanted to be a frontend dev.

I am still exploring..so I have a CMS with login as Google.. connected in supabase. I don't have any knowledge with login logic , auth , token and stuff so I asked AI for it. gave me the code and explanation this and that.. eventually I learned how to CRUD using supabase and able to write it from the scratch without asking AI or searching in the internet.

the login code I got was pretty straight forward and I kind of have a mental model of understanding it then I was exposed to middleware. but skimming through the supabase documentation to find what I need to make the login logic from the scratch is overwhelming for me.

my question to experienced devs out there.. do you write the code from the scratch like login logic (auth..etc) or do you guys have a pre-written code that you use and refactor it to fit on the project you are working on?

right now its a personal project so my CMS I am working on is basically a fullstack (?) .. I also want to ask if setting up login logic is also a scope of a frontend dev? my head hurt learning it.

thank you.

Hey everyone,

I’m currently building a custom real-time Watch Party synchronization app using Next.js 15 (Turbopack) and Supabase Realtime Broadcast Channels.

Up until recently, we were syncing playback states using a third-party video aggregator embed (VidLink). Our app successfully intercepts their outbound PLAYER_EVENT frame tokens (which broadcast out strings like "event": "seeked", "currentTime: 176" via window.addEventListener('message')).

The Roadblock:

We need a way to force Player B to synchronize whenever Player A plays, pauses, or seeks. However:

1. The video embed provider has no inbound message handling implemented. Sending .postMessage({ command: 'seek', time: x }, '*') to the iframe window falls on deaf ears.

2. Trying to force sync by updating the iframe src query parameter using their documented &startAt=X variable triggers a massive Ping-Pong Feedback Loop. Player B reloads at the new time $\rightarrow$ player fires a fresh outbound "seeked" event $\rightarrow$ Player B's window mistakes it for a local user action and broadcasts it back to Player A $\rightarrow$ Infinite rapid reloads until we get hit with an HTTP 429 Too Many Requests ban.

What we've tried:

• Implementing strict outbound state debounces and temporary emission lockouts (Date.now() + 5000) using React refs to silence the feedback loop during reloads. (Still occasionally risks race conditions and feels like a massive hack).

• Contemplating moving entirely away from the iframe embed model over to a native HTML5 video component coupled with Hls.js, backed by an open-source scraper API (like movie-web/backend) to fetch the raw stream URLs directly.

Before we completely rewrite our architecture to use raw streams, has anyone successfully solved a two-way synchronization room setup using a closed, outbound-only third-party iframe embed? Are there any clever cross-origin mitigation patterns or token handshakes we are missing here? is there any stream aggregrator that spits out just .mp4/.m3u8 type files?? i looked over at stuff from p-stream but couldnt find in the git how tf do they host watch parties

Appreciate any advice or structural feedback!

Next.js shipped its November security release on Nov 3: 16.4.5 (Active LTS) and 15.5.29 (Maintenance LTS), seven advisories. None are critical (the release post rates one High, the rest Medium), so here's a quick way to tell how urgent it is for you.

**First, check which band you're in**

npm ls next

- Below 16.4.1 / 15.5.28 (including all of 16.3.x): upgrade today. You're also missing the Oct 14 fixes for two critical unauthenticated RCEs (SVG image optimization, use cache with typed arrays). There is no patched 16.3.x.

- 16.4.1 to 16.4.4, or 15.5.28: you have the critical fixes. Upgrade this week, sooner if one of the cases below fits.

- 14.x: unsupported, no fix for any of this.

**The seven, by who they affect**

- Cache Components / `use cache` (16.x only, four advisories):

- GHSA-mfr8-8qww-v76h (High in the release post): the same `use cache` function called directly and through `unstable_cache()` can serve one tenant's data to another when it reads a root param like a tenant ID.

- GHSA-rhh4-g77r-r9qj: binary args (Uint8Array, Blob) to `use cache` can collide on the same cache key, so users can get each other's cached results.

- GHSA-vc7v-qv4w-wrv8: nested `use cache` functions can reuse content across root-param values.

- GHSA-vvgp-ww4w-46vf: self-hosted `next start` with Cache Components and no Partial Prefetching, one unauthenticated request can poison a shared fallback shell.

- Edge routes that set cookies (GHSA-f3mh-rxg3-f5g2): `NextResponse.cookies.set()` in Edge route handlers / Edge API routes also echoes the cookie in an internal `x-middleware-set-cookie` header that same-origin JS can read, even when HttpOnly. Needs attacker JS already on your origin. Node routes and `cookies().set()` weren't affected in their repro. Worth checking if your session cookie is set from an Edge route.

- Image optimization (GHSA-7qx7-33qx-rqx2): an image from an allowed host can be misread as AVIF and get past `dangerouslyAllowSVG: false`. Your remotePatterns allowlist still applies, so a wildcard host makes this worse.

- Self-hosted apps returning a fetched Response unchanged (GHSA-pc58-hwjq-p385): behind an HTTP/1.1 proxy that queues pipelined requests, responses can land at the wrong client.

The release post doesn't ask anyone to rotate secrets.

**Upgrade**

npm install [email protected] # 16.x

npm install [email protected] # 15.x

If you're on 15.x and came up from an older lockfile, also run `npm ls sharp`. [email protected] still accepts sharp 0.34.x, which is inside the Oct SVG RCE range (fixed in sharp 0.35.5). `npm update sharp` fixed it in my test.

15.x gets security releases until Jan 31, 2027, so plan the move to 16 before then.

Sources: https://nextjs.org/blog/november-2026-security-release and the linked GHSAs.

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

i really would need your help fellas

I recently migrated to vinext to be able to host on i CF, I am now testing the app on dev mode.

so far iv run into two issues:

1:clicking an add to cart button does not work at all the cart stays empty, note that my cart is fully zustand nothing is saved on server

2: server side components does not receive environment variables at all, i am using Infisical to inject the vars but vinext keeps giving me this error whenever i use the createServerClient() from supabase
the error is

[vinext] server render error: Error: Your project’s URL and Key are required to create a Supabase client.

and this is how I am accessing the vars in my createServerClient
process.env.NEXT_PUBLIC_SUPABASE_URL

IM STILL ON DEV MODE STILL HAVENT DEPLOYED ANYTHING

I have a site, NextJS with WordPress. I used to use Next Image, but due to the sheer number of images (over 100k), I moved to offloading them to Cloudflare R2. I use CF image transformation, and the correct image sizes are served.

Do I still need to optimise the images with a plugin on WordPress? Or would that be redundant? I can think of one thing the plugins could do: change the format to WebP or AVIF.

Run this after next build:

grep -rl "無効な入力" .next/static/chunks

That string is "invalid input" in zod's Japanese locale. It shouldn't be in your client JS at all unless zod's locale files came along with it (or your own UI has that text in Japanese). Grep the Japanese string, not a German one. Webpack's minifier can escape the German.

Our test app was a fresh Next.js 16.4.5 project with one client component and a single email field checked by zod. Between builds we swapped only the import line. Turbopack:

With --webpack the 4.3.6 default import matched too, while 4.5.4 and 4.6.7 stayed clean. We didn't build 4.4.3 with webpack.

Sizes, gzipped. Going from import { z } to import z took the 4.3.6 Turbopack build from 199,925 bytes to 236,253, and the 4.4.3 one from 194,380 to 237,354. Those totals are all of the app's client JS for a one-field form, Next and React included, so the gap is what the import line changed.

By 4.6.7, zod's index.js exports the default as an alias, export { z, z as default }. In 4.4.3 it was export default z. The comment above the alias says it lets Rollup and webpack shake import z from "zod" the way they already shake import { z }, and points to #6050.

If the grep finds something and you're on 4.3.6 or 4.4.3, import { z } from "zod" came back clean in our builds. On 4.5.4 and 4.6.7 the two imports built to identical bytes. On any other version, rebuild and grep again.