Recently, we migrated domain of our APIs to a new domain. our recent API migration to a new domain. let's dive into the nitty-gritty of "how" for now. We'll save the "why" for another post.
A quick rundown of the product.
FeedbackSpark is an in-product survey tool designed specifically for SaaS Product teams. Not only does it allow you to create surveys within your product, but it also offers Link surveys and surveys that can be embedded right into your emails.
Our problem
Now, here's the thing about the migration. Changing the API domain wasn't a big deal for in-product surveys and link surveys since they always use the most up-to-date API routes. However, we had to consider the survey links that were already embedded in emails sent to end users. Keep in mind that these are POST API routes used for collecting responses, which is an important detail.
Our options
We could've done a 301/302 redirect to the new domain, but there's a catch. While this solution is simple to implement and works well for GET APIs, it doesn't play nicely with POST requests. You see, 301 and 302 redirects have a tendency to lose the POST request data. We did some digging and came across a Stack Overflow answer mentioning the 307 redirect, which supposedly keeps the POST request data intact. But here's the kicker: it's not entirely reliable. Browsers like Firefox, Safari, and Opera might still discard the POST data.
After weighing our options, we decided to go with a different approach. We pointed both domains to the API backend, allowing both API routes to work seamlessly. This way, we could ask customers to update the URL in their embedded emails whenever possible and wait for the traffic on the old URL to naturally die down. It felt like a cleaner and safer solution to avoid any potential data loss.
How to do this on AWS?
First, head over to your Amazon EC2 console and navigate to the load balancers section in the navigation menu.
Find your load balancer and select the listener you want to modify (usually HTTPS these days).
Click on "view/edit rules" and then "Add rule" to create a new rule.
In the conditions section, choose "Host Header" and add both domains as a single rule. Since both domains will point to the same Target Group (backend), we used a single rule for simplicity.
For actions, select "Forward to..." and choose the appropriate target group.
Save the rule, and you're almost there!
The final step is to point the DNS records of both domains to your load balancer. Once that's done, give it a test to make sure everything is working as expected.
And there you have it! That's how we migrated our APIs to a new domain while ensuring a seamless experience for our users. I hope this gives you a better understanding of the process we went through. If you have any questions or want to chat more about it, feel free to reach out.
Photo by Jorge Tung on Unsplash
Top comments (0)