I just watched the video and I'm wondering about the fact that you don't have preview URLs but instead have a cookie based way to differentiate a preview from the real production version.
Is that really something that makes it easier? Debugging which cookies are used, deleting specific cookies or sharing a specific preview version seems to be a lot harder that way? Or am I missing something?
Having worked on a similar system in the past - it’s a trade-off.
On one hand, all your domains match across all environments/deployments and you can set a cookie and refresh to switch versions fast. Only 1 HTTPS cert and no subdomains to manage. You could invisibly do a slow rollout of deployments by slowly changing cookies. Fun stuff like that.
On the other hand, you have to have special links to set the cookies, and you end up building some kind of environment/version indicator somewhere or else you’ll lose your mind when debugging. And buckle up for when you accidentally switch versions in a different tab instead of using Incognito and screw up some debugging. Or try explaining to a confused marketing person that they’re looking at the wrong version of your landing page because a cookie they don’t know about is set wrong.
It’s all trade-offs. Personally having used both approaches I think the cookie method sounds better than it ends up being in practice. Different domains is uglier, but more clear.
Yep, definitely a tradeoff. Really awesome to hear others have explored this in the past!
I wanted to err on the side of _enabling_ an identical-to-production development workflow, because AFAIK nothing else really offered this. So the cookies approach is what I ended up starting with, and I also built a UI to help make the difference abundantly obvious: https://reflame.app/~r/start-preview/?mode=production&varian...
Even still, subdomains are definitely less confusing though, and doesn't lead to the same kind of strange behaviors that you could only make sense of if you understood exactly how cookies work and how Reflame makes use of them (a tall order, I'm not even sure if I do 100% today). I may eventually also offer a subdomain version of these previews, for those who might be collaborating with less technical folks who are more likely to be confused by the cookie-based implementation.
Assuming an app handles it correctly, unique domains-per-deployment give me the warm fuzzies when debugging. When tracking down a problem, I want there to be no doubt I'm looking at the correct version. Vercel's approach here is nice.
That's a really fair concern, in fact it's one that's bitten me quite a few times. Can't count the times I stared at a page waiting for an update, only to realize I'm looking at production, or vice versa.
This why I ended up building a small UI overlay to show the current preview and allow exiting the preview and switching between prod/dev modes (in fact I just shipped this yesterday in preparation for the launch since I knew it would make a huge difference to developer experience).
Comments
I just watched the video and I'm wondering about the fact that you don't have preview URLs but instead have a cookie based way to differentiate a preview from the real production version.
Is that really something that makes it easier? Debugging which cookies are used, deleting specific cookies or sharing a specific preview version seems to be a lot harder that way? Or am I missing something?
Having worked on a similar system in the past - it’s a trade-off.
On one hand, all your domains match across all environments/deployments and you can set a cookie and refresh to switch versions fast. Only 1 HTTPS cert and no subdomains to manage. You could invisibly do a slow rollout of deployments by slowly changing cookies. Fun stuff like that.
On the other hand, you have to have special links to set the cookies, and you end up building some kind of environment/version indicator somewhere or else you’ll lose your mind when debugging. And buckle up for when you accidentally switch versions in a different tab instead of using Incognito and screw up some debugging. Or try explaining to a confused marketing person that they’re looking at the wrong version of your landing page because a cookie they don’t know about is set wrong.
It’s all trade-offs. Personally having used both approaches I think the cookie method sounds better than it ends up being in practice. Different domains is uglier, but more clear.
Yep, definitely a tradeoff. Really awesome to hear others have explored this in the past!
I wanted to err on the side of _enabling_ an identical-to-production development workflow, because AFAIK nothing else really offered this. So the cookies approach is what I ended up starting with, and I also built a UI to help make the difference abundantly obvious: https://reflame.app/~r/start-preview/?mode=production&varian...
Even still, subdomains are definitely less confusing though, and doesn't lead to the same kind of strange behaviors that you could only make sense of if you understood exactly how cookies work and how Reflame makes use of them (a tall order, I'm not even sure if I do 100% today). I may eventually also offer a subdomain version of these previews, for those who might be collaborating with less technical folks who are more likely to be confused by the cookie-based implementation.
Love the widget!
Assuming an app handles it correctly, unique domains-per-deployment give me the warm fuzzies when debugging. When tracking down a problem, I want there to be no doubt I'm looking at the correct version. Vercel's approach here is nice.
Thanks for the explanation, that makes sense. I think I prefer the more explicit version over the seemingly more elegant version.
That's a really fair concern, in fact it's one that's bitten me quite a few times. Can't count the times I stared at a page waiting for an update, only to realize I'm looking at production, or vice versa.
This why I ended up building a small UI overlay to show the current preview and allow exiting the preview and switching between prod/dev modes (in fact I just shipped this yesterday in preparation for the launch since I knew it would make a huge difference to developer experience).
This is not in the demo because it was recorded a while ago, but take a look at this Live Preview I just created to see what it looks like: https://reflame.app/~r/start-preview/?mode=development&varia...
They are ersatz feature flags