Next.js: An Honest Review(beeps.dev) |
Next.js: An Honest Review(beeps.dev) |
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
> 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!
the main issue i wanted to highlight is that things are not caught at type-check time. maybe vercel could provide eslint plugins? this could codify a lot of the caveats
> There's no way to get around thinking about AuthN/Z with any server APIs
very true! maybe there is a way to make the default secure somehow by making it awkward to publicly expose a POST route by accident. awesome that next.js 15 is doing things in that regard.
thanks for addressing the points leerob, shows the great governance mentioned in the end of the post :)
imo it's easier to spot the authn/authz issue here
export default function handler( req: NextApiRequest, res: NextApiResponse<ResponseData> ) { // updating user details without authn/authz }
than here
"use server"
export async function updateUser(email: string, age: number) { // updating user details without authn/authz }
without having read any next docs. engineers got trained to consider authn/authz the moment they see "http route/endpoint", maybe being more explicit about what happens in the api would help?
or next could provide an authn api for server actions that authn providers would implement?