Published by

Exploring the use cases for serverless website architecture

Last Saturday, Sam introduced me to Chris Coyier’s talk on serverless-ness, The All-Powerful Front-End Developer. Pretty interesting and useful. I’m glad he leads it by breaking down the problematic nature of the word “serverless”! The following day was spent in agorama’s p2p workshop at furtherfield. Coincidentally, there is a lot of overlap in these topics.

I’ve spent the past few days wrapping my head around all of this, contextualising it against the sorts of concerns and projects we work with. Though I desperately want to get going with Dat, I’m starting with serverless because it may solve an urgent need in my day-to-day work. Right now, I’m spending much more time than I realistically can maintaining CMSs and hosting environments for older websites.

All of the below is a thought dump on the topic, an attempt to pick apart the meaning of and the use cases for a serverless website architecture.

I am by no means an expert, so if anyone out there in the big wide 🌎 reads this and has suggestions, particularly if I’ve misstated anything, let me know.

I am very new to the many faces of serverless. To learn something new, I have to break the task down in to its constituent parts and create a ladder of use cases for myself to climb up. These are the completely subjective levels I’ve broken it in to, starting with the simplest and growing in complexity.

Level 1 = HTML/CSS/JS files + static file hosting

Level 1 is a simple static site typically made up of HTML, CSS, and Javascript. The only difference is the hosting itself.

USE CASES

Sam is doing exactly this with his blog (Jekyll + GitHub Pages) and site (Pug + Gulp + Netlify).

We’re also doing this with our some of our SB-PH docs. We write our standard project scope and terms of service in Markdown so that we can keep the content in version control, and they’re hosted on GitHub Pages so that we can send the docs easily to our clients via URLs. This sort of setup is really useful for most of our day-to-day requirements as developers. It’s ridiculously simple, particularly when you factor in continuous deployment and free SSL.

Another great example is Tara Vancil’s site published via the p2p web. See her how-to post for more info. The Dat protocol involves static files and does not involve a server. See recent post by Paul Frazee on the current state of dat:// sites + servers. I won’t go in to detail on the p2p web here because it is getting its own deep-dive.

ANTICIPATED COST

This seems pretty easy on the wallet as far as I can tell. Basic static file hosting for http:// / https:// sites is cheap. For dat:// sites, it’s basically free!

POTENTIAL DOWNSIDES

This is great for simple sites, particularly dev-authored content. It’s not so great for content editors that aren’t as code-literate. Also, relational data isn’t that easy to manage. On to Level 2.

Level 2 = Level 1 + data source + cloud functions

Level 2 introduces servers in to serverless. This is why serverless as a term is sort of a misnomer. Though it can mean “no server involved”, it usually means “someone else handles the server maintenance”. The functionality provided by a server is still important, for good reason.

If you need to store complex data and access it via an API, you probably need a platform with a server. There are a lot of data storage platforms available with a wide variety of functionality. This was written about recently on the Codepen blog, see Need to store some data?.

If you want to get info from an API, you usually need to connect to it using an API key. API keys must be kept secret in order to keep your data secure. In the vast majority of cases, you must connect to an API on the server-side, to protect your super-secret keys. Cloud functions allow you to connect to an API on the server-side without forcing you to maintain a server environment. A few cloud function service providers include Firebase, Webtask, and Netlify.

USE CASES

We’re currently exploring the front-end code + data source + cloud functions route to create a semi-public work archive for SB-PH, and to keep track of / share our library (as in real books). In both cases, we’re using Airtable to store the data and Vue for the front-end. We’ll probably host these sites on Netlify. I’m connecting to the Airtable API with Webtask currently since Coyier’s video is effectively a little tutorial on Webtask (see around 19:53 mark).

ANTICIPATED COST

As with Level 1, the cost of Level 2 is generally pretty attractive. That said, the bottom line very much depends upon the exact services you choose and the traffic that your site gets. Rate limiting is your friend.

POTENTIAL DOWNSIDES

A bigger network of services means more potential points of failure. This is why I get nervous when a setup involves more than one SaaS platform. Stay skeptical and choosy.

On a related note, consider service account ownership from the start when integrating a particular service in a client’s website. As a rule, we always set up separate accounts for our clients with any required services as opposed to piggybacking them on our own. Note that this is a personal preference; a lot of developers handle this differently, particularly when they have ongoing maintenance retainers in place with their clients. For our part, we prefer this separation so that we don’t have to untangle a client’s services from ours down the line if/when it becomes necessary to do so. We also don’t have any interest in a client being tied down to us as developers, if they need to work with anyone else for any reason they should be able to. And a final, maybe the most important, reason: ownership involves responsibility. When a client is given explicit ownership and control over their own website-related services and accounts – hosting, domain registration, CMS administration, etc. – in my experience they are usually (not always!) more responsible about the website as a whole.

Another potential downside is that even a data source with a slick UI à la Airtable may be an unsuitable editing experience for someone that is not all that tech-friendly. Likewise, larger organisations frequently need more high-level CMS functionality. On to Level 3.

Level 3 = Level 1 + managed headless CMS + cloud functions

Level 3 is very similar to Level 2, but the data source is a managed headless CMS.

By “managed headless CMS”, I mean a service provider that hosts the CMS, maintains the CMS, and maintains the hosting environment. Some people refer to this as Content as a Service, or CaaS. On the flip side, you can have an un-managed headless CMS. This would be a self-hosted CMS with a RESTful API / can output JSON. A lot of great, wildly popular CMSs work for this. Kirby CMS would be my first stop. Though Kirby is not perfect for every use case, it has my ❤️ due to the community surrounding it and the overall design. The Studio Scholz site is an example of this (Vue + Kirby). Kirby requires a server though, so let’s get back to serverless.

There are many functionality requirements that might push you from more generic data storage to a managed headless CMS. Here are just a few (besides a more user-friendly UI):

  • Global entries/fields for site-wide information like a menu or address
  • Relational fields which ideally update themselves if the pointed-to content is hidden/removed
  • Multiple users, with customisable tiers of user permissions
  • Drafts / versioning / “marked for review” capability
  • Content scheduling
  • Multilingual support
  • Serverside image resizing

Of course, not all CMSs are created equal. This has always been true with more server-full CMSs (see WordPress.org, Kirby, Craft, ExpressionEngine, etc.), and it remains the case with managed headless CMSs.

When selecting a CMS, you have to weigh up its overall appropriateness for the use case at hand. “Appropriateness” can encompass: immediate budget, ongoing budget, functionality requirements, future plans, licensing model, the associated dev community, support level, viability/history behind the CMS provider, and so on.

If there are a thousand things to weigh up when choosing a traditional CMS, there are a million things with a managed headless CMS. To all of the above, add considerations regarding bandwidth, API request limits, amount of webspace, etc. Selecting a managed headless CMS is no small task, but the benefits can be substantial if cutting out management requirements is the goal.

USE CASES

This level is where serverless becomes truly viable, and possibly preferable, for client projects.

Take our current situation at SB-PH as an example. As the number of sites we have developed goes up, so does the relative amount of server maintenance we get asked to perform.

This isn’t great for our clients. It can be hard to budget for maintenance, who wants to put money towards fixing up a legacy system when it could go towards more exciting things? Maintenance inevitably feels like a boring, frustrating, and jargon-riddled obligation.

This also isn’t great for me because it takes me away from the work I want to be focusing on. I actually don’t mind server maintenance, it can be an interesting puzzle to solve. But the bulk of the time, I would much rather be developing actual websites or adding new, useful features to our existing websites. Regardless, it’s a problem we need to solve, fast. We can either hire someone to handle server maintenance – not something we want to do right now, we’re happy with our small footprint and the flexibility that provides us – or go serverless.

Before jumping in to this for a client site though, I’ll try out a managed headless CMS setup with a personal project. I’m probably going to start with an archive of all of the hand-written recipes from friends and family I’ve collected over the years. Since part of the purpose of this exercise is to “test drive” a headless CMS as if it were a client’s site, I’m going to use one that I expect will satisfy our usual client site requirements. Currently, Sanity seems like a good fit. I believe it was originally created by Bengler when they were working on the OMA website. Apparently Sanity also drives the Center for Advanced Visual Studies Special Collection site. I’m impressed with the community surrounding it thus far, and their support for TIFF resizing and image hotspots is pretty cool. I won’t realistically be able to use it for client sites just yet since they don’t have single entry support, but that’s on their roadmap and is expected for later this summer.

I’ll probably consider Netlify CMS with Hugo or Gatsby in the future for other personal projects, but that’s not realistically a route I’ll ever go down for a client site since it’s linked to a GitHub account. I would consider Shifter for this WordPress blog, but TBH I’m probably going to keep this site on traditional hosting for the foreseeable since that in itself is an interesting ongoing learning experience.

ANTICIPATED COST

The pricing differences between these platforms, and even the tiers within each platform, are wild. It’s hard to provide much of a cost run-down without this post getting significantly longer than it already is… At first glance, the most attractive in terms of pricing seem to be, in order of most attractive to least: Netlify CMS, Sanity, GraphCMS, Contentful.

POTENTIAL DOWNSIDES

The cost. It seems like the recurring cost of a managed headless CMS can go up exponentially as a site grows. This would worry me a little if I were proposing it to a client. That said, the cost of hosting and server maintenance is baked-in, so that should be more straightforward for budget planning than suddenly needing to fork out for unexpected maintenance.

The other possible downside is the actual service provider. Going down the managed headless CMS route is kind of like putting all of your eggs in one basket. Since it forms the foundation of the website, you need to trust that it isn’t going to just disappear (case in point). You also need to trust that their hosting will be secure and reliable. And finally, you need to cross your fingers that they aren’t going to drastically change their pricing model down the line.

All of this is why I would probably lean towards an EU-based headless CMS provider, even if I weren’t based in the EU. With the GDPR that recently came in to effect, companies that operate in the EU are required by law to make EU citizens’ data portable. That gives me a little more peace of mind in the event that we decide, or need, to jump ship to another provider. The GDPR-compliant and EU-based managed headless CMS providers that I am currently aware of are Sanity and GraphCMS. Providers that are not in the EU but address GDPR clearly in their documentation include Netlify CMS and Contentful. Note that Netlify CMS is pretty heavily tied to GitHub.

Overall, the landscape of managed headless CMS providers kind of feels like the wild west. There are a ton of providers out there, but only a very select few I feel jazzed about. Many are out of our clients’ usual budget, poorly designed, overpowered for our usual needs, or just otherwise a little sketchy / not the right vibe. I’m sure it’ll all level out at some point, but it makes me feel a little skittish currently.

Level 4 = Levels 3 + further APIs

This is the multi-headed beast route. You might go down this route for an e-commerce site. One example would be to use a managed headless CMS for the majority of content + the Shopify API for e-commerce. I’m not going to go in to a ton of detail here since I’ve got plenty to explore in everything above. Suffice it to say, the sky is the limit (so long as time/budget is too!).

All that thinking-via-writing, and yet I still feel like I’ve barely scratched the surface. I need to continue sweeping across potential serverless setups and also narrow things down a bit further. These are a few of the questions I’ll keep asking myself as I keep digging:

  • Are you overcomplicating things? If so, take a few steps back.
  • Is this going to be understandable and enjoyable for the content editor? If not, look elsewhere. The longevity of a site ultimately lives and dies by the person that interacts with it on a regular basis.
  • Is this within the budget, both short- and long-term? Answer carefully, considering the non-physical currency – time, emotion, etc. – involved in some projects.
  • Do you like the dev community that surrounds this? Rephrased: would you actively look forward to meeting the average dev involved in this tech for a drink or coffee? You’re going to be neck-deep in this every day so if it’s your choice, make it a good one.

Serverless seems promising, but ultimately no one approach is the queen of web dev. Turf wars are backwards, unnecessary, and not relevant in a landscape so vast. Keep your eyes and ears open, recognise your weaknesses, try to have fun, and surround yourself with good people whenever it is within your power to do so.

I said it above and I’ll say it again. If anyone out there in the big wide world happens to read this and has suggestions, tell me. Find me on Twitter or send me an email at mail@piperhaywood.com.

The scribbles above kind of encompass where my head’s at with this topic; a little all over the place, with maybe the slightest inkling of a composition. They were made with an iOS app I really enjoy called Sketches. The nicest song I heard today was “If You Go Away” sung by Scott Walker, thanks to Sam for that and many other songs.

Edit 14.06.18 at 8:43
Suggestions/fixes from Sam:
1. Misstated his site setup, fixed that.
2. Said that Netlify CMS was hosted on GitHub, which probably isn’t right. It is heavily tied to it, but I haven’t got the exact relationship straight yet.
3. Added an example of a Kirby + Vue site.