Redirects Discovery
As a piece that was initially being looked at for the purpose of the CMS squad, the needs have been raised elsewhere for this to be a across the Technology department, and the company. This document sets out initial ideas and questions to that this work needs to solve.
Background
The CMS team has been looking at a way to streamline the process of requesting and implementing redirects. So far the team has focused on developing an internal user facing front end application that acts as a "todo list" style of redirects that will communicate with a chosen infrastructure to handle redirects and post a notification of slack. This app should aim to bridge the gap between the business and tech.
Potentially options as a service to handle application redirects have been:
- CloudFlare page rules
- CloudFlare bulk redirects
- Vercel
- Apache server
It is been agreed that we should go down the route of a form submission application rather then a Slackbot.
Initial Findings
Programmatic migration of current page rules Any current redirects, page rules etc must be easily migratable into the new service, and this is often achieved through an API.
Centralised v. De-Centralised redirects Redirects are currently de-centralised often to keep a separation of concerns but also we have a page rule limit in CloudFlare. There is general consensus that in an ideal world we centarlised all redirects into a bulk redirects. Does this have any negative impacts? See here for rule limits.
Complextity of Redirects The vast majority of the time redirects are "URL A to URL B", this would allow for the client application to contain a simple UI as any more complex redirects are unlikely to come from out side the department.
Accountability A single redirect entry needs to have accountability and be traced back to a user(s). Additional data could be added to a redirect rule that include "Requested By", "Implemented By", "Purpose" etc. Is this possible with CloudFlare? Would we need additional database service? Is this requirement deemed priority?
Feedback Loop The client app should be able to not only request new redirects, but should also be able to delete current ones. Beyond this, there should be a round trip of feedback to the developers and user who requested the change. This could include Slack, email, JIRA tickets.
Workflow

Next steps
- Explore further the CloudFlare Bulk Redirect API
- Refine what a user needs to fill out to create a basic redirect rule?
- Refine fields needed for an MVP application to work.
- Refine process post form submission - which other actions should be triggered ? (i.e Slack, MR, email)