Blurring the Line Between CDN and CMS
10th October, 2017
In plain English, you’ll be able to write code that changes the content, headers, look, feel and behaviour of your pages via the Cloudflare CDN. You can do this without making development changes on your servers, and without having to integrate into existing site logic.
Why is this helpful?
As SEOs, we frequently work with sites that need technical improvements or changes. But development queues are often slow, resources restricted, and website platforms complex to change. It’s hard to get things changed or added.
Service workers on the edge
Cloudflare, like other CDNs, has servers all over the world. When users request a URL on your website, they’re automatically routed to the nearest geographic ‘edge node’, so that users access the site via a fast, local connection. This is pretty standard stuff.
What’s new, however, is that you can now write code which runs at those edge nodes, which allows fine-grained control over how the page is presented to the end user based on their location, or using any logic you care to specify.
With full control over the response from the CDN, it’s possible to write scripts which change title tags, alter canonical URLs, redirect the user, change HTTP headers, or which add completely new functionality; you can adapt, change, delete, build upon or build around anything in the content which is returned from the server.
It’s worth noting that other platforms, like AWS, already launched something like this in July 2017. The concept of making changes at the edge isn’t completely new, but AWS uses a different approach and technology stack.
Cloudflare’s solution is based on the Service Worker API (as opposed to Node.js), which might look like a more future-proof approach.
Service workers are the current framework of choice for progressive web apps (PWAs), managing structured markup, and playing with new/emerging formats as Google (and the wider web) moves from favouring traditional websites to embracing more app-like experiences. That makes it a good skill set to learn, to use, and potentially to recycle existing code and solutions from elsewhere in your ecosystem.
That PWAs look likely to be the next (arguably, the current) big thing means that service workers aren’t going anywhere anytime soon, but Node.js might just be the current flavour of the month.
Cloudflare provides a sandbox for you to test and visualise changes on any website, though it’s unclear whether this is part of their launch marketing or something which will be around for the long-term (or a component of the editor/deployment system itself).
That’s a lot of power to play with, and I was keen to explore what it looks like in practice.
It took me just a few minutes to modify one of the scripts on their announcement page to add the word ‘awesome’ (in a pleasing shade of orange) to Distilled’s homepage. You can check out the code here.
Service workers can be complex to work with, too. For example, all of your changes are asynchronous; they all run in parallel, at the same time. That makes things lightning-fast, but it means that some complex logic that relies on specific ordering or on dependencies might be challenging to write and maintain.
And with all of this, there’s also no nice WYSIWYG interface, guides or tutorials (other than general JS or service worker questions on StackOverflow). You’ll be flying by the seat of your pants, spending most of your time trying to work out why your code doesn’t work. And if you need to turn to your developers for help, you’re back at our initial problem – they’re busy, they have other priorities, and you’re fighting for resources.
A meta CMS is not a toy
As we increasingly find ourselves turning to workarounds for long development cycles, issues which “can’t be fixed”, and resolving technical challenges, it’s tempting to see solutions like Google Tag Manager and Cloudflare Workers as viable solutions.
If we can’t get the thing fixed, we can patch over it with a temporary solution which we can deploy ‘higher up the stack’ (a level ‘above’/before the CMS), and perhaps reprioritise and revisit the actual problem at a later date.
You can fix your broken redirects. You can migrate to HTTPS and HTTP/2. You can work through all those minor template errors which the development team will never get to.
But as this way of working becomes a habit, it’s not unusual to find that the solutions we’re using (whether it’s Google Tag Manager, Cloudflare, or our own ODN) take on the characteristics of ‘Meta CMSs’; systems which increasingly override our templates, content and page logic, and which use CMS-like logic to determine what the end-user sees.
Over time, we build up more and more rules and replacement, until we find that there’s a blurring of lines between which bits of our website and content we manage in each platform.
This creates a bunch of risks and challenges, such as:
- What happens when the underlying code changes, or when rules conflict?
If you’re using a tag manager or CDN to layer changes ‘on top’ of HTML code and pages, what happens when developers make changes to the underlying site logic?
More often than not, the rules you’ve defined to layer your changes break, with potentially disastrous consequences. And when you’ve multiple rules with conflicting directives, how do you manage which ones win?
- How do you know what does what?
When you’ve got lots of rules or particularly complex scripts, you’ll need a logging or documentation process to provide human-friendly overviews of how all of the moving parts work and interact.
- Who logs what’s where?
If conflicts arise, or if you want to update or make new changes you’ll need to edit or build on top of your existing systems. But how do you know which systems – your CMS or your meta CMS – are controlling which bits of the templates, content and pages you want to modify?
You’ve got rules and logic in multiple places, and it’s a headache keeping track.
When the CEO asks why the page he’s looking at is broken, how do you begin to work out why, and where, things have gone wrong?
- How do you do QA and testing?
Unless your systems provide an easy way to preview changes, and allow you to expose testing URLs for the purposes of QA, browser testing and similar, you’ve got a system with a lot of power and very little quality control. At the moment, it doesn’t look like Cloudflare supports this.
- How do you manage access and versioning?
As your rules change, evolve and layer over time, you’ll need a way of managing version control, change logging, and access/permissions. It’s unclear if, or how Cloudflare will attack this at the moment, but the rest of their ecosystem is generally lacking in this regard.
- How do you prevent accidental exposure/caching/PII etc?
When you’ve full access to every piece of data flowing to or from the server, you can very easily do things which you probably shouldn’t – even accidentally. It doesn’t take much to accidentally store, save, or expose private user information, credit card transaction details, and other sensitive content.
In general, then, relying overly on your CDN as a meta CMS feels like a risky solution. It’s good for patching over problems, but it’s going to cause operational and organisational headaches.
That’s not to say that it’s not a useful tool, though. If you’re already on Cloudflare, and you have complex challenges which you can resolve as a one-off fix using Cloudflare Workers, then it’s a great way to bypass the issue and get some easy wins.
Alternatively, if you need to execute geographically specific content, caching or redirect logic (at the closest local edge node to the user), then this is a really great tool – there are definitely use cases around geographically/legally restricted content where this is the perfect tool for the job.
Otherwise, it feels like trying to fix the problem is almost always going to be the better solution. Even if your developers are slow, you’re better off addressing the underlying issues at their source than patching on layers of (potentially unstable) fixes over the top.
Sometimes, Cloudflare Workers will be an elegant solution. But, more often than not, you should try to fix things the old-fashioned way.