Description
As we’ve seen so far, Next and Vercel combo is limited in that the transformation of an outgoing response is not directly supported, which is why the redirio middleware resorts to using an additional passthrough fetch to gain access to the actual response.
This functionality is important for many redirio features, such as transformation of the body.
- We can say that with some rules redirio sometimes needs only the request, lets call that Step 1 - log, redirection, status code, headers.
- While with other rules redirio also needs the response, lets call that Step 2 - body manipulation.
Issues:
On the other hand, this approach also creates various issues.
- We are seeing 2x middleware invocation metrics in Vercel and Netlify (most common ways of deploying Next).
- And lower lighthouse scores as middleware invocation lasts longer than a proxy does (2 calls each time, usually 60ms and 120ms)
- (not verified!) I've received reports that the second, internal, fetch, is logged as coming from the Vercel IP, in the Vercel Monitoring, which, again, makes it unusable.
Argument
My argument is that implementing full redirio functionality is, with current limitations in this framework and its ecosystem, simply bad.
These drawbacks prevent the users from using most of redirio functionalities, which would work totally fine, without ever seeing the response - redirections and headers. Arguably the primary usage of redirio.
While the current middleware will perfectly serve a great many users, there is a large mini-enterprise segment of this market that will, like myself and other teams in my company, be unable to utilize redirio in a reasonable manner due to these tradeoffs.
To quote my Head of SEO colleague Dragan: "god damn i just need 50k redirections that respond within 10ms" 😆
Suggestion
I’d like to implement a flag, that will drop the Step 2 in the middleware. If active (default should be false) this will prevent the Step 2 from happening, thereby making it impossible to use certain Redirectionio functionalities, but in turn will not need the response body, and can therefore ease the use for the happy path use cases, where 99% of our expected usage is to use redirections and header setting.
Do you think this would be possible? I am willing to invest engineering resources to implement this in a PR, but might need some guidance regarding the feasibility of the idea.
Alternatives
- Using managed instances, works fine, but has a drawback that it makes Vercel CDN largely irrelevant, and Vercel WAF and Vercel Monitors kinda unusable.
- Since non-enterprise plans don’t support “trusted proxy” feature, we can’t rely on forwarded IPs or Vercel WAF. This combined with double middleware invocations also baloons the Vercel Monitoring costs.
- Additionally, redirio IP ranges aren’t static which makes it near impossible to implement whitelisting on these providers, unless the project is on an enterprise plan, in which case they are more likely to use the Cloudflare worker anyway.
- Using self-hosted agent has the exact same issues.
- Using CloudFlare is possibly all-around the best way to implement Redirection.io, but CF comes with additional costs, and it is the official opinion of Vercel that no CDN or proxy should be used in front of it, unless the user is on and enteprise plan. It suffers from similar issues as the above, but lessened by at least having a powerful CDN/WAF/Metrics in the mix. It also comes with significant cost bump (in the specific case I am working with this month, some 500 EUR/mo).
- I'd love it if we were able to find a new approach for a native Next.js middleware. Xavier and Joël pointed in one of their emails that there is a possible new avenue of some sort. But from everything that I've read online, there doesn't seem to be an alternative, and a policy change on the Next.js side is unlikely to happen, as this behaviour seems deeply entrenched in their architecture.