Most People Don’t Actually Use Next.js as a Backend
Source: Dev.to
The LinkedIn Post That Sparked a Debate
A month ago I shared a post on LinkedIn with the title “Most People Don’t Actually Use Next.js as a Backend.”
The post attracted far more attention than I anticipated, even reaching a Reddit discussion that gathered over 500 upvotes:
https://www.reddit.com/r/webdev/comments/1pqrqfv/i_guess_ive_been_using_nextjs_the_wrong_way/
Why the Pattern Is Problematic
- Many developers claim they are building full‑stack applications with Next.js, yet all data fetching occurs on the client side.
- Every request goes directly from the browser to an external API, meaning there is no server‑side logic, no backend responsibility, and no real use of Next.js’s backend capabilities.
When this happens, you’re essentially using React with better routing, not leveraging the backend features that Next.js provides.
Security Implications
- Direct client‑side calls expose API endpoints, request patterns, and sometimes even secrets through environment leaks or misconfigurations.
- Next.js is designed to keep external services hidden behind server routes, ensuring that secrets never reach the browser and reducing the attack surface.
Performance & Control
- By routing requests through Next.js, you gain better control over caching, rate limiting, and response shaping.
- Skipping this layer means you leave security, performance, and control on the table.
When to Use Express Instead
Express still makes sense for:
- Large, shared, multi‑client APIs.
- Scenarios where you need a dedicated API layer separate from the web frontend.
If your application is web‑only and you have already chosen Next.js, falling back to a CRA‑style architecture defeats both security and simplicity.
Takeaway
If your Next.js app exposes external APIs directly to the client, you’re not using the framework as intended.
Use the right tool, and more importantly, use it correctly. 👍
Additional Links
- LinkedIn post: https://www.linkedin.com/in/kenneth-nnabuife-a7a63812a