Redirects with custom express server

[Cowboy-coder]

We have problems getting redirects to work if the redirect.source url matches an already existing express route.

Given the following redirect rule in next.config.js:

async redirects() {
    return [
      {
        source: '/foo',
        destination: '/foobar',
        permanent: true,
      },
    ]
  },

and the following server.js

app.prepare().then(() => {
  const server = express()

  server.get('/foo', (req, res) => {
    return app.render(req, res, '/foo')
  })

  server.all('*', (req, res) => {
    return handle(req, res)
  })

  server.listen(port)
})

The redirect from /foo to /foobar only works if we remove this route

server.get('/foo', (req, res) => {
    return app.render(req, res, '/foo')
})

To me it seems like redirects only happen AFTER route matching and only if it doesn't match an already existing route. This seems a bit weird to me, can someone shed some light on if we are using redirects in the wrong way?

[janus-reith]

I would consider it weird if it behaved the other way around.

You're using a custom express server, and for some routes you pass them to the nextjs handler inside that express server.
The express server itself doesn't know anything about next.config,js or nextjs-specific functionality like redirects.

Now if the /foo express route doesn't even call the nextjs handler, how could nextjs possibly know about any redirects to apply?

If instead of that express route you would be using nextjs api routes, they would be within the scope of nextjs routing and you could redirect to/from them. Maybe check if you actually need to rely on that express server at all.

If you need to use the express server however, you can still handle rewites and redirects inside of that.

[Cowboy-coder]

I would consider it weird if it behaved the other way around.

Why would it be weird?

You're using a custom express server, and for some routes you pass them to the nextjs handler inside that express server.
The express server itself doesn't know anything about next.config,js or nextjs-specific functionality like redirects.

The express server doesnt need to know anything about next.js or redirects. Im thinking a call to either handle() or app.render could check the redirect mapping before it actually renders the nextjs app.

Now if the /foo express route doesn't even call the nextjs handler, how could nextjs possibly know about any redirects to apply?

Im not following, in my example I explicitly call app.render for /foo and for all other routes i call handle() so all urls should be next.js - aware.
Of course if you for example manually call server.get('/health, (req, res) => res.send('OK')) the next js framework wouldn't be aware of any redirects, but that makes sense cause im opting out completely of next.js handling anything for that express-route.

If instead of that express route you would be using nextjs api routes, they would be within the scope of nextjs routing and you could redirect to/from them. Maybe check if you actually need to rely on that express server at all.

Ah, need to investigate. I have never used nextjs api routes.

If you need to use the express server however, you can still handle rewites and redirects inside of that.

I know, we do it like that for another project, but I was hoping this new redirect-feature could be used instead of rolling our own solution for redirect mappings.

[janus-reith]

Im not following, in my example I explicitly call app.render for /foo and for all other routes i call handle() so all urls should be next.js - aware.

I agree, technically I guess it should work out to apply redirets to render calls by passing these calls to the router in next-server.ts, although still that's not how I would've expected render to work.

While I still couldn't really get the usecase for defining an express route for that one explicit path and then redirect it somewhere else, I guess you'll have your resons, so I'll try to focus on the actual difference you would get by using render instead of just handle, beside that handle uses the router.
While handle will match anything coming from req.url, with render you would be able to just get one explicit path directy, which is not necessarily one coming from the request <- Is this what you're after? (Although again in this case, I'd prefer the router to not interfere).

Indeed there seems to be no exposed function for this, and I wonder if creating some small public function that simply wraps handleRequest would be a possibility here. It could take req, res and pathname, call parse on pathname and then pass things to handleRequest

From what I see, that would support your usecase where you pass one explicit path and still want the Router to handle it?