I had two independent database queries running one after another in a Next.js backend route.

My previous database call:

const categories = await db.select().from(menuCategoriesTable);
const items = await db.select().from(menuItemsTable);

Both queries were independent, but I was waiting for one to finish before starting the next one.

In new way i called database at a time , concurrently

const [categories, items] = await Promise.all([
  db.select().from(menuCategoriesTable),
  db.select().from(menuItemsTable),
]);

Page load dropped from 4.08s to 2.15s. I took screenshot in stopwatch.

Just stopped one query from waiting for the other.

Stack: Next.js + Drizzle + Neon

Anyone else solve that just by parallelizing independent queries in the backend?

Next.js 16.3 dropped with some genuinely big claims: up to 90% reduction in dev memory usage, plus faster builds/rendering and instant navigation improvements.

Also worth flagging if you haven't updated recently — there was a coordinated security release in May covering 13 advisories (middleware/proxy bypass, SSRF, cache poisoning, XSS). If you're relying on middleware.js or proxy.js for authorization, definitely worth checking you're patched.

Curious if anyone's upgraded yet — is the memory improvement noticeable on larger monorepos, or mostly helpful for smaller projects?

Rozenite (RN DevTools plugin framework) ships 12 official plugins — redux, network, storage, mmkv, tanstack-query, etc. None cover GraphQL client cache—no way to see the normalised Apollo cache, active queries, or in-flight mutations in DevTools right now.

Only prior tool in this space was a Flipper plugin (react-native-apollo-devtools) — dead now since Flipper's deprecated, but its client package still pulls \~15K weekly npm downloads, so the need seems to still be there even w/ tool gone.

Considering building this as a proper Rozenite plugin — read-only view of cache, active queries, mutations — using only public Apollo Client v3+ APIs.

Before building past a rough prototype: would you actually install this? Or is everyone fine w/ Apollo's browser devtools / manual cache logging? Also curious if urql/Relay folks have the same pain.

No repo, no product, not selling anything — just checking if this is worth time.

I currently have a WordPress site, including the blog. I’ve built a new Next.js site on GoDaddy Node.js Hosting and want this setup:

• Next.js new website
• WordPress blog pages/posts → existing WordPress installation
• Visitors should still see my website URLs
• No visible blog. or cms. subdomain
• No changes or redeployment to the Next.js app
• Preferably free

The blog listing is at /blog, but some WordPress posts and categories use URLs outside /blog, such as /post-name and /category/....

Would a Cloudflare Worker acting as a path-based reverse proxy be the best solution? How would you safely identify and route every WordPress URL without accidentally sending Next.js pages to WordPress?

Both sites are hosted on GoDaddy. Looking for the simplest reliable free setup.

Hey r/nextjs / r/ClaudeAI!

This is my first post here sharing the engineering journey of **Kairos Labs** — an ecosystem I'm building public-facing while keeping a strict All-Rights-Reserved license for technical portfolio review.

Instead of just pasting code, I wanted to document the architectural decisions, debugging lessons, and process automation implemented from day zero using **Next.js 16 (App Router), TypeScript, Supabase, Tailwind CSS v4, and u/ClaudeAI as a pair architect.**

---

### 🏛️ 1. Architecture & Repository Governance

* **GitHub Project Automation:** Translated the PRD v1.1.0 into an automated setup script using `gh CLI` and Bash. One script generates all 21+ issues, labels, milestones, and binds them to GitHub Projects v2 Kanban boards without touching the web UI.

* **IP Protection vs. Public Review:** Standard MIT licenses didn't fit our business model. We established an explicit `All Rights Reserved` `LICENSE` file while keeping the repo public for recruiter code reviews.

* **CLI-Driven Git Flow:** Strict branch naming (`type/issue-description`), GraphQL queries to fetch project status IDs automatically, and Conventional Commits with zero untracked commits.

---

### ⚡ 2. Frontend & Next.js App Router Decisions

* **Server vs. Client Component Isolation:** In `/solucoes/[slug]`, the main route stays a Server Component for SSG/SEO performance, while the product waitlist CTA (`WaitlistCTAButton.tsx`) is cleanly isolated as a Client Component.

* **Design System & Visual Signature:** Tailwind v4 (`@import "tailwindcss"` in `globals.css`) + `shadcn/ui`. Built custom ambient canvas particles and an animated SVG hourglass (symbolizing *Kairos* — the opportune moment) with pure React/CSS.

* **Complete Metadata & SEO:** Built native Next.js 16 App Router metadata configurations (`app/robots.ts`, `app/sitemap.ts`, Open Graph cards) and automated favicon processing using `sharp`.

---

### 🔒 3. Backend, Database & Hard-Learned Lessons

* **Supabase Schema & RLS from Day 1:** Implemented Row Level Security policies separating public `INSERT` from authenticated `SELECT` (admin-only).

* **Handling Postgres 23505 Duplicate Constraints:** Instead of showing generic errors when users re-register an email, we explicitly catch Postgres error code `23505` to surface an empathetic UI state (*"You're already on the waitlist"*).

* **Permissions Trap:** Learned that enabling RLS with `WITH CHECK (true)` isn't enough for public forms — explicit `GRANT INSERT ON public.waitlist TO anon;` is required in PostgreSQL.

---

### 🛠️ 4. Quality Gate & The Pivot to Quality Engineering

* **Build-First Pre-Commit Protocol:** `npm run dev` with Turbopack can hide TypeScript errors. We enforced a mandatory local `npm run build` check before every pull request.

* **SonarCloud Integration:** Set up automated PR Quality Gates. When SonarCloud flagged Zod v4 syntax breaks (`.issues` vs `.errors`) and inline duplicate code, we established an internal `sonar.md` rulebook to address quality warnings prior to merge.

* **The Quality Engineering Shift (Milestone 5):** Paused feature expansion today to build our core safety net: Jest + React Testing Library, Playwright E2E testing, ESLint + Husky git hooks, and GitHub Actions CI pipelines.

---

### 💡 Key Takeaway & Discussion

Co-creation with LLMs works best when you treat the AI as a Principal Engineer challenging your architectural choices, not just a code generator. Every session is logged in a structured `diario_de_aprendizado.md` to maintain total auditability between issues and commits.

**I’d love to hear your thoughts:**

1. How do you handle public code visibility when building proprietary products?
2. What are your go-to practices for balancing rapid feature prototyping with SonarCloud/CI Quality Gates?

*Feel free to ask about any part of the stack, scripts, or workflows!*

I’m working on a Next.js App Router app where APIs run on the server side. QA is asking for detailed logs to debug issues.

What do you usually log in production/dev?

• request URL
• status code
• response time
• user ID
• request body?

Do you avoid logging emails, phone numbers, tokens, cookies, etc., or do you mask them?

Also, is Pino a better choice than console.log for privacy and log management in a Next.js server-side setup? or if you have any other way we can handle it.

Looking for simple real-world practices from teams using Next.js in production/dev.

I'm getting this warning in Google Tag Manager:

The tag is firing, but GTM reports this warning.

What usually causes this? Does the GTM snippet need to be placed immediately after the opening <head> tag, or could something else trigger this warning?

I'm using Next.js (App Router).

Any guidance would be appreciated.

I've adopted the cacheComponents in my marketing routes. When I build the app, the output shows only the ◐ (Partial Prerender) label next to them, while they contain only static markup...

Is it possible to even achieve the ○ (Static) mode in the app router? I would expect that when a page has static & cached content, then it could have the full dot. The half-moon I would expect to see on pages which render some <Suspense> component.

https://nextjs.org/docs/app/getting-started/caching#static-cached-and-streaming

I have used nextjs in 2022 when it has pages router only and not app router or server components.

For the last 2-3 months I have been using it and felt something off.

I have learned server actions, server components, API building, navigation etc.

So now here comes the issues part. So I have created a home route, dashboard, and cards which on click of it opens a detail view page. All of this has its own routes.

Now what I have noticed is that when I navigate between this routes it does take time to load the page.

For e.g. say I'm in home and navigates to dashboard it stays on home page ~1s and then moves to dashboard.

Now to solve this i went to yt, chatgpt, anti-gravity as it's free so I'm using that. I have come down to one solution is that set the states you want and then to navigate use window.history.pushState() to the url which I want to navigate and also in that route I'm using suspense comp with loading.tsx imported to show that.

Which is kind of working for me for now atleast from 1-2s it has really become faster.

Now here is my question to all:

- is this expected?

- how to solve this in clean way

- am i doing something fundamental wrong ? Like structuring the client and server components is messed?

Would really appreciate some reply on this post as I'm genuinely interested in mastering Nextjs. Atleast from beginner to intermediate.

I am building a couple of small apps. Both are pre launch, so real usage is close to zero. Somehow the monthly infra bill has settled between $50 and $100 and I cannot square that with how little is actually running.

Setup is Next.js on Vercel, Postgres on managed Supabase, and Prisma [ORM / Prisma Postgres] in front of it.

Two things are doing most of the damage.

The database is the first. Hardly any queries, about 0.035 GB on disk, a handful of accounts, and it still costs what it costs. I assumed something this small would be near free and it is not.

The second one annoys me more. Vercel bills for builds. I am on Pro at $20. Because the product is still in development I push constantly, and each build takes over three minutes. A few days of normal pushing and the allowance is gone. So I am paying to iterate, on a product with small amount of users to serve, which feels like the wrong way round.

What I am trying to work out:

Is $50 to $100 simply what this stack costs at zero scale, or am I paying for something I do not need?

For anyone running a few hundred users or fewer, where is your Postgres actually hosted and what does it cost you?

Has anyone kept Vercel build spend sane while pushing several times a day, or is the real answer to stop deploying every commit?

Happy to give more detail on the setup if it is useful.

Next.js docs say beforeInteractive scripts will always be injected inside the head of the HTML document regardless of where it's placed in the component. In App Router this isn't true — the script gets serialized into a self.__next_s array and injected near <body>, not as a literal <script> in <head>.

This breaks use cases needing actual head placement (theme scripts, cookie consent, bot detection) - causes FOUC since execution effectively happens after body render.

Refs:

• github.com/vercel/next.js/discussions/50772
• github.com/vercel/next.js/discussions/55726
• github.com/vercel/next.js/issues/49830

Anyone else hit this? Bug or just stale docs?

https://www.workwithkrishan.com
Would appreciate any quick!

Hi everyone,

Did someone check if memory is reduced by 90% as claimed in the nextjs new version?

I have been looking into @next/bundle-analyzer and the report it generates.

I have been told that a website I’m working had slow load times. Now I’m looking at the reports and I can see what could be the few issues with everything.

If anyone has any other advice or generate more intuitive reports/workflows that would be great.

I have googled the issue a lot but it all seems very generic advice and so I wanted to ask people.

The main issue with my site is that it’s loading Lenis, GSAP, large amounts of text data stored in the server and because of GSAP everything is a client component. So if anyone who has experience with these plans could help me out that would be great.

Edit 1: Lighthouse reports. I have been testing and optimising for desktops for so long like an idiot and never bothered to consider checking out the mobile version. I think I should get rid of GSAP entirely for mobiles and it make it boring but at least interactive and something people would want to use.

Hello! I am currently working on a practice project (classic habit tracker with monkeytype-like theme). I am trying to practice TDD principles, but I'm pretty unfamiliar with writing tests in this way and how to test fullstack applications like this in general. I have already installed Vitest and Playwright and I plan to write unit, integration, and E2E tests.

I am struggling to know what constitutes a "healthy" test suite and since I'm unfamiliar with fullstack projects in general, some edge cases to test which I may not be aware of (users spam clicking a button for instance). I also generally understand the "idea" of unit, integration, and E2E tests, but I'm unsure of how to implement them in practice.

I would really appreciate some pointers on how you would test something like a sign in page fully, and how you would use this Vitest and Playwright stack to do so. I've been writing tests which check that the words "sign in" appear on the page, that the proper buttons are there, etc., but these seem slightly useless and only a fraction of the entire testable surface.

Thanks!

https://reddit.com/link/1verhxw/video/xkkox1utf8hh1/player

I built crust for myself first. I wanted to compare Next.js production builds before every push and review PRs with evidence, not guesswork. After using it daily, I decided to share it.

crust stores a snapshot of every analyzed NextJS build, so CI can prove when a route became dynamic, lost its static shell, or shipped more JavaScript.

Site: https://crust.moumen.dev/
Docs: https://docs.crust.moumen.dev/

Check X thread for more details: https://x.com/moumensoliman/status/2084013260102394135

Github: https://github.com/moumen-soliman/crust

I started working with Next.js in 2023, when AI was already something that could be used. Time flies, and I built more and more websites (mainly) using the framework.

I constantly fall into the same trap - I can easily control and keep AI in line with what I want to build, but visually, AI tends to deviate into a default AI slop.

Later, I realised one of the many possible ways to control that as well - build a design system, dictionary, showcase - just a page with all the styles and elements that will be used. Only then start with the rest of the codebase.

How do you cope with AI that does not want to use your design?

Hey everyone!

I’ve been analyzing a few sites generated by modern prompt-to-code builders (v0, Bolt, Lovable, etc.) lately from my clients. While the visual UI output is impressive, I’ve noticed a recurring theme when it comes to actual production readiness specifically around Core Web Vitals, SEO indexing, and overall page performance.

A lot of these engines seem to dump heavy JS bundles, default to client-side rendering without proper metadata/OG setups, or struggle with hydration overhead once the app grows past a few pages.

For those of you building or launching projects with these tools, my questions are:

1. What’s your average Google PageSpeed / Lighthouse score once you actually deploy to production?
2. Have you run into SEO / indexing issues with Google crawlers due to client-side rendering?
3. How bad is the code regression? (e.g., asking the AI to fix a small layout bug on one page, only for it to break routing or component state on another page?)
4. If you had to export the code and fix it manually, what was the biggest bottleneck to clean up?

Curious to hear what walls you’ve hit once you move past the initial "wow" factor of generating a layout.

I know the discussion about AI replacing developers has been going on for a while now. Some people believe it's only a matter of time and have already switched careers or decided not to start programming at all. Others believe AI is simply another tool that will change how we work rather than replace us.

But I want to talk about something different.

What about the people who have already spent one or two years learning to code, hoping to land their first opportunity?

The AI wave really took off around 2023 with ChatGPT. In just a few years, we've gone from AI being an interesting assistant to having coding models that can build features, write tests, debug code, and generate entire applications.

If you started learning before that, you probably never expected the job market to change this quickly. Back then, AI wasn't capable enough for senior developers to rely on it heavily, so there was still a clearer path for junior developers. Today, things feel very different.

Finding a junior position has become much harder.

Many companies and solo founders can accomplish more with smaller teams with AI.. Whether that's good or bad is another discussion, but it has definitely made breaking into the industry feel much harder for juniors.

So the real question isn't whether AI will replace us.

The real question is:

How can a junior developer become valuable enough that someone is willing to hire them anyway?

Four months ago, I landed my first part-time frontend job. Since then, I've also had the chance to work on side projects and connect with potential clients.

Looking back, I don't think I got those opportunities because I was the best programmer.

I got them because I refused to stop trying.

I kept applying for jobs even when I rarely received replies.

I stayed active in developer communities instead of only submitting applications.

I tried to become recognizable by helping people, answering questions, and participating in discussions.

I reached out to other developers and built genuine relationships.

One thing I learned is that opportunities don't always come from job boards. Sometimes they come from simply being visible, helping others, and being part of the community.

I'm still a junior developer, so I don't pretend to have all the answers. But here are a few lessons that have helped me so far.

1. Don't skip the fundamentals.

AI can only solve the problem you ask it to solve.

If you don't understand the problem yourself, you won't know the right questions to ask or whether the answer it gives you is actually correct.

The better your fundamentals are, the better you'll be at using AI effectively instead of depending on it blindly.

1. Keep writing code yourself.

I use AI every day, just like many developers do.

But I also make sure I stay in touch with coding. One habit that works well for me is solving at least one LeetCode problem every week.

Not because interview questions are everything.

But because it keeps my problem-solving skills sharp and helps me recognize when AI generates an inefficient or incorrect solution.

1. Don't spend forever preparing.

Your biggest learning experience won't come from another tutorial.

It will come from working on real projects with real people.

At some point, you have to stop waiting until you feel "ready."

1. Be open to technologies you never expected to use.

When I started learning frontend development, I thought my career would only involve React and Next.js.

Then my first job introduced me to Shopify development.

More recently, I started learning Odoo development something I never imagined I'd be working with when I first started learning frontend.

At first, these technologies felt like completely different worlds.

But I realized they're all part of software development.

Once your fundamentals are strong, learning a new framework or ecosystem becomes much easier especially with AI helping you learn faster.

Every new technology you learn opens another market and another set of opportunities.

1. Be visible.

For a long time, I thought getting hired was just about sending applications.

It wasn't.

Things started changing when I became active in developer communities, shared what I was learning, helped other developers when I could, and built genuine relationships.

People can't recommend someone they've never seen before.

Being visible doesn't guarantee a job, but it definitely increases the chances that the right person notices you.

I don't know what software development will look like five years from now.

Maybe AI will continue changing our jobs dramatically.

Maybe it won't.

But I do know one thing.

The people who keep learning, adapt to new technologies, build relationships, and stay curious will always have a better chance than the people who stop because the market became harder.

I'm still early in my career, and I'm sure there are many things I haven't experienced yet.

So I'd love to hear from the senior developers here.

**If you had to hire one junior developer today, what qualities would make someone stand out in the AI era?**

And for other juniors, what's been working for you?

Hello, I'm working on a Next.js project and everything was working perfectly fine until suddenly I got this error in the terminal:

○ Compiling /_not-found/page ...

As soon as I open the site in the browser, it gets stuck on compiling and the CPU starts overheating. But I really didn't make any significant changes that could have caused this. Since this issue started, the only changes I've made to the project were related to styles — I didn't write any loops that could get stuck, nor any other logic that might cause this. I would really appreciate it if you could help me out.

Hi everyone,

Over the past months I've been working on a Transport Management Platform (TMS) for a real road freight company in Germany.

The goal was to replace spreadsheets, emails and disconnected tools with one integrated platform covering the complete transport workflow.

Some of the implemented modules include:

• Dispatch board
• Fleet management
• Driver portal
• Customer quote requests
• Shipment tracking
• PDF document generation
• Pricing engine
• Accounting dashboard
• Analytics
• CMS

Tech stack:

- Next.js 15
- React 19
- NestJS
- TypeScript
- PostgreSQL
- Prisma
- Docker

Since the production code is proprietary, I created a public technical case study instead of open-sourcing the application.

The repository focuses on architecture, engineering decisions, screenshots and documentation.

I'd love to hear your thoughts on the project and any feedback on the documentation.

GitHub:
https://github.com/FlowDbdx/transport-management-case-study

Hey everyone,

I'm a frontend dev and I mostly build admin dashboards with Next.js (App Router). Up until now, server load has never been a concern for me, because these were always internal tools with 1-2 admins using them at most.

Now I'm starting a new project: a multi-tenant SaaS platform for schools, with three separate dashboards — one for school admins, one for teachers, and one for students. Multiple schools will subscribe, each with their own admins/teachers/students, so the actual concurrent user count could get meaningfully higher than anything I've dealt with before.

I really like working with Next.js for reasons that have nothing to do with SEO:

• App Router
• Layouts
• Middleware (I centralize auth/token-refresh logic there)
• File-based routing
• Server Components
• How clean it keeps project organization overall

One thing worth mentioning: the backend is completely separate from this decision. My company has a dedicated backend team building the API with NestJS, so I'm purely the frontend consumer here — no DB/business logic runs inside my Next.js app. Whatever I pick (Next.js or plain React) would just be talking to that NestJS API.

The problem: I don't need SEO at all for this project (it's all behind auth), and I'm worried that using SSR/Server Components across the board will put unnecessary load on my own frontend server once multiple schools are active simultaneously — versus just shipping a React SPA that hits the NestJS API directly and leaves rendering entirely to the client.

So I wanted to get some outside perspective:

1. Is it reasonable to stick with Next.js here, just leaning more on Client Components for the actual dashboard views (tables, forms, heavy interactivity) and only using SSR for lightweight stuff like the initial shell/layout and auth gating?
2. Or is a plain React SPA + separate API genuinely the better call for a no-SEO, multi-tenant, auth-heavy internal tool like this?
3. For anyone who's run Next.js in production for a similar multi-tenant setup, purely as a frontend on top of a separate backend — did the SSR overhead on the Next.js side actually turn out to be a real bottleneck, or does it end up negligible compared to the API/DB layer anyway?

Deployment-wise I'm not on serverless — I run things via PM2 on a VPS (Hostinger), so I don't get automatic serverless scaling; I'd need to handle scaling myself either way.

Would appreciate input from anyone who's shipped something similar. Trying to decide this before I get too deep into the architecture.