Decision needed: Backward compatibility for legacy v1 URLs? #500
Description
Question
Do we need to support legacy v1 shareable URLs?
Context
This came up while reviewing the app split PR (#494). Once the website and calculator are on separate domains:
- Website:
policyengine.org - Calculator:
app.policyengine.org
We initially thought simple redirects from website → calculator would handle old links. However, v1 and v2 use completely different URL formats, so redirects alone won't work.
URL Format Differences
| Version | Example URL |
|---|---|
| V1 | /uk/policy?reform=94906&baseline=1&focus=policyOutput.policyBreakdown®ion=uk&timePeriod=2026 |
| V2 | /uk/report-output/:reportId/:subpage/:view |
Key differences:
- V1 uses singular routes (
/policy,/household,/population-impact) - V2 uses plural routes (
/policies,/households,/report-output) - V1 encodes state in query params (
?reform=...&baseline=...) - V2 uses path-based IDs and database-backed resources
Current State
- V1 URLs (e.g., from old blog posts) show "App not found" on both
policyengine.organdapp.policyengine.org - V2 has no translation logic for v1 URL format
- Simple redirects won't work - the v2 app doesn't understand v1 query params
Options
Option 1: No backward compatibility
- Old v1 links remain broken
- Users would need to recreate their policies/households in v2
- Simplest approach
Option 2: URL translation middleware
- Build logic to parse v1 query params and create equivalent v2 resources
- Complex: would need to map
reform=94906to a v2 policy ID - May require API calls to translate IDs
Option 3: Maintain v1 app for legacy URLs
- Keep v1 running somewhere for old links
- Adds maintenance burden
Decision Needed
Is backward compatibility for v1 shareable URLs a requirement? The app split PR (#494) would ideally need this resolved.
Related
- PR Add monorepo structure with design system and app split #494 - App split implementation
- Old blog posts contain v1 URLs (e.g., in research articles)