Calling a Next.js API route from a middleware using fetch

[nicholasio]

I have been wondering about the implications of fetching Next.js API Route from a middleware. My use case is that I want to talk to Redis (an arbitrary server instead of serverless redis like upstash) from a middleware so I'd need to run a node.js redis client (which I assume wouldn't work directly inside the middleware).

Would that be considered a bad practice due to the potential latency cost? How would vercel handle a situation like this? Would Edge functions be "close" to where next.js API routes are running? Would this add a significant latency cost to middleware?

[eric-burel]

Had a similar use case, it seems that currently the best practice would be to rely on a dedicated 3rd party that provides an HTTP interface, Vercel examples are all using Upstash for instance. That's probably the same problem if you want to connect to a db like Mongo (#12229).

Aren't API routes also stored at the edge? So technically I guess it would work, with the limitation that you can only call an API route that is NOT protected by the same middleware, as otherwise you create an infinite loop.

[IonelLupu]

@eric-burel . We are running Nextjs on our own infra. I have some code in my middleware that requires to encrypt something using the crypto nodejs package. Since the middleware file runs on Edge (or at least the Nextjs build says so. We get some error when building if crypto is directly used: The edge runtime does not support Node.js 'crypto' module.), I can't call my crypto function directly there. So, I created an endpoint on app/api/encrypt/route.ts. When I run locally or on Vercel, everything works correctly because I can call that endpoint like this:

const response = await fetch(`${request.nextUrl.origin}/api/channel/encrypt?channel=${channelName}`)

Now, my problem is with Docker. request.nextUrl.origin is the container name and when I run the app, it calls this URL https://booking-ui-86cd7b6dd5-tvnwk:3000/api/channel/encrypt?channel=blabla

Is there another way to call these endpoints without using the request.nextUrl.origin.

const response = await fetch(/api/channel/encrypt?channel=${channelName}) doesn't work either because it's not a valid URL. Getting Failed to parse URL from /api/channel/encrypt?channel=blabla

[nicholasio]

What if you just set your public next url as an env variable?

[IonelLupu]

@nicholasio , yeah. It worked when using a variable. Being inside Kubernetes we had to use the service name in the env variable because the origin was the pod ID initially. Either the service name or the main URL of the website works. The issue with using the final URL of the website is that it will go outside the network and then again inside which is a bit slower. Not the end of the world, but using the service name instead, which keeps the request inside the network, is better.

[magnusriga]

Late to the party here, but a small note on how we did this:

1. We never use the nextUrl property, due to Next.js' modifications. We found it more reliable to use the WebStandard properties on the request object, like the url and the headers.

2. For most of our middleware host logic, we just grab the Host header: new Headers(request.headers).get('Host'). Not sure if that is useful here.

Are you seeing an app slowdown, due to fetches in middleware? I am considering adding a small redis fetch in middleware, but worried it will slow middleware down. It is being used by prefetches and so on, so needs to be fast.