by joseferben on 1/22/25, 4:29 PM with 4 comments
by joseferben on 1/22/25, 4:29 PM
tl;dr
- Next.js 14 is fast, but App Router caveats increase cognitive load
- Server Actions are awesome, once secured
- Everyone is using Next.js, this is its greatest strength
- Vercel as hosting platform is a joy to use and they save us tons of time
by leerob on 1/22/25, 4:47 PM
> Next.js middleware run in an environment that's neither Node.js nor browser a browser environment. Some of Node’s API is supported, some isn’t.
Agreed, this is super painful and one of our top requests to fix. We're working to allow access to all Node.js APIs in Middleware. Tracking here: https://github.com/vercel/next.js/discussions/71727
> The docs mention that you should treat Server Actions like public API endpoints and Next.js 15 makes exploitation harder. However, this is still a major footgun.
Next 15 makes this much better than a standard API route. We automatically strip unused endpoints, and we add unguessable, non-deterministic IDs to secure the server actions. There's no way to get around thinking about AuthN/Z with any server APIs: https://nextjs.org/blog/next-15#enhanced-security-for-server...
> You need a 3rd party library (npm i server-only) to make sure that server code only runs on the server.
This is slightly misleading – code will run server only when you place it in a Server Component. That never makes it to the browser and you can safely fetch data there. What `server-only` does is help prevent cases where you have a shared data layer in your application, and someone might import and try to use a function designed for the server on the client. This directive then makes it error out during compile time.
Love the suggestion for trying to find ways to make this a TS hint versus waiting for compilation though. Good idea.
> Layout components can't access searchParams or pathname. We added x-search-params and x-pathname headers to incoming requests in our middleware.ts to work around this limitation.
This is intentional: https://nextjs.org/docs/app/api-reference/file-conventions/l...
What are you trying to do where you couldn't use, for example, useSearchParams in a client component for this?
> It's easy to accidentally bundle and ship server-only code to the client. There is server-only, hopefully it's going to be part of Next.js at some point.
Exactly, this is what `server-only` is for – it won't be part of Next.js core because it's designed for the broader React ecosystem, but we do recommend using it for cases like this.
> It looks like the View Transitions API is coming to React and will likely be the best solution in the future.
Indeed, View Transitions are currently already available in the latest Next.js canary and we'll be sharing more on this very soon.
Hope this all helps, thanks for writing this up!