So I was just learning well for like 1.5 years now.

I did HTML, CSS, JS, Reactjs, build many projects and was being familiar to Nextjs now.

And now I see about Ai, how crazy it is and also stopped getting freelance clients anymore too for work.

Should I like just keep learning and do MERN stack and apply for job at this point or just pick something else that can still get me some work now?

I'm so confused right now, feels like almost 2 years went to waste trying to learn programming and web development to make it my career.

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!

was building a small dashboard with cursor and noticed most of my pages had "use client" at the top. every time it hit a hook or onClick error it just turned the whole page into a client component instead of pulling the interactive part out. so my data fetching ended up back in useEffect lol. now i have a project rule that says pages and layouts stay server components and anything with state goes in a small component next to them. haven't had to undo one since, curious if anyone else had to fight this.

Context: I am building a self-hosted backend for realtime apps, and making its Next.js starter template. I want npm run dev in that template to start Next and the backend together, one command.

With Vite this is easy, a plugin can start the backend inside the dev server (configureServer). But for Next I couldnt find a hook:

- next.config wrappers (the withSomething() pattern) are meant for config. You could start a process from there, but next.config also loads on next build, so the backend would start during builds too.

- instrumentation.ts register() runs once when a Next server starts. But it runs on every server start, dev and prod, and it has to finish before the server is ready. Spawning a long-running process from there feels wrong.

So it looks like everyone runs two processes side by side. Convex's Next.js template does npm-run-all --parallel dev:frontend dev:backend. Others use concurrently, turbo, or docker compose.

Is there a proper hook I missed?

What do you find yourself spending the most time on when working on a Next.js app?

For me, a recent time sink was investigating slow cold starts on Cloudflare and figuring out which dependencies to cut.

What about you? What’s been eating up your time lately?

For one toggle I write a server action, revalidatePath/revalidateTag, useOptimistic, and a "use client" boundary. I know why each piece exists, and it all works.

But the data already lives in the DB, and the UI is just a view of it, so keeping everything in sync feels like a lot of wiring for a small change.

How are you handling this in your apps? Have you settled on a pattern or built an abstraction around it, or do you just write it each time?

Curious what still feels tedious, if anything.

I keep reading that with Server Components and Server Actions you no longer need TanStack Query (or any client-side data fetching library). I’d like a sanity check for a specific setup.

Setup

• Next.js 16 App Router used purely as a frontend. All data and business logic live in a separate .NET backend.
• Everything is behind a login, so SEO doesn’t matter.
• Better Auth handles authentication. Access tokens stay on the server, and route handlers act as a BFF proxy to the .NET API.
• Client components use TanStack Query → route handlers → .NET. Forms use useMutation + invalidateQueries.

Requirements

• A dashboard with many filters stored in URL query params
• Clicking a chart bar adds a filter, which triggers new queries
• Data grids that load more rows on click
• Lots of client-side validation

The Next.js docs on client-side data fetching suggest a library like TanStack Query when components need a shared browser cache, which seems to fit here.

Questions

1. Is this a reasonable architecture, or am I fighting the framework?
2. Is it fine to use TanStack Query for all data fetching in this kind of setup, or is that considered bad practice with the App Router?
3. Any pitfalls when combining TanStack Query with the App Router?

Thanks!

As the title says, work needs this as a requirement. I know NextJS should handle this properly but i need the website to be google searchable properly on all 70mil pages. Im a bit confused on what kind of generation method i should use for this? SSG for 70 mil should crash my aws container.

But then again, the requirement is that all 70 mil pages are indexed by google so that it shows up on google search. The pages are already stored in a db

Any tips, architectural/engineering advice is welcome

Hey everyone!

I’ve been working on BoseUI, an open-source UI component library, and just added a new component called Black Hole.

It’s inspired by the black hole visuals in Interstellar and is built using a single raw WebGL shader, without relying on any 3D libraries.

Some highlights:

• Real-time gravitational light bending
• Dual-arc accretion disk with Doppler beaming

• Targets 60 FPS in the browser
• Can be used as an animated hero background behind text or other UI elements
• Installable directly through the shadcn CLI

Try it out:

Demo: https://boseui.site/components/black-hole

Hey everyone,

I’m wrapping up a full-stack project for a client who is completely non-technical, and I want to follow modern best practices for a clean, secure handoff.

The Stack: Next.js, Vercel, GitHub, Neon DB, Cloudinary, Namecheap, and Resend.

I want to make sure of a few things:

1. Full Ownership & Billing: How do I easily transfer these accounts (and credit card setups) so they own everything, but without breaking the app or confusing them?
2. Future Developer Friendly: I want them to be able to hire another developer in the future to audit or scale the code without needing my permission or involvement.
3. Security: How do I cleanly remove my own access so the client feels 100% secure?

How do modern freelancers and agencies handle this offboarding workflow efficiently for "tech-noob" clients? Would love to hear your checklists or tool recommendations (like 1Password, Bitwarden, etc.) for sharing credentials!

Thanks!

After migration we got lots of 404 errors automatically which we fixed earlier.

The ghost 404 errors you experienced previously were caused by how URLs, redirects, or trailing slashes were handled during the migration, rather than the tracking code itself.

I'm building a small multilingual website with Next.js App Router, Prisma, PostgreSQL (Neon), Zod, and react-hook-form. An admin panel lets one user edit about 35 content fields in English, Russian, and Armenian (en/ru/hy). I want adding a fourth language later to require minimal changes.

Current architecture

• A key-value Setting table with key and value columns.
• Translations stored as flat keys, e.g. contact_title.en, contact_title.ru, contact_title.hy.
• Admin forms use structured objects, e.g. contact_title: { en, ru, hy }, and save through a Server Action.
• Server Components read settings through unstable_cache with a settings tag, and the Server Action calls revalidateTag after saving.
• Text is resolved through a fallback chain: requested locale → default locale → hardcoded fallback.
• Static UI strings live in dictionary files, with optional database overrides.

A bug I ran into

When submitting the admin form, a nested object was converted with String(value), which stored "[object Object]" instead of the translated text. The bug exposed a design problem: the conversion between flat database keys and structured form data was spread across several places.

What I've changed

• Centralized the flat-to-structured conversion in one codec module (decodeFlat / encodeSettings).
• Generated the validation schema and field whitelist from shared constants.
• Replaced roughly 200 individual upserts with a single bulk INSERT ... ON CONFLICT using unnest, because the Server Action was timing out in a serverless environment.
• Delete empty translations so the fallback chain can take over.
• Added round-trip tests to check that every field and locale survives decode → validate → encode.

Questions

1. Storage: Would you keep flat key-value rows, use a JSONB column, or introduce a dedicated translations(entity, field, locale, value) table? What becomes painful as the project grows?
2. Empty values: Would you delete empty translations to enable fallback, or store explicit empty strings to support intentionally blank content?
3. Validation: How do you handle text-length limits across languages? Armenian and Russian are often much longer than English, so I'm using per-locale length multipliers as warnings rather than hard errors.
4. Fallbacks: How do you keep fallback logic centralized and consistent across Server Components, Client Components, and unstable_cache data?
5. Adding languages later: What tends to be overlooked beyond the database schema?

I'm especially interested in practical experience with admin-editable content, rather than translation libraries for static UI strings.

Thanks!

We’ve been using Cache Components and PPR (loving it), and I’m curious how it’s been for others.

What are you building, and what made you try them?

Whether you’ve shipped, are still figuring things out, or decided against using them, I’d love to hear how it went.
Feel free to share your app too.

Curious how people are running Next.js in production without Vercel.
What made you choose your current setup? Cost, flexibility, existing infrastructure, or something else?

And now that you’ve been running it for a while, what’s been surprisingly easy or more work than you expected?

Especially curious about the little things you’ve ended up building or maintaining yourself that don’t get talked about much.

Imagine Priya spends an afternoon writing careful RLS policies. Every table is locked down to the owning user. She tests in the dashboard and feels good.

Later she asks her AI assistant for an `/api/orders` route. It keeps hitting permission errors, so it quietly creates the Supabase client with the service_role key (newer name: secret key). The errors vanish. The route takes an order id from the query string and returns it.

Now any logged-in user can request any order id. The policies never get a vote, because the service role bypasses RLS entirely.

What to look for:

Search your codebase for `service_role` and `SUPABASE_SERVICE_ROLE_KEY`

Each hit should be in server-only code, ideally admin jobs or webhooks

Routes that act on behalf of a user should use that user's session client, so RLS applies

If you must use the service key, check ownership by hand (`.eq('user_id', user.id)`)

The tell is simple: if the AI "fixed" a permissions error, find out how.

I recently had to pick an i18n library for a Next.js App Router project and ended up reading a lot of source and docs for both next-intl and react-i18next. Here's the short version of what actually mattered, in case it saves someone a weekend.

1. Server Components are the deciding factor, not features. next-intl was designed around the App Router. getTranslations() in Server Components and useTranslations() in client ones read from the same request config. With react-i18next, the useTranslation() hook only works in Client Components. On the server you need a per-request i18next instance. A shared global instance whose language you change per request can leak one user's locale into another concurrent request. That bug is easy to write and hard to spot.

2. Bundle size is mostly about messages, not the library. Whichever library you pick, what ends up in the browser is mostly your message catalog. With next-intl, text rendered in Server Components arrives as HTML and its messages never go to the client. For client subtrees you can pass only the namespaces they need:

<NextIntlClientProvider messages={pick(messages, ['Pricing'])}>

react-i18next gets to the same place with namespaces and a lazy backend. It's a configuration choice rather than the default.

3. The message formats differ, and mixing them fails silently. next-intl uses ICU ({count, plural, one {# file} other {# files}}). i18next uses its own JSON format with suffixed plural keys (file_one, file_other), and ICU only through a plugin. If you paste ICU strings into an i18next project without the plugin, they render literally, braces and all.

4. setRequestLocale is the thing everyone forgets. With next-intl, if a statically rendered page doesn't call setRequestLocale(locale), that page opts into dynamic rendering. On Next 16, also remember that middleware.ts is now proxy.ts. A leftover middleware.ts just never runs, and you get "Unable to find next-intl locale".

5. My rule of thumb: whoever owns the most code that renders text wins.

• Mostly a Next.js app: use next-intl, even if a small React Native app on the side uses i18next.
• Translations shared across Vite/RN/Electron/Node: use react-i18next everywhere.

6. Pick locale codes once. en_US in file names, en-US in URLs and en in <html lang> all in one app causes subtle fallback bugs. Use BCP 47 tags everywhere.

Curious what others picked. Has anyone run react-i18next in Server Components at scale without problems?

She started with Next.js and Cloudflare D1 to keep a small project straightforward. As the game grew, she moved the database to DigitalOcean, then moved the application and database to AWS. She described the application and database being in different locations as one source of trouble after the first move.

Her current stack includes Next.js 16, React 19, TypeScript, PostgreSQL, Socket.IO and Three.js through React Three Fiber. She also uses Zustand, shadcn/ui and Tailwind.

I’d like to hear from people running similarly interactive apps: how have you arranged your Next.js application, database and real-time services?

What actually prompted you to change that setup? Was it latency between services, database load, connection management or the difficulty of operating it? I’m particularly interested in what you measured before deciding to move things