The team at Slate is in the midst of a project we refer to as Redux, an effort that includes almost every person at the magazine. For the website, the project involves a complete rewrite of our code and new design to implement at the same time.
Our goal is speed: Readers should be able to get to what they want quickly, writers should be able to swiftly publish their posts, and developers should be able to code with speed.
Rather than having a single big launch day, we’re going for an incremental approach to Redux. We want to bite off the smallest and thorniest problems one at a time, tackle them as quickly as possible, and fix other things as we go.
The team started with the Cover Stories that Slate publishes once a week, then moved to an article or two every day. Eventually we’ll be publishing all articles in the new system. Finally, we’ll start migrating old articles into Redux sometime next year.
Just recently, we hit a very significant milestone: a new URL.
As a web developer and product dabbler, I love URLs. URLs say a tremendous amount about an application’s structure, and their predictability is a testament to the elegance of the systems behind them. A good URL should let you play with it and find delightful new things as you do.
Each little piece of our new URL took a significant amount of planning and effort by the Slate tech team. Let’s break it down:
Scheme
The next iteration of Slate is running on https. That secure s should give users more confidence in Slate and will even speed up site delivery, since some new web tech is limited to secure connections. It may only be one character in the URL, but it can take some lift to run a site on https. With https, everything you view on Slate is encrypted. The web is moving in this direction, and browsers are going to start flagging any website that’s not running on https, so we had to make this a priority in our transition.
We chose a complete rewrite of the site as a time to introduce https because it helps us avoid the cumbersome task of going through the existing site and finding all the tiny images and scripts that have been added over the years with non-https URLs. We’ll be running automated tests to try to catch any insecure resource, but should you ever see a warning about https on a new Slate article, we want to hear about it!
Domain
You may have noticed that there’s no more www on our new article URLs, just a bare slate.com. We’re now using something called our “zone apex.” Apex domains (also known as “bare,” “root,” or “naked” domains) aren’t easy to work with due to some intricacies in the DNS specification, but it was worth the trouble. Using our apex domain alongside our old site running on www lets us easily publish in two different systems with completely different software stacks that both look legitimate to our users. If readers clicked onto articles on https://redux.slate.com (which, incidentally, is what our first 10 pieces were on), they might think they’re being phished or start asking questions about the domain when we want them reading the story.
Besides, top-level domains are super hip.
Path
You wouldn’t believe the number of meetings it can take to decide whether a URL should say /articles/news-and-politics/2017/06/fear-of-the-first-amendment-in-time-of-violent-protests.html, /news-and-politics/2017-07-06/fear-of-the-first-amendment-in-time-of-violent-protests.html, or some combination of those. In a push for simplicity and usability, a new article URL will only have the section (in this case “news-and-politics”) and use the month for its date in the path.
One wonderful difference between our old and new CMSes: If our editors change the URLs, the new CMS knows to keep track of the old ones and redirect users intelligently. No longer will an article about bitcoin that was accidentally posted in /arts/ have to hold onto its URL forever.
Once more articles are being written in the new system, we’ll let folks remove the title, month, and year to see all the pieces from that section. With a simplified URL, future releases can allow for any pieces of the path to have good, predictable lists of content.
Handling Our Old URLs
We already had a lot of things happening on the apex domain. Like many other Amazon Web Services customers, we were using a tiny server to redirect traffic from http://slate.com to http://www.slate.com whenever users typed slate.com directly into their browsers. Over the years, various developers and system administrators had said, “Hey, why don’t we use that little server for this other thing that came up?” And, of course, they did. So now the little configuration that just added “www” was handling random things like configurations for our iOS app, redirecting one-off websites, and more.
Luckily, when we were building the new stack for Redux, we also chose to use a service called Fastly. Fastly is a content delivery network and more. What we love about it is that it lets us use varnish configuration language to write our rules for how traffic is routed, as opposed to some of the harder-to-wrangle configuration languages for other CDNs (looking at you, XML). VCL means that we can make updates quickly in a relatively readable language and keep those updates under version control. Because we now keep these rules in code and put it through code review just like everything else, we’re much more comfortable pushing logic to the edge.
Now instead of using a small server that costs a few dollars a day and represents a potential point of failure, we can push all the rules about routing Slate traffic to this or that endpoint and various redirects into a few files that live on Fastly. It’s speedy, easy to update, and saves us money.
What’s Ahead
This new URL represents a lot of work, but it is just the beginning of the user-facing features of Redux. In the next few weeks you’ll be seeing more articles written in the new system, new section landing pages, custom elements for Slate Plus members, topic pages, and more. We’ve only just begun.
