Transcript

CHRIS: Hey, everybody. Thanks for listening to ShopTalk Show. We have an awesome show for you. As you know, this "season" we are doing topical based shows. The topic this week, oh, drum roll or something, I feel like is necessary.

[Drum roll sound effect]

CHRIS: Headless CMSs. What is a headless CMS? You're going to find out if you listen to this show. It's a very interesting concept.

We have two sponsors for you. Braintree: Simple, secure payments, code that you can integrate in minutes. It's an API for taking money from people for your Web app kind of fundamental if you're building a Web app. The URL there is BraintreePayments.com/SHOPTALK. Please go to that URL to check it out. It's pretty cool. I don't think you're going to regret it.

Fluent Conf, which is coming up in San Francisco March 7th through 10th, two days of intensive training on things like React, Node, CSS layout, followed by two days of sessions and that type of thing. Use the coupon code SHOPTALKS, when you register to save 30% off of that conference coming up in lovely San Francisco. That's going to be a fun trip for all of you all that bite on this and go. I don't think you're going to regret that either.

For now, let's kick things off.

[Banjo music]

MANTRA: JUST BUILD WEBSITES!

DAVE: Well, welcome to another episode of ShopTalk Show. I should actually be using my Halloween soundboard because today is a spooky, scary episode about headless CMS - woooo.

CHRIS: If CMSs were people, it would be like Spooky Hallow indeed.

DAVE: I'm Dave Rupert with Mr. Chris Coyier. Chris, who do we got here today?

CHRIS: Hey! We have a pal on this. We have invited some people who have inspired me to think more about this subject and I'm sure have lots of say about this subject. Number one, we have Matt Dennewitz. Hey, Matt.

MATT: Hello.

CHRIS: Matt is VP of Product at Pitchfork.com, the most influential music site online.

DAVE: Uh, I'd give it a 5.4.

CHRIS: I don't know how to introduce Pitchfork. What do you say? What do you really do at Pitchfork? I'm sure that's what you really do, but you know what I mean. What do you really do?

MATT: My team just builds the website. We build backend. We build the CMS. Kind of build anything that needs to be built and then make sure it stays running.

CHRIS: Yeah, so code, servers, those things.

MATT: You got it. Yeah.

CHRIS: Nice. You've been there a long time, thus the VP thing, and you know the ins and outs of how the Pitchfork infrastructure works, including CMS stuff.

MATT: So true. So true.

CHRIS: Okay. Chicago, right?

MATT: Mm-hmm, correct. Yeah. I've been here about 14 years.

CHRIS: Yeah, so that's where Pitchfork is and where Matt Dennewitz is, those two things. Makes a lot of sense, really.

MATT: Here in the heart of Logan Square.

DAVE: If you were to draw a Venn diagram, they would be overlapping.

CHRIS: I don't even think it counts when the two circles are the same circle. It's like a Venn "no-diagram."

DAVE: Hmm.

MATT: Isn't every circle a Venn diagram, really?

CHRIS: Sure. Kind of. It's a half of one, anyway. I met Matt through an event called SNDMakes. SND is the Society for News Design, and our mutual friend and my girlfriend, Miranda Mulligan, runs it. It was pretty darn fun, I think. It's like this boutique hack-a-thon thing where, through this society or whatever, a bunch of cool, interesting, smart people come together and build stuff, and stuff. We did one of those in Austin, and then we did it again just recently in Chicago, and Matt was at both of them. It was pretty fun.

MATT: Yeah, so were you.

CHRIS: I was. I was totally there. We got to hang out for, like, an entire weekend at the Cards Against Humanity offices, and it was pretty cool.

MATT: (Indiscernible).

CHRIS: Yeah. I have lots of questions for Matt, and we're going to pepper him with stuff. Maybe we'll even talk about baseball for a minute. I don't know, though. Matt might get too passionate.

We also have Jeff Eaton. We've never talked to Jeff before. Hey, Jeff. How are you doing?

JEFF: I'm doing pretty good. It's great to be here.

CHRIS: Yeah. Jeff, you are -- quoting from your page on Lullabot.com where you work -- content strategy, Drupal architecture, multichannel publishing, content modeling. Is it safe to say you care about CMSs a little?

JEFF: I care to an almost unhealthy degree about CMSs, structured content, content reuse and, yeah, all that stuff. I love it.

CHRIS: Okay. Cool. You are at Lullabot and stuff. Do you want to tell us about that, maybe a recent project or something?

JEFF: Yeah. I've been working with Lullabot. We're primarily a Drupal architecture and development shop. We've been at it for about a decade. Actually, this January is our tenth anniversary, and I've been with Lullabot for a little over nine years, so I've been there for quite a while now.

We do projects like the Grammy's website, MSNBC.com, a lot of NBC properties, Martha Stewart Living, the World Wrestling Entertainment Company, and we also work with a lot of small to midsize clients like educational institutions and stuff like that who aren't necessarily doing giant media enterprises, but a lot of our, like, tent pole projects, the ones that we sink a lot of time and energy into, are those media and content publishing businesses where it's a big part of what they do. It's not just an adjunct or part of their marketing or whatever. But, putting that stuff out is their business.

CHRIS: Yeah. Interesting. Okay. Cool, cool. Clearly a big -- we hear -- sometimes we even get questions about little agencies who are like, "Should I specialize in a particular CMS or something?" It's like here's kind of proof that doing that isn't the worst idea in the world with a massive client base you have and still being kind of a Drupal focused shop.

Just as a minor aside here, if some big contract came along that they wanted Lullabot to do, and they specifically didn't want Drupal, would you do it anyway, or are you that focused on Drupal that it wouldn't be--?

JEFF: No. We actually do other stuff, like we've got people who are ramping up on Swift, and we've done React Node projects and stuff like that. I've done a bunch of Django stuff on the side just because I nerd out a lot. But, it's such a big part of the rhythm of the clients that we work with and stuff like that, that that's the majority of the stuff that we do. We enjoy doing other things, but usually it's as an adjunct to Drupal, large-scale Drupal projects, just mostly because of inertia and the kinds of clients that come in the door.

CHRIS: Awesome. I don't think we've met, but this started, this concept in my head started as Dave and I -- there was even an episode of this. We were at an Event Apart. Were we in Chicago, Dave?

DAVE: Chicago.

CHRIS: Yeah, I believe we were.

DAVE: State Street, it's a great street.

CHRIS: I don't even know what's going on there. We were invited to that one to do a live ShopTalk Show, so that's why you couldn't hear it here. At that particular one, for whatever reason, this concept of headless CMS kept coming up over and over again. And so, I would like to define it before we get too much further along, or at least what we all think of when we think of it. Karen McGrane was there, who is another big content person. I also asked her to be on the show, but she is busy romping around New Zealand and said that the person that you have to absolutely talk to is Jeff Eaton, so that's why Jeff is here, not that I wasn't aware of you already, Jeff. But, it was a--

JEFF: It's okay.

CHRIS: It's an amazing--

JEFF: I'm flattered.

CHRIS: It was an amazing endorsement by Karen. While we are at it, this is what I think of it. I'm going to do a short one, and then I'm going to pass it off to you two because I kind of want to know what you think about when you think of headless CMS. I just think of some kind of maybe even a UI for a backend, but the UI just absolutely doesn't care about templating or what the front end of the site is going to look like.

It is only concerned with accepting data being input and then its output is literally just APIs only, like json API, whatever. Hit this URL. I'll return you data that I'm storing within myself.

Head refers, in my mind, to just templates only. A headless CMS would be a CMS that just doesn't have templates. What do you think, Matt? Is that anywhere near right? How do you think of this term?

MATT: Yeah, I think you nailed it. The way I think of it is just kind of decoupling data delivery from any backend or front end. The backend just kind of becomes a permission to front end. Traditionally, the backend is thought of as the CMS, I guess at least where I come from. The advantage that gives you is you can put a lot of effort now into the data delivery and kind of marshalling who has access to that and refining it, and then you really don't need to care about who reads it, how it's read, or how it's fed back into, which lets you kind of decompose all of those concerns and spread them out to different teams who could maybe excel at the individual concern level rather than all together.

CHRIS: Okay. That's already a benefit of it is, organizationally, you could split this thing at the concern level, so you could have teams that do different parts of this and not smash them together anymore.

MATT: Yeah.

CHRIS: That's a good thing. Let's hold off on that for a minute because that's a benefit of it. Let's define it first and then do the benefits thing. Jeff, what do you think about when you think about headless CMSs?

JEFF: I think you definitely nailed it. I tend to think of headless CMSs as sort of existing on a continuum of decoupling. Headless feels like a very extreme version of a greater trend towards separating concerns, I think, even if you're doing a tightly coupled CMS. Like Drupal traditionally is a single stack that handles the backend, the front-end, the mid end, all the ends. But, you can still do things that move you towards a more decoupled system if you're, say, very scrupulous about making sure that the structure of your content doesn't bake in all kinds of design decisions in the underlying structure and that that's handled by your theme.

Going full on headless is sort of a way to absolutely, positively enforce that at the architectural level. You have to do that if you're building a headless CMS because you've got a separate system taking in data and spitting out HTML or transforming it into data for an iOS app or something like that. It sort of forces a degree of adherence to that separation that is easy to fudge if you're using a system that is fully baked from the backend to the front end.

CHRIS: That's fascinating. If we're thinking of CMSs on a spectrum of how decoupled they are from data to what it spits out, like backend and front end, different CMSs are at different points on that spectrum. Headless CMS is all the way on the totally decoupled part, and there are probably some that are all the way on the totally not separated kind of thing.

I think of WordPress before there was a json API and stuff as there is now, there's no way you can get at that data except for by creating a theme, templates, and crap, and using WordPress PHP functions to get at that data in there. That's completely coupled. Right?

JEFF: Yeah, and even to the point where, in WordPress, like a lot of business logic and a lot of the stuff that you might think of as being the guts of what makes your site. Your site, conceptually, lives in the theme because that's where a lot of the action is.

CHRIS: Mm-hmm. We could talk about advantages. But, before that, I think this probably, to some people out there, feels a little weird. Like, okay, let's say I go for it. I'm now completely decoupled.

What does that mean? I don't know. I guess short of why would I do that; what do I do with just an API of data then? Aren't you kind of like, uh, totally on your own then for what you do on the front end? Matt?

MATT: Yeah. In some ways it does mean you're kind of on your own, that kind of decoupling.

CHRIS: How am I going to deal with the URLs now? That was handled for me before. Yeah.

DAVE: Yeah, I think that's my question. I deleted my themes folder. [Explosion sound] Gone, in the trash, right? Now it spits out json. Now what do I do? Now I have to build something else, I guess, to consume that json. Is that how? I guess maybe walk us through my very first headless CMS.

CHRIS: There you go.

JEFF: That would be the best Fisher-Price product ever.

DAVE: Fisher-Price, yeah. My first headless CMS.

MATT: Yeah. I think, from our perspective, the way you'd approach this as in you now have kind of like a monolithic data store. And so, whereas before you had an app like WordPress or the Django admin that would let you kind of like see your data and would handle all the data fetching for you, but also rendering an interface to manage it, as well as giving you the option to have views on the front end that access it, you're kind of blowing up everything, so now you're responsible for the consumption apps, so your front end, which would read the API and display it. You're also responsible now for a new CMS in the backend that's going to read those APIs and have to interact with authentication. It's not that much different than how you would build a mobile app, which is also going to have to just read an API and kind of deal with that signaling as well.

CHRIS: Yeah. Therein lies the rub, in a sense, isn't it? It's kind of like -- I don't know -- if I'm totally not decoupled, that means how am I going to build a mobile app? There better be some kind of API to this data because maybe I'm choosing not to go responsive and building a native app, but it still needs access to the same kind of data. I certainly wouldn't want to have two different CMSs that I'm trying to keep in synch. Like all of a sudden now that I'm decoupled, isn't it like hands in the air, awesome because I can use the same API for both…?

MATT: Yeah.

JEFF: Unicorns all the way down.

MATT: Yeah. You're reducing everything down to a basic data stream, and you're giving yourself the responsibility to build everything around that data stream now. Whereas before, you were given kind of like a batteries included platform.

CHRIS: Yeah. I think that's the thing. This isn't theoretical. Even though it feels a little theoretical, it's not really theoretical, right? I imagine a site like Pitchfork has a website, but it has a mobile app too. It also has who knows what all properties.

It's kind of like those are the easy ones to imagine. But, as most of us have jobs and we're aware of the complexities that come along with stuff that it's never just as simple as: I've just got to make the website better. It's like, no, this company needs this, and this company needs this, and whatever.

MATT: It's true.

CHRIS: Yeah?

MATT: Yeah. It's like having your entire site depend on an RSS feed. You know?

CHRIS: Yeah.

JEFF: That's not chilling at all.

DAVE: That sounded both neat and terrifying.

MATT: Yeah.

JEFF: It's interesting that you mentioned all the different properties that you could drive with something like that because at least, like on the projects that we worked on, that's one of the common threads we find. That the earliest groups that have been pushing towards this whole headless direction, and I would probably describe it as first working with decoupling more and more of their systems, making sure that the design isn't tightly coupled into the content, structures, and stuff like that, and moving towards a headless approach and more of an API driven approach. They're the ones that have had to roll out mobile apps or deal with third-party partners that want to consume rich versions of their client, of their content for republishing, stuff like that.

They've been having to deal with the complexities of the "you're responsible for everything" stuff that you were talking about on different endpoints in their sort of suite of properties and suite of things that they're putting out. The idea of having to take on more responsibility for the front-end stuff, in particular, isn't new for them. They've been having to do that for these different things in a piecemeal fashion. And, in that kind of scenario, going headless and saying, okay, the website becomes just another one of these things that is an endpoint consumer of our underlying content store, that's a shift that, for many of those types of properties, can actually simply things because you don't have the website as this one monolithic thing and then everything else has an adjunct. It becomes everything works with this standard, centralized system.

MATT: Yeah. It's a design pattern that probably needs to be analyzed before jumping into, you know, if you just need a standard blog, you probably don't need something like that. But, if you're in the syndication game, if you've got a lot of partners who need to read your content, if you've got a reason to spread across multiple devices, multiple platforms even, or even have a heavy data exchange, then this is starting to look like a really attractive option.

DAVE: Maybe we could do some cost benefit analysis. Is that okay? I imagine--

CHRIS: Napkin math?

DAVE: Napkin math. I'm thinking of it in, let's say, yeah, I'm trying to go to the iPhone app, the Android app, the Apple watch, and the website. It sounds really great to have the central store to get to all those places. Then it also seems smart to decouple, let's call it, the theme, but the front end website from the backend so that you're not overweighing the backend. We've probably all experienced where you had a bad plugin in WordPress that crashed your WordPress.

CHRIS: (Indiscernible).

DAVE: It was just purely front end. It was only when we logged in, but it was okay. But, you've probably all, like we've all experienced that one random line of code takes down the whole system, so you kind of build up a defense, right? That's kind of like maybe a positive of this headless CMS thing is your front-end mess-ups don't affect your backup mess-ups. Is that something you find?

JEFF: Jeff here. I would say that's definitely one of the perceived benefits. Sometimes it's also an actual benefit. The thing is, whether or not the backend exploding in flames and you going and fixing it causes hiccups on the front end, it also depends on the architecture and how you set up a headless site. It really does depend.

I like to think that the oldest, fully headless, 100% decoupled CMSs were tools like movable type and Blogger way back in the day when Blogger was something that you logged into, and then it made HTML files and would FTP them to your server for you. I also think I just dated myself.

DAVE: This is a rudimentary Jekyll.

JEFF: Yeah, in the sense that it was a tool that you used to manage your content and it spit out flat files that could live completely independently of the CMS. You could literally uninstall moveable type and your blog would still be there. You wouldn't be able to edit it, but it was all there, fully rendered, and ready to go. One of the major benefits of that in those days was, like, super scaleable, like as fast as you could make your Web server spit out static files was the maximum delivery speed of your content, and you didn't have to worry about things like, oh, God, we added a new plugin and suddenly the site speed tanked, and we've got to go track that down. Some of those things that I think became part and parcel of the troubleshooting landscape of modern, big CMSs didn't even exist back then because everybody was spitting out flat files.

As things got faster and it became more practical to have a full stack CMS that rendered everything on the fly, we learned that we could do all these crazy things. We could do personalization. We could do all kinds of cool dynamic stuff, but then we also ended up sort of sacrificing some of that ease of scaling.

I don't know. Some of the clients that we've worked with that have been most excited about it, that complete decoupling of we could even switch out to a different backend system and, as long as it exposed the same interface for the front end to pull from, we could just keep on….

CHRIS: Or, digested the backend data the same way. In the case of Jekyll, it's these Markdown files with some YAML at the top of them, so as long as that's stored the same.

JEFF: Yeah.

CHRIS: I don't know. You'd think these days a safer way of some kind of more, like a database on the backend that doesn't necessarily need to be in production, but exists somewhere.

JEFF: And especially with a CMS and backend editorial stuff. I think I'll shut up and let Matt weigh in on this, but I think the editorial experience and the editorial workflow ends up becoming more and more of an important part of any CMS that an organization uses internally. Being able to iterate that over time and keep these improvements and just keep sort of improving it on an ongoing basis while being able to much more rapidly iterate the front end. Being able to iterate those two pieces at different paces, I think, is a real benefit for some groups.

MATT: I think that's a great idea. It's a great thought. And, I think, just to kind of support that idea, when you separate those two and you kind of make the CMS a little more important in terms of the UI, one thing you find is that you can always do a little bit better in the CMS. The CMS deserves more love because, more often than not, it just becomes editorially and even, like on the development side, just a means to an end. Right? The CMS is always what's good enough. It's never something that you want to go back and really blow out.

We made a couple passes here at Pitchfork in making a better CMS, and it's been eye-opening in terms of how people respond when you make their crud operations much more beautiful and natural to go through. I think that….

CHRIS: In a good way or a bad way?

MATT: In a really good way, actually.

CHRIS: Interesting.

MATT: You give someone a more beautiful CMS and something that works a little more naturally in terms of how they think about composing a piece, and we've seen that with, like, Medium, and we've seen that with other, like Contently, things like that, where people are really thinking about the editorial experience of writing inside the browser, but also composing with multimedia and putting together different objects that maybe have, on the front end, a different representation. But, on the backend, need just to kind of be previewed up front or to be built collaboratively and things like that.

The point being, when you separate the concerns like this and you start to think about the CMS as just another user interface, you can actually kind of push the art of the CMS forward a little bit rather than being, you know, coming from our area like the Django admin being mostly generated where it's good enough. It's great. We can build custom interfaces for it, but really putting some TLC into the CMS goes a long way for just the editorial side. Few people actually get the advantage.

CHRIS: I guess that plays into the decoupling a little bit. If you can have a team at a company that's job is to build this, the content creation experience, that's pretty cool. You own that, this team. Work with the writers and make what you want them to be great. Then have a different team be like, okay, we're going to just suck down data and make the awesomest reading experience we possibly can. Of course, you all have to talk to each other, but I like that idea of being able to split that up a little more cleanly.

MATT: But I also think that for teams, like on our side, we share that responsibility. We don't have a CMS team and a front-end team, for teams of generalists like that. It also just kind of compels you to think a little bit more. It also kind of drives down something maybe you'd talk about later is it starts to make you think about what you're actually storing in the data because now you have several systems pulling it. More than kind of like, "Oh, my God. We need to clean up this crazy HTML for the iPhone." Now it's, "Oh, my God. We need to clean up everything in our database because we've exposed this to everything else on the planet now and HTML is no longer good enough."

JEFF: Suddenly pasting that Google ad code into the comments field feels like a terrible idea.

CHRIS: Yeah.

MATT: Exactly.

CHRIS: Oh, yeah. See, you can clearly--

JEFF: That's not at all a made up example.

CHRIS: You can make a bad headless CMS is the point, right? Just because you've made a headless CMS doesn't mean you've done a good job. For example, if you made a headless CMS and the fields you had available were Title and Content and, inside that Content was a bunch of HTML with classes on everything and whatever--

JEFF: No, you just wrap it with body and call it--

CHRIS: Yeah. You haven't done a very good job of thinking about the data that you need. Hopefully, mostly, if you're going with CMS, headless CMS, you kind of know that and aren't doing that bad of a job.

MATT: But it also kind of compels the user to think a little more critically about what they're actually storing across all levels, not all experiences, but just kind of a nice external website.

JEFF: This is actually something -- so there's a client that I'm working with right now that's in the process of converting, I think, something like maybe six or seven major brands of theirs over to a shared, fully decoupled, headless API driven system from a full stack, everybody builds there own, monolithic CMS with a front end approach. And, it's complicated because they're actually going through and trying to look at, like, okay, what is everybody doing with their CMS? What kinds of things are you doing with that heavily coupled CMS?

To what Matt said, really thinking through what it is you're doing, what it is you're storing, forcing the entire organization to become a lot more thoughtful about what the structure of your content is and what the meaning of what you're storing is so that it can be repurposed in lots of different ways. That's a big shift, and I think it's especially tricky when you've got a lot of editorial design variation when you may have a standard, predictable, easily templated format for 80% of your content, but maybe 20% of it really needs to be able to break outside of that mold and be highly tailored in some way. How you handle those kinds of things, that takes planning and thought to not just turn it into another heavily baked in thing that you'll need to completely redesign, rebuild once the next redesign rolls around.

CHRIS: Wonderful. Let me tell you--cue the cool ad roll music--if you're interested in learning about Web stuff, check out O'Reilly's Fluent Conf. It's coming up in San Francisco this March. The 7th and 8th is the training portion of it with just hardcore learning sessions like all day things where you go and learn the crap out of a certain subject. Then the 8th through 10th are the sessions that you go to and get a sprinkling of the rest of the world.

Web, Web, Web is what they say: programming, design, making the Web great. The sessions explore everything from foundation design decisions, to the details of JavaScript workflows, the latest JavaScript frameworks, conversations like React versus Angular 2. That's the kind of thing that's going to be talked about. Those will be the hallway conversations at Fluent Conf. for sure: hardware, chat, testing, performance, the cultures that make these projects succeed or fail.

There is a discount code if you want to go out to San Francisco, which I'm sure will be absolutely lovely that time of year. You're going to have a great time. Use the coupon code SHOPTALKS when you sign up for O'Reilly's Fluent Conf. Follow the link in the notes.

All right, let's say, Matt, that you were going to theoretically make a new website. You're going to work on Matt's Cool Baseball website, which is a major publication, and you're going to make a headless CMS. You're kind of a Python guy or a Django guy, a little bit, right? At least you like that…?

MATT: Primarily, yeah.

CHRIS: You're going to build a CMS. Walk us through that, and then walk us through what you might do on the front end because you are a little into React these days too, right? Some kind of Django React hybrid might be kind of rad.

MATT: Yeah. Do you want to talk specifically about that stack or just kind of broadly?

CHRIS: I don't know. I don't mind broadly, but I think this show--

MATT: Yeah, let's go broadly.

CHRIS: Okay. The audience can handle tech, though. Don't worry. Yeah.

MATT: Oh, yeah.

CHRIS: Okay.

MATT: Not afraid. Cool. If I was starting a new project, I would start off by, like most cases, figuring out my data model, and I would start with the data model not only because that's going to inform first getting some sample data in, so I can set up maybe the Django admin if that's going to be going with or WordPress. But also because I know that my goal is to serve this over the API, so I want to kind of nail down upfront what the backbone of the application is going to be data-wise.

After that, I would probably flesh out a little bit of just like a coupled together scenario to make sure that I'm on the right path. Maybe get a couple of CRUD (indiscernible, 00:31:03) going on, and that's when I'd start to think where can I intelligently decouple some of these concerns. That's when I'd probably be grabbing Django REST framework or whatever equivalent in the language I'm using. That's when I'm thinking about, on the front end, what do I need to do for data fetching. I'm kind of looking at the options of do I want to do a totally, like, single page application style app or do I want to decouple it.

If I arrive at the answer yes, then I'm looking at: Do I want to serialize this over the wire? Do I want my CMS to be coupled to the data models, as in do I want to run the API out of the same code base as I do for the CMS for now? Or, do I want to totally have a standalone service that just talks to the database and then handles authentication on its own so I can read and write with different users and also marshals into if I wan json or if someone wants Yaml or if I need a syndication partner that only takes XML - things like that.

Then I'm starting to look at first decoupling from the CMS, if that's a decision I go down. I have now a standalone data service. I can build up the CRUD service in the back that maybe only I have access to. Maybe users don't log in there. Users probably don't even need to know about it.

That also gives me the opportunity to hook up. Lets say I don't want to have authentication baked into my API. I can use a service like op0 or something like that. They can store all the user information. Maybe I don't need a user database on my own here.

From there, I can start to worry about payments or anything else, all those other nice features, the ETL side if I need to do any data loading, but now I've got spread out kind of like a strong pull in the middle that I can tether all of my different interfaces to. I've got a stable data model. I've got whatever CMS that I would choose to use, and I've got a way for the front end to access it. I consider the front end to be just one of many, including the CMS would be the front end too. I think that's probably how I would start off at a high level. Does that make sense?

CHRIS: Yeah, totally. I don't fully have my head wrapped around how I might digest a fully json API into a fully functioning, click-aroundable website that looks like any other website, if not better somehow, faster somehow. I couldn't do it. I could learn how to do it, but it seems like, okay, so all I have is this json API. You expect me to really super quickly render an entire website out of that. I wouldn't quite know where to start. I could figure it out, but you know what I mean. It's like I don't totally get it. You use a front-end router, right?

MATT: Mm-hmm, yeah. Let's say you took a React app like Fluxible. Fluxible comes out of Yahoo. It's a great implementation of Flux. It's very straightforward. They give you all the services you need so that you dispatch actions. Actions can load data remotely, those like action responders, we'll call them. I know that's not like a Flux term, but you receive data, let's say, from a summary you've loaded.

You put that into a store. Your store then triggers signals and your UI updates. You could use something like Fluxible to, first off, render your React components on the front end, which your backend doesn't need to know anything about those React components. But, again you could share them if you wanted to.

You click a button to say load 100 blog posts or something like that. You would then dispatch an action. You would read from the json API. The json API would then send you all of your blog posts or whatever filtered posts that you would like because you can customize your API then to send back the filtered results. Then you store those client sided render appropriately.

CHRIS: I want to try it. I need a practice json file.

JEFF: You get hooked real fast.

CHRIS: Maybe affirming some things that I already thought, like if you did this kind of thing maybe my content gets to kind of like live forever. I've done so right by my content that this content can go forth and serve things that we don't even know about yet, like maybe there's some cool thing that's going to need my content. Well, fine. Hopefully it can eat APIs because that's what I'm serving. Surely it can.

Also, json, that's not the cool format anymore. It's jsonB or something weird. No problem. I'll just adjust some middle layer to start spitting that out too because the data is just there. Just like a template or a front end template might suck down data and turn it into a certain format, that's all an API is doing too. It's just sucking in some data and putting it in a certain format that's useful to somebody else. I get this kind of content that might just live forever.

JEFF: I really like the idea of just designing arbitrary data types now just to make sure that your API can spit it out. Just, you know, Yaml? Yeah, that's old hat. We've got Spaml.

CHRIS: Yeah, just inventing some new data formats. Sure.

JEFF: The funny thing is like Flikr, for a long time, had the 97 different formats or whatever that you could accept all their data feeds in. One of them, I think, was LOLCODE, like the parsible language of lolcats. You could get an RSS feed and it was a documented data format that was hilarious, but utterly useless.

CHRIS: I would think Eaton would be a cool format because then your marketing could be like: What's your app Eaton? You know?

DAVE: Oh! Oh!

MATT: Mmm.

JEFF: One of the things I think is interesting, though, is the idea that Matt has mentioned a couple of times of, like, solidifying on a predictable and at least relatively stable data structure or, in a lot of the sites we work with where there's a lot less "data" than there is content. We don't deal with transactional stuff. Usually it's individual entities of content that are related to each other and have fairly heavy amounts of stuff coming with them, whether it's media, text, or whatever.

Making sure that those structures are predictable and that you pretty much know what the underlying model of the stuff you're creating and maintaining and sticking out there is, regardless of what format it's going out in. That's a really huge stake in the ground. That makes it easier to iterate on your backend because you can think about ways of making, manipulating, and editing those kinds of things smoother as a purely backend UX concern. Then you can think of, oh, what are interesting and cool things that we could do on the front end with these sort of content resources that we have at our disposal without necessarily having to concern the edits and the content creators on the backend with every single thing that's going on in the front end. It can really bear a lot of really cool, cool fruit.

MATT: Totally.

CHRIS: Ah, fruit. Delicious.

MATT: Somebody has got to play devil's advocate here because--

CHRIS: It's going to happen in one second. I'm going to let Dave loose on it just for a moment.

DAVE: (Indiscernible)

CHRIS: Ugh!

DAVE: Yeah, brother. I'm getting amped up.

CHRIS: Cool beat-boxing sounds or whatever. The URL we're sending you to this time is BraintreePayments.com/SHOPTALK. Developers around the world have embraced the Braintree v.0. SDK is the easiest way to add secure mobile payments to their apps and websites. It supports Android, iOS, JavaScript clients, SDKs in .net, NodeJS, Java, Pearl, PHP, Python, Ruby. I don't even know if there are any more languages than that. That's all of them. Just kidding, but it's pretty close to covering the entire Web, I would say.

They provide you example code, like I want to use Braintree because I want to take PayPal, bitcoin, Venmo, Apple Pay, Android Pay, or credit cards, whatever. I want to use one API to do it because I don't want to go frickin' insane taking money. You can use Braintree to do that and just look at their reference implementations, use their sandbox. Figure it out. Get going. You can even call them on the phone, and they'll hand walk you through the thing. That's pretty cool, pretty good customer service. The URL again is BraintreePayments.com/SHOPTALK.

All right, Dave. While we were at this AEA Chicago where we were talking about this, I got the sensation, as you were sitting right next to me, that it wasn't your favorite idea ever in that it may occasionally maybe, maybe just maybe, cause more problems than its worth. Did I characterize you okay there?

DAVE: Decent characterization. I appreciate it. Thank you, Chris.

Let me say I'm a fan. I think it's in the modern era where you have to syndicate to a phone and a watch and a car and a speaker in your living room, lightbulb, or whatever. I think an API makes sense. I think that's a very important architectural decision.

My question is, let's say I run a publication and I heard this podcast. I'm like, oh, ShopTalk said do headless CMS. We're doing a headless CMS now.

I think my question is, although it solves a technical problem, does it create people problems along the way in the sense that, if I'm a designer and I design something, and then the front end developer is like, "Oh, we don't have a data point to actually design that to make that design happen," okay, well, then the designer is like, "Could you ask somebody about the data point?"

Then the front-end guy goes to the API guy and says, "Hey, can we get this data point in the data thing?" The API guy is like, "Oh, yeah. It's true. Totally, but I've got to go talk to the database guy who runs all the databases."

Okay, let me go to the database guy and he's doing this. He said, "Yeah, he can add that field in the database." He comes back and says, "Cool, but now we've got to talk to the CMS authoring tool, and we've got to do that." Then the API guy talks to the front-end guy.

I'm just wondering if we're creating nodes of communication.

CHRIS: Silos, you might call them.

JEFF: To be fair, you have just described the current project I'm on.

MATT: These definitely sound like problems that would exist even if you didn't kind of like separate your problems out.

DAVE: Yeah. If it was a monolith, I could maybe just go commando and make it happen and, like, pray to my gods, the commit lands, right? But it seems like oftentimes we're very naïve in saying, "Oh, this is technically the best, so it's the best," and we kind of forget the organizational overhead of, like, "Well, I just created 16 meetings to add a field to the database just per some design concept."

I'm curious what your experience is, mostly. Jeff, I think you said you're kind of going through this right now, but are we creating more people problems just to solve a technical hurdle?

JEFF: In theory. I think sort of, as Matt alluded to, these are not the kinds of problems that don't exist in a fully coupled system, in a traditional CMS that does front end and backend. It's just that oftentimes the fact that it's a single code base, it's a single language that both the templating and the backend code and stuff like that are both handled in. Oftentimes you'll have more cross-functional developers who would be able to, say, go in and dip into any one of those things to do a small tweak like that on a team where the skill sets are more divergent, like say you've got a PHP based backend and a React based front end, and it's literally two different pools of developers and two different skills, and maybe two different divisions of the company that handle those things. Yeah, you've sort of got a bucket brigade of decisions and requests that need to get relayed through that.

But again, I think that, to some degree, that's an organizational thing, not something that's inherent in the technology. But, it absolutely does need to be kept in mind that it's a lot easier to sort of fudge those things late in the game if you're using a monolithic stack, whereas in a completely decoupled system you're making sort of a contract. And, if you come up with a design that needs something more to go on, you've got to figure out where that data is coming from.

One of the ways that we've tried to solve that is baking things like editorial intent into some of the metadata in ways that aren't necessarily tied to particular design outputs, but give designers a lot of freedom how to interpret a particular thing on a front end, like giving editors the ability to, say, set relative priority on things. Not necessarily what order they're in, but regardless of where it appears, when this story comes up on the front page, it should really be accentuated compared to all the other stories. Do what you will on the front end, but I want to capture this.

CHRIS: I like the opposite of that. This is just garbage. This story, bury this thing.

JEFF: Yeah, it's like we are contractually required to put this on the front page. But, for the love of God, if you can just stick it….

CHRIS: Yeah.

JEFF: But, yeah. Things like that, capturing those sort of editorial intentions that are going to be part of the ongoing workflow that you find yourself communicating with design, but the editor is the one making those decisions, like should this be accentuated, should this be sort of toned down a bit compared to the other content?

CHRIS: Interesting.

JEFF: Do I want to present this in a particular way? What aspect of this story should be up front?

CHRIS: This could be a whole other show. It's like how do you design those fields.

JEFF: But, thinking through those things beforehand as a part of the data and content modeling process and part of the editorial workflow process can really save you a lot of time upfront because, if you're just thinking purely of what data do we present, like what would go into the RSS feed, it's very easy to then suddenly get to the design stage and say, "Oh, God. But now we need these three pieces of metadata to determine what goes in the upper right slot versus what goes in the center."

CHRIS: Sure.

JEFF: But if you've captured some of those emphasis and prioritization decisions in metadata that the editors can control, you can make lots of design decisions without suddenly having to run around in circles … extra fields….

CHRIS: Right. I'm sure there's a limit too because you don't want a publishing article to be a 15-page wizard either, right?

JEFF: Oh, yeah. True.

MATT: Yeah.

JEFF: It looks like you're writing a review.

MATT: One other thing to kind of thing, and this is mostly for the dev side, is that when you split these apart, you're not going to be able to share, as easily, components between the front end and the backend, that, even thinking about we need a button that does this. Okay, now we need an API endpoint. It's now in the CMS. We need to reflect this, but our CMS is running a different stack than the front end is. If we're using React on the front end, but we're still on jQuery, Backbone, whatever on the backend, now we've got a problem. We can't share the styles. We can't share the code. Now we can't allow people to preview. How do we get people from CMS to the front end to be able to preview?

Along with kind of like the editorial intake and planning that absolutely needs to happen with … (indiscernible, 00:47:00) to kind of map out ahead of time to make sure you don't lose time in an existing system as you're porting that over, just totally rebuilding your backend when you've only committed to rebuilding the front end.

CHRIS: I also imagine it being like, "I just want a preview of what this is going to look like on the Web." "Well, too bad. You can't have it. It's decoupled now."

MATT: Yeah.

JEFF: (Indiscernible)

MATT: Yeah. Now you have to invent the universe from scratch.

JEFF: I think it's important to note that these things aren't unsolved problems. They're not unsolvable problems. Putting together a preview system for a decoupled CMS, yeah, that is absolutely, utterly doable. But, it's the kinds of stuff that have been treated as table stakes features for a lot of highly coupled CMSs for quite a few years that, "Oh, well of course that's baked in." It's not unsolvable, but you've got to step back and think, "Okay, what things have I been taking for granted and what ones do I really need, do we really need to build into our new system, and what things can we just leave behind?"

CHRIS: Pretty interesting. Other than pitfalls, which we covered a little bit, for those of you that have worked with this a little bit, is there anything where you've been working with it and you've been like, "You know what? That's not great. But, overall worth it, but meh." Just something that kind of sucks about working with a headless CMS, is there anything that comes to mind?

MATT: I'll say, again, I don't think this is inherent in working with a headless CMS, but it's one of those things that is easily overlooked. I think that the Drupal community in particular, which is where I spend a lot of my time, is sort of starting to sober up about this aspect of it because Drupal 8 just shipped with the ability to roll out Restful endpoints with a couple of clicks. That's one of the features of Drupal Core now.

Yeah, hurray! Unicorns, rainbows, everything is magical and bright.

DAVE: What could go wrong?

MATT: What could possibly go wrong? But, one of the things that I think a lot of people are suddenly realizing is that all of the approaches and best practices to optimizing and squeezing the most performance out of a monolithic CMS on the server side, it may be tricky, but a lot of people have gotten used to how you do that. There are caching layers, and whatever language specific, Opcode caching systems you've got, there are all kinds of stuff that goes into that. But, if what you're doing now is just serving up json when people hit endpoints, it's very, very easy, for example, to create a page that is now, instead of making one request and chugging on it for 2 seconds, is now making 30, 40 requests for different little bits of json data to populate each sidebar, to populate the main content, to populate related articles.

Suddenly, you have to start thinking not just about do I have json endpoints for all of these individual pieces of data, but now how do I start optimizing this so that I'm not making 30, 40 requests just to get listings of related articles because that can impose just as much of a performance penalty. It's very easy to sort of approach it in a quick to develop, but difficult to scale, fashion. That's where you start coming up with different intermediary layers to bundle all those things together so that you've got maybe a lightweight node as the intermediary layer that collects all of the 19 different packets of information that are needed for a particular type of page - stuff like that.

I'm glossing over all kinds of details, but that's one of the things that I think really complex, highly dynamic sites have lots of cross-relational stuff. It's easy to overlook that and sort of say, "Yah! It's just json feeds now," and you've got to plan for that, too, once you get into the performance scale….

DAVE: Do frameworks like React or even Backbone or these kind frameworks, do they help you manage cache at all in these sort of situations, or is it kind of build your own cache so you don't, like you said, hammer your server into the ground?

JEFF: They give you enough tools. This is kind of like toolkit dependent to store the data so that if you want to go back to a page you've already loaded, you don't necessarily have to reload it.

I think what I found on our side, we actually ended up engineering such that any way when you go back to the page, you're going to reload it. It's not that much different than how a very coupled app would be where, if you changed the page, you're doing a data refresh. I guess one of the main points I'd like to point out is actually the tooling just is still kind of catching up. There's a wide variety of tools, none of them totally mature, and the documentation is sparse enough that it can be a little frustrating getting started on just having it totally like a JavaScript centric site. Taking the plunge on that side, too, to something if you want to go down the React road or really anything with server side rendering, that is just pulling it on the API and it seems like JavaScript is the most attractive option for that server end, front end.

CHRIS: Mm-hmm.

JEFF: The tooling can catch you up for a little bit and cause a lot of costs. There's no obvious way to authenticate a user through a single page app, so you're going to have to spend a little time figuring out, like, do I want to send a token back in my hash, and can I set up all SSL and then turn off logging and the redirects to make sure that I don't have a security leak? If I have other information in the hash because I'm using a hash router, can I easily pick out the token that I sent back, or do I want to use some other kind of authentication? How do I socially authenticate people - stuff like that?

There are still going to be pain points where you're going to require a server. You can't go totally JavaScript, or you can't just rely on the API. But, one of the other problems is also you're now maintaining an API. Whereas you only had a website before, now you've got two problems, right? Now you've got an API that's open to everyone to some degree that you have to make sure it's up, and you've got this website you've got to maintain, and there's a CMS you have to maintain. You're definitely blowing out your responsibilities a little bit, too, which could be a bit of a drain.

MATT: Yeah. Especially as the headless thing has caught on and has excited a lot of people in the Drupal world, a lot of the pushback has been around the idea that this is a solution to people wishing they had more flexibility at the templating layer. If we only did this in -- if we completely ditched the full staff rendering and we just did our own stuff purely on the front end, we'd just be able to do whatever we wanted. True, but you're also taking on a lot of complexity if you just decide you're building an app because your CMS's templating layer has rough edges that you wish you could ignore. Really realizing the benefits of it depend on hitting on more of those, you know, we want to be able to iterate the front end and backend differently.

We're dealing with lots of partners, and we need to be able to expose our stuff in different formats and different endpoints and stuff like that. Those are where a lot of the really big benefits are realized. Just doing it because front end tech is moving faster and is cooler than whatever version of jQuery ships with your CMS, that's where I think it's easy to get sucked in by the unicorns and rainbows promises and then become very disappointed that, you know, "Oh, my God. Now I'm stuck in troubleshooting this profile."

DAVE: Yeah. I feel like this episode needs a Part 2.

CHRIS: You're making me think of an idea of a static json -- you know, like there are static websites and how cool they are. This is an API that publishes static json files.

MATT: Oh, it's like Jekyll, but just a giant json file.

CHRIS: Yes! Yeah.

DAVE: All right, go to this website: silo.pocalyp.se. It is exactly what we're talking about. It is a beautiful--

JEFF: It sounds like XSLT all over again.

DAVE: Yeah, it's just a json file on the Internet. I love it. It's my favorite website now.

CHRIS: That is so weird. Okay. I've got a way for us to wrap this up. Let's say you have some CMS that isn't particularly decoupled or on the spectrum of decoupled or not decoupled that we talked about, which I really like. Let's say you're not as decoupled as you wish you were. What are some steps to get closer to that, should this be appealing to you--as our final roundtable kind of question--Jeff?

JEFF: I'm actually more of a backend nerd than a front-end nerd, despite all of my cheerleading for this. I would say one of the interesting ways you can do it with, like, zero impact on your current infrastructure is to actually look at the data and look at the database. Look at the content and data structures that you've currently got.

See if you can improve them and streamline those. Then start experimenting writing lightweight apps that consume that data first. Like, is it possible for you to make something that pulls your content out and does something interesting with it without talking to other stuff? If you can start getting comfortable with that way of dealing with your underlying content and data, and you feel like it yields some cool benefits, actually doing the work of building out an API might be really beneficial. But, investing the time and thinking through those underlying content structures and what your real editorial needs are and how this content is going to be used, those are questions that will benefit you even if you never fully decouple, even if you never go headless.

MATT: I think that's totally right. I'd just add onto that. There's always that old rule of the shape of your data will start to take the shape of your UI starting with just a simple user interface that will let you test. What you actually need out of an API should teach you just about everything you would need to know before taking this plunge.

CHRIS: Interesting. Any other thoughts on kind of baby-stepping towards decoupled, headless action?

DAVE: It just seems like, with things like the new Drupal Core features and the WordPress API and stuff, most people can probably turn on some kind of API at this point and then fire up CodePen--cha-ching--and start tinkering with this stuff. I'm not too far off, right?

JEFF: No.

CHRIS: No.

DAVE: Okay.

MATT: Yeah. No, that's totally doable.

CHRIS: I love it. Sounds good. Normally we answer a few questions. We're both running out of time and the fact that there weren't a lot of questions specifically about this. It was more just like, you know, blah-bidy WordPress, you know the kind of questions we normally do here, so we're going to do let that be and kind of wrap up. What do you got, Dave?

DAVE: Well, Jeff and Matt, before we go, how can people follow you and give you money? Then, what's one thing you'd like to plug before you go? We'll start with Jeff.

JEFF: Boy. I'm @Eaton on Twitter, not to be confused with either the Toronto Eaton Center or Eaton Corporation.

CHRIS: It's a new data format.

JEFF: Let me tell you. I hear about everyone's lunch.

DAVE: I am following the wrong business.

JEFF: Yeah, a lot of the work that I'm doing and the projects that I'm working on at are Lullabot.com, also a Drupal backed, React on the front end, headless project. Boy, something that I'd love to plug: I'm going to be actually talking about content modeling for structured systems and capturing design intent, some of that stuff that I was talking about a little bit. I'm going to be talking about that at Confab Intensive this September in Seattle, so I'm pretty stoked about that.

DAVE: Matt?

MATT: You can follow me on Twitter, @MattDennewitz. I think my name was in the tweet earlier, so you can find it there.

I don't really have anything to plug, but keep an eye on Pitchfork. We've got some really exciting stuff coming up. And, if you're a baseball fan, SaberArchive.com is a Sabermetric Research archive that I run, and we're about to get a very nice site refresh in time for the regular season to start, so I'm pretty excited about that.

DAVE: All right. Well, thank you, dear listener, for downloading this in your podcatcher of choice. We really appreciate it. Star, heart, favorite it up: that's how people find out about the show. Share it on Twitter. While you're there, follow us on Twitter, @ShopTalkShow. We give you tons of tweets a day. And, if you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire you.

Chris, do you got anything else you'd like--?

CHRIS: ShopTalkShow.com.