Show Notes
Weekly Update
Transcript
Alvin: It’s the fancy new 12-23 thing, isn’t it? Yeah, just to come back on the SEO bit, I think, yeah, as you said, it’s just, anything that Google consumes is, at the end of the day, an HTML tag. It’s no different to the P tag, which you’ll use to display whatever. So it’s also up to you, the developer, to make sure that you create the OG tags that your content is there practically so the engines can crawl it. So it’s nothing… The headless provider will just give you an API, you can do whatever you want with it. To go back to the composable thing now, yeah, so a lot more people have started to move to it. You hear us talking about it, you hear some of our competitors talk about it, and that Defy is also doubling down with the acquisition of Gatsby, for example.Alvin: The idea is to go headless CMS plus, right? So with headless you say, “Oh, I have this one API that takes care of all my content.” But now, what if you could plug other things to this API? What if you could say, “Oh, I want…” I’m just making stuff up here, but what if I want to connect my slack to it? What if we have a weather app or something like that? Any other types of dynamic data that we need to combine with our content to have this one API that gives us everything. And it’s the idea of, again, you’re composing what you need with your headless CMS. And that for us, that looks like an ecosystem of apps, meaning you can extend Contentful with different apps, which could be translation, it’s 2023, so it could be GPT, could be anything else. So that’s the idea. Your headless CMS also integrates with other data providers.Drew: So it becomes like an aggregator of other content. So as well as having maybe a content editing team creating content, you might also be pulling stuff in from your Instagram feed.Alvin: Yeah, exactly.Drew: Or say, a dynamic feed from a third party provider and then making that all available under one API to all your different consumers. Okay, well that kind of makes sense. I think that makes sense.Alvin: Especially with Instagram, we’ve all seen the horrible Instagram embeds or the Twitter ones. Twitter API is a thing of the past now but anyway, just to give you an example of, you have these horrible embeds, and what if you could get that data from the headless CMS as well and then render it statically? That makes a lot more sense.Drew: Okay. So yes, it’s just an aggregation function on top of the standard as well as being the source of truth for your own content.Alvin: Exactly.Drew: Also then brings in other pieces of content. Now, I’ve personally always been interested in owning my own data where I can, and I’d usually pick a self-hosted solution for something rather than a service, given the choice. Although I have mellowed over the years. The trade-offs I make now are very different from what I would made in the past. But with a headless CMS being API driven, it seems like you’ve got a bit more flexibility there as to where it’s hosted. So you don’t necessarily need the CMS and the website to live on the same server or in the same environment. You could separate those out. So, is there added complexity there or is that an opportunity for simplification? Have you any thoughts?Alvin: Yeah, for sure. It depends, because everything is from that one API. Depending on your needs, that might get a lot of traffic, which will make self-hosting a problem. As you said, you’ve mellowed as some sort of into self-hosting because it’s become easier to just set up something in the cloud, whereas managing servers, has that necessarily got easier? Tech has changed, but it’s still annoying.Drew: It’s just got complicated in different directions.Alvin: Right. Yeah. So there are self-hosted headless CMSs. We’re not one of them because, again, we tend to target bigger clients that have, again, these needs for these APIs, and our CDN takes in, it’s in the billions of requests per month. So we’re pretty for high traffic stuff. But yeah, there are solutions you can install, Strappy is one of them that is self-hosted. You can install it on your own server, and this will give you, as you said, headless CMS. You’ll own your content, you’ll get the API. But the drawback with that is, obviously, if you get a ton of traffic, then it’ll go to your server that you might not scale or you might not want to pay for it to scale that yet. That’s the one true — but it’s possible for sure.Drew: And I guess you’ve got to manage it then if it’s on your end, you’ve got to keep it updated, keep it running, keep it backed up. I guess the decisions you’d make for a small community website would be different for the things you’d make if you were Ikea. IKEA probably isn’t going to be running Strappy on a VPS. That’s probably not a good solution for them in a lot of ways. So what are the things you should weigh up when picking a headless CMS solution? What are the things to be looking out for that are perhaps different from what we’re used to evaluating for a traditional CMS?Alvin: I think it depends… Well, as a developer, you’ll know what you’ll be coding so you can look at the API and what it looks like, whether you like it or not. How easy, does it support GraphQL? Everyone does these days, but stuff like that. Then I think it depends on the people who are going to spend a lot of time in the CMS team. As much as it’s great for me if I like the API, but if the people who are going to write in the CMS hate it, then it’s probably not the right choice. So I definitely think you probably want to involve these people to the decision, right? Because they’re going to be the ones spending time. For us, we want to make sure that we can retrieve everything we want from the API as developers, but definitely wants your blog editor to give you the green light and make sure it has everything they need.Drew: Yeah, you mentioned the API becomes really important, and I’ve seen headless CMSs with Rest APIs with GraphQL, and then various solutions have SDKs that you can import into your project that give you a language native way of interacting. Is there anything you would, from a development point of view, that would be useful to look out for when evaluating availability of SDKs or types of APIs?Alvin: Yeah, for sure, if it’s something you like. At the end of the day, the beauty of it, is it’s still an API call. So any language under the sun will support that, hopefully. Yeah, so it’s also up to you, right? Do you want Python native SDK where it’s just like, okay, I’m typing three lines of code and I do client, get entry, get this idea whatever, or get these entries that are of this content type, they prefer that grade. But if you’re the kind of person who’s like, “Nope, I’m going to have complete control,” it also goes back to what you said about owning your data. The problem with relying on this on an SDK is what happens when there’s a security problem, versus if it’s you and you’re just using the bare bones HTTP client on your language, that there’s less risk. So it also depends on the kind of project you’re working on.Drew: You talked about the user interface aspect, and it’s got to be one of the big factors, isn’t it? When you’ve got people entering content, creating content in a system and managing it, the user interface that’s provided is a big factor there and how the data is… There are all sorts of different approaches aren’t there? In content management to how you manage data, whether it’s just one big wizzywig block of junk, or whether things are broken down to a granular level for structured content. Presuming that most headless solutions still have some sort of user interface for editing content to get you started, does that reflect what you’ve seen in the marketplace?Alvin: Yeah, everyone has a wizzywig. Some have varying degrees of support with Markdown, and again, the ecosystem of apps that I was talking about. So more and more players are having their own, and this helps also to extend it so it can help with this discussion of, if you’re talking to a blog editor, it’s like, “Ah, it’s kind of there, but I really wish there was a field that could do X,” and you could either extend it yourself or just look for another solution. But yeah, different teams have varying needs. And it could be small things, like for example, scheduling. Like, oh, I want to be able to have this campaign going, I want to make sure that from now, I can make sure a blog post goes on the Monday, another one goes on a Tuesday and another one goes on the Thursday. And if the interface for this is a nightmare versus something else that you might not need. It depends, right? It’s always… But yeah, it’s crucial. Absolutely.Drew: And I guess, if you’ve got very specific needs, in theory, you could use a headless CMS purely as a content engine and have your own mechanisms for getting data in, and basically write your own interface for writing into that system as well. Is a right interface something that everyone supports? Or is that a feature to look out for when evaluating?Alvin: I wouldn’t say… I can’t remember if there’s one in particular who doesn’t, but I know we definitely do because-Drew: It’s a very broad question. With your extreme knowledge of a hundred percent of the marketplace, does every single one…Alvin: Right. Yeah, I know we support it because, it’s also, I think, with DEVREL, you end up spending a lot more time in your product versus the others, you tend to have a good… And this is where it’s different to sales, what we were saying earlier. When someone comes up to me and say, “Oh, what is the one feature that is different?” I always say, “Well, it depends what you need.” What is the one reason I could choose Contentful? And this is where we very much differ from sales, which we’ll have a list right there in the ready. And then we’ll be like, “Oh, for sure you should choose us because A, B, C, D.” And for us as developer, is more like, “What do you need? What scale do you have? What do you like working on? How big is your team?” It’s a different question. But as far as writing, having an API that works both ways, we definitely support it, and I would be surprised if others do not.Drew: It becomes quite crucial, doesn’t it? Because very few projects comparatively start with nothing. Most people have got some sort of system in place before, and taking the data that you’ve already got and migrating it into a new system can be a major project, and a deal breaker for a lot of bigger use cases. You’ve got to be able to get data in. So having a CMS that has an API that you can write code and interface with whatever the previous system is, get that code into a decent shape, and then inject it into the headless system, that’s a major advantage, isn’t it?Alvin: And you can think in terms of reproducibility as well, because migration is great, but it’s even better if you can say, “Oh, this is the exact script that I ran for migration as opposed to just this collection of random commands that I did on my machine.” And it’s like, oh, beta’s over now. It’s much better to say, “Oh, we have this very defined way of transforming this data from this shape to that shape.” And having an API helps you with this for sure.Drew: Hopefully gone are the days when you have two browser windows open and copy and paste content from one form to another. I’ve certainly been there in the distant past. But yeah, flew those days behind us. Is there anything that has particularly caught your attention?Alvin: I think the composable thing is, it’s been going on for a few months now, but it is definitely a shift. Everyone is starting to think, oh, maybe there’s more than just being the headless CMS solution. And obviously AI, which every market is talking about now. But it’s also content, and especially written content is, the first, right now, at least, the very first industries to be impacted by it. So how do you integrate it? How do you make sure… How do you account for things like attribution? These are discussions that are happening in the content space for sure, definitely. At least right now, it’s the first industry that it’s really attacking.Drew: Yes. Written content and things like images, there’s Photoshop, new version of Photoshop has come out this last couple of weeks that has completely generative fill in it, which is amazing. So it’s a brave new world, isn’t it? From a content point of view particular, it’s a brave new world. And you mentioned attribution, and that’s a minefield as well, isn’t it? Figuring out how all that works when content has been generated from a model trained on-Alvin: We don’t know what.Drew: Yeah, who knows what. So how can you attribute stuff? It’s going to be a very interesting time, going forward, figuring out how we do that. Is there anything else that, say I’m planning a project, I’m going to use a headless CMS. I’ve decided maybe I’m going to use Contentful, and I’m planning out this project. What should I be considering? What lies ahead of me? What should I be worrying about? What is there that I should be thinking about? On embarking on this?Alvin: I think it’s your content model. So it’s the first thing to get right. We see sometimes people really over-complicating things and having content model for, if you think of an index page, having a separate content for a carousel, and then there may be a river type content. Do you know what I mean? In terms of where you have an image on the left and text on the right, and then it follows by image on the right text on the left. So you can really over-complicate things where it’s content model. You could think, “Oh, rivers is very different to a Carousel,” for example. But then you can think, “Oh wait, no, is it just an image with text with it?” And then at the end of the day, oh yeah it is. So it’s stuff like that where it’s easy to over-engineer things, and then having content models that are Carousel homepage one, and then about page Carousel two, and it’s like, well, no, these aren’t the same thing.Alvin: So it’s trying to think in the abstract way, even if it might be more code originally because you’re building more flexibility into each of the content models, the content types as well. But in the long run, that could save you.Drew: So it’s about, I guess, thinking of what content you’ve got and what different types it falls into?Alvin: And what you might have in the future, which is complicated for sure because you can never know. But trying to build flexibility of, in terms of trying to think outside the box that, for example, what if there was a caption in this river? What if one of the images was actually a video? These little tweaks like this, which it will save you a lot of time in the long run, because it will prevent you from having to rethink everything later.Drew: From a development point of view, from a developer point of view, one thing that always gives me reassurance in my work is having a good test suite that you can run to make sure that things aren’t broken before you deploy.Alvin: Yeah.Drew: Is there anything in terms of testing around content that we could make use of?Alvin: For sure. It’s an API too. So if you can think of using something like Storybook, where you have your different components, you could say, right, so, as we said about, this is a generic component. What happens if there’s three instances of it? What happens if there’s five? What happens again, if one of them is a video? It’s this whole, the meme, cue engineer walks into a bar, orders zero beers, orders a thousand beers, stuff like that.Drew: What is an elephant?Alvin: Right. Yeah, exactly. And that type of thing. You can build into test suite and see what happens.Drew: Yes, that’s quite interesting. I guess, again, it’s the decoupling of things that makes that really easy. And I guess then, if you’re running that Storybook, you can then run it through some visual regression testing and spot breakages or what have you. Yeah, that’s really fascinating.Alvin: You can think of human errors too, right? Sometimes when you set up everything, you’re like, “Oh yeah, of course they’re going to put a date on the article,” but then sometimes you forget or sometimes there’s something else and you realize, oh, that the date you published is different than the date you had in the article, whatever. Or one of the author’s Twitter doesn’t work. Stuff like that is, it’s writing your test suite is a good time to think about these edge cases, right? Sorry, what was your question?Drew: Yes, no, I was just jabbering on. In fact, I remember years ago writing a sort of system for blogging, and every one of the absolute required fields was a title for the blog post. When I created it, I never even questioned, would a title be optional? A title is fundamental. Every blog post has a title.Alvin: H1.Drew: Right. And then you use that to generate the nice slug for the URL and all these sorts of things. And in listings, it’s the title that appears. And then Tumblr came out, and you could create all sorts of posts on that, and you didn’t even need a date or a title.Alvin: Oh yeah.Drew: What madness is this? But it’s like you’re saying, it’s thinking outside of the box and thinking about the different types of content that you might have. And it turns out that fundamental assumption that I made early on in that system, that we absolutely a hundred percent always had a title, became a limitation of what we could do with the system, because then when content came along that didn’t have a title, I was stuffed.Alvin: Yeah, Instagram is another example. Or as we said, the great thing about headless is that it can go anywhere, but if you’re also planning stuff that is written in Contentful, but that will go on your website, again, your catalog, but also on Instagram, we have this great promotion this week for half price of whatever. On Instagram, that might just be the image and nothing else, and the description or something else. Yeah. Or you want to make sure, definitely don’t pull the hashtag into the blog, stuff like that.Drew: Yes. Yeah, and I guess just thinking about Instagram and using content in that way, having this API with your content opens up all sorts of possibilities for generating images. You could pull the content and render text onto an image and post it to Instagram and do all that sort of things, that imagining doing that with a traditional CMS would just be… It’d be a flight of fancy, it’d be difficult. You’d be fighting against the system rather than working with it.Alvin: Yeah. And this is where other features, as I said, scheduling for example, can be very important, because you can say, I want to make sure that whenever this campaign launches, we also have the Instagram stuff going out, which are again, these images generated from the new publish in the CMS, and this is where the CMS itself can have a scheduler, you can use Zapier or you can use Zapier to capture it and run a script that will then generate the image. You can do all of this in a Chrome job somewhere. It depends, but this is where these features become important.Drew: Your content then just sits as one piece in a big chain of loosely joined elements that are delivering your various digital products or what have you onto your customers.Alvin: And the composable stuff is about this being less loose, is to make sure you have some kind of control that’s defined, right? That’s not like, oh, there’s this Chrome job here and this app here, and it’s all duct tape.Drew: Yes. So yeah, it gives you a level of control and potentially then, quality control or moderation or any of those steps that you might want to put in between rather than just… Because it would be possible to federate content in a front-end JavaScript app, you could do that, but then you’re missing that potential gate-keeping or any of those steps that you might want to put in, that having a platform that does it for you or enables that as a feature. Sounds super useful. So we’ve been learning all about headless CMSs today. What have you been learning about lately, Alvin?Alvin: I was on web rush last week, so I did a lot of work with Astro, the different web framework. It’s been out for a bit, but since 2.0, I feel like they’ve really stepped on the gas and started releasing so many things. So I’ve really been looking into it, and it’s great. I have a blog post coming out. But yeah, I’ve been looking at the docs and learning a lot about all the new features, references, which are amazing. If you’ve had to deal with Markdown before and the whole type safety that they’ve added to Markdown, it’s really interesting. And the fact that they support all the frameworks is just even better. So yeah, I’ve been learning a lot about Astro recently.Drew: That’s great. I think we did an episode on Astro, maybe a couple of years ago now, so perhaps it’s time that the Smashing Podcast Revisited.Alvin: Yeah, there’s a lot of new stuff that came outDrew: That’s amazing. If you, dear Listener, would like to hear more from Alvin, you can find his personal website with links to his various projects and social profiles at alvin.codes. Thanks for joining us today, Alvin. Do you have any parting words?Alvin: No, thank you for having me. I’ve been a reader of Smashing Mag for a long time. My first article, I think, came out last year, which was also a great honor. And yeah, thank you so much for having me.
(il)
