Dynamic Redirects, best way?

[ndimatteo]

Hey there!

I'm wondering what everyone's opinions are on how to properly generate page redirects that are defined outside of Next?

For example, I have data coming from Sanity.io where a client would maintain a list of redirects (with from, to, and isPermanent fields). How can I take that data and generate redirects within NextJS? It's possible that the redirect from URL could cross multiple dynamic and static pages defined within Next.

My initial solution was to write these redirects to vercel.json in my build scripts, but unfortunately, Vercel reads the config file BEFORE build scripts are run so the redirects are never read through.

I feel this solution would be such a clean solution for setting these up, but with how Vercel deploys projects it seems unlikely this solution will work without a core update from the Vercel team.

The goal is to avoid:

1. hardcoding the redirects in the codebase.
2. Setting up a 3rd-party service to write these on deploy
3. Adding these into each page template via getStaticProps (especially when the redirects are "unknown")

Thoughts?

[ArrayKnight]

I was just about to start testing this exact same approach, using a headless CMS on a separate domain from the site to manage redirect and then a pre-build step to update the vercel.json redirects via webhook and local script.

We had questions about whether the vercel.json could even be modified (possibly not being allowed to write to fs at all) or if we could even manage to do it early enough in the process for vercel to pick up the new version rather than the repo version.

Glad I found this before investing a bunch of time down this path.

But we had another path to venture:
Using our webhook to trigger a Github action, which modifies and commits the vercel.json file. Not quite as simple or clean but it bypasses vercel completely.

Did you come up with a different/better solution?

[ndimatteo]

@ArrayKnight since posting this there have been a number of updates to the Next platform and I was able to easily do this with the new way they handle redirects. You can read more about it in their docs, but I found it as simple as this for a Sanity powered site:

// get redirects from Sanity for Vercel
async function fetchSanityRedirects() {
  const data = await client.fetch(
    `*[_type == "redirect"]{ from, to, isPermanent }`
  )

  const redirects = data.map((redirect) => {
    return {
      source: `/${redirect.from}`,
      destination: `/${redirect.to}`,
      permanent: redirect.isPermanent,
    }
  })

  return redirects
}

module.exports = {
  async redirects() {
    const sanityRedirects = await fetchSanityRedirects()
    return sanityRedirects
  }
}

[rodrigo-arias]

I'm doing something similar with WordPress and Redirection. The two problems I have faced:

• Need to rebuild to get new redirects added
• Validation to prevent the build from breaking if invalid redirects are added in the CMS. On this point, the hard part is that the regexp don't match directly with the format of Next.js Redirects

[danijelglisic]

Hey, I have error in next.config.js file because client is not recognized but when I import it there is error because import statement outside a module. How I can solve this like you in this example?

[ndimatteo]

@danijelglisic you'll need to import the Sanity client in next.config.js like this to avoid that error:

const sanityClient = require('@sanity/client')

[notflip]

@rodrigo-arias Which method are you using now? (I know it's 2 years later, but I'm curious if you ever got around these two problems you mention

[rodrigo-arias]

@notflip Not really. I tried two approaches:

• A custom nextConfig wrapper that fetched, validated, and normalized redirects and added feedback if something was off, along with a cron job that ran a couple of times daily and triggered a rebuild if new redirects were added. It worked but was far from ideal.
• The official Middleware approach. It solved the rebuild issue but required keeping Redis in sync since users didn't want to leave the CMS to manage redirects. This gets around the limit of 1,024 redirects but adds too much complexity.
  

[Kyoss79]

To be honest, this is such a bummer and kind of a dealbreaker for our company.
It's really sad that it took us this long to discover this behaviour in nextjs.

Just a short headsup for everyone who stumbles over this issue just like me and is clueless.

NextJS does only generate the redirects from next.config.js at build-time. Although it is an async function,
that function is only called during the build.

I was under the impression, that this function would get called repeatedly in production, and was wondering how often that would happen. The answer is zero times.

So you can make redirects kind of dynamic, as in load them from an external service, but you can not make them dynamic, as in they will update automatically in production.

Triggering a new build for a new redirect per webhook is kind of a no-go for big sites who basically have hundreds or thousand of redirects. (don't ask me why, for a typo, for a rename of the url, for SEO purposes). This would lead to dozens of redundant and concurrent builds every week in my current project.

What I really needed was an ISR-like method that gets called every XX seconds and repupulates the redirects.

[smakman]

When using Vercel you could store your redirects in Vercel's Edge Config and handle the redirects in your middleware:

// middleware.js
import { NextResponse } from "next/server";
import { get } from "@vercel/edge-config";

export async function middleware(request) {
  const redirect = (await get("redirects")).find(({ source }) => source === request.nextUrl.pathname);

  if (redirect) {
    return NextResponse.redirect(new URL(redirect.destination, request.url), {
      status: redirect.permanent ? 308 : 307,
    });
  }
}

export const config = {
  matcher: [
    '/((?!api|_next/static|_next/image|favicon.ico).*)'
  ]
};

Your Vercel Edge Config can be updated with the Vercel REST API and would look like:

{
  "redirects": [
    {
      "source": "/from",
      "destination": "/to",
      "permanent": true
    }
  ]
}

[Kyoss79]

I mean sure, this works. But is it feasible? If hundreds of your users request the same URL, its going to make hundreds of middleware requests to your Edge Config repeatedly. Even if there are zero results for a given URL.
I am not happy with implementing "solutions" like that.

[smakman]

If you want dynamic redirects you somehow have to match the current route against an external source. It's mentioned here in the Vercel docs as a possible use case for their Edge Config. It also mentions that the latency is negligible (0-15ms). Egde Config does have its limitations though, mainly in terms of number of reads and store size.

[Kyoss79]

@smakman sure, I do agree. But if you have several "negligible" calls on your page that starts to sum up. As I said, those are 99% of the time totally unneeded calls anyway.

My current solution would be to put my project behind a provider that let's me configure redirects even before hitting the NextJS Site. Like Cloudflare.

Another solution no one has mentioned yet, but may be interesting for some: You can create redirects in getStaticProps. So instead of slowing down every request with a middleware, you can ask your backend (or Edge config) in getStaticProps if this page should be redirected.

[smakman]

getStaticProps will only run when a page gets statically (re)rendered, not on every request.

[leerob]

Please check out our new docs here!

https://nextjs.org/docs/app/building-your-application/routing/redirecting

[rodrigo-arias]

@leerob Would you consider adding a kind of On-Demand ISR API that allows us to revalidate the redirects defined in the next.config.js without having to rebuild the entire site?
I understand that an alternative solution can be built using the middleware, but that has some performance costs, and mitigating them requires more complex solutions and probably Redis or an equivalent in Vercel.
Thanks!

[michaelroth-xx]

would be interested in this as well! a revalidate possibility in next.config would be awesome