Ep. #46, Headless CMS with John Kelly of Contentstack

Brian Douglas: Welcome to another installment of JAMstack Radio, in the House we've got John from Contentstack. Hey, John.

John: Hey, how are you doing? Thanks for having me.

Brian: Cool, yeah. We have you in the room, and I'm just curious about what you do and why you're here?

John: I'm product manager at Contentstack. We are, as the JAMstack know as well, the audience, a Headless CMS company.

You can also think of it as API first, API only, content as a service, counter -infrastructure.

A lot of analogies there, but yeah. Basically the most well-known is Headless CMS.

Brian: OK, cool. Headless CMS is a term that we-- We've had other individuals on the podcast talk about that as well.

How long have you guys been using that term, "Headless CMS?"

John: We've been using it for probably as long as the company's been around, which is a couple of years.

Pretty nascent in the industry, but I actually came from a CMS background working for a company called DNN Software out of San Mateo.

They were an old legacy .net, monolithic, on prem CMS from circa 15-20 years ago.

We ended up developing one of the first decoupled CMSes, which is a little bit different adjacent to Headless in that they were still an on prem installation, but it had a restful API that you could access.

That was about 5 years ago, and that's right around when the Headless CMS revolution began.

Then it really picked up steam just about this past year.

Brian: For the sake of the listener, who maybe this is their first episode.

"Headless CMS," you mentioned the definition, but essentially separating your CMS from your mono repo or your personal repos?

John: Yeah, that's exactly right. I think the term probably is thrown around in a lot of different ways. I think it's probably being refined even as we speak.

Honestly, with every new white paper that gets released from some company, they'll probably refine even further.

But yeah, exactly, it's basically just content as a service.

In the same way that you might create a forum or create some entry on a page within a website, that content itself has no idea where it's ultimately going to be published.

It just exists as what we like to call "Structured data," so it can be sent anywhere.

It could go to a webpage, could go to a mobile app, it could go to a watch, or a display, or go to an IoT device.

We have no preference and it makes it nice and flexible.

Brian: So, the structure of Contentstack. You, I'm assuming, have a log in.

You establish a presence on the GUI, build a project, and then you have an API that talks to you like your React app, or your--?

John: Yeah, that's right. So we have this idea internally, actually. It's some of our "Four 'E's."

We have a lot of acronyms that we throw around.

One of them is "Equality" and we position ourselves both as an editor-friendly and market -friendly CMS, so for business users and also equally as well for the developer audience.

There is definitely a web application, but the APIs that we have that power the underlying app are actually the same that the web app uses, as well about 95% of those.

In fact, we have use cases and customers that actually build their own application that communicates with their APIs, so some of the editors don't even log into Contentstack.

They do behind the scenes, but our web app is only one half of the application itself.

Brian: In our pre-show conversation we had talked about Contentstack, you guys are focused with the enterprise world.

I'm curious of why the enterprise world? I have an idea, but I'd sure like to hear from you. Why the enterprise world?

And what's the difference approach to getting large, essential corporations to leverage Contentstack or Headless CMS in general?

John: It's an interesting question.

I was thinking about what that answer would entail.

I think honestly it more comes down to a very long laundry list of reasons why we chose to go enterprise, as opposed to SMB, mid-market and upstream.

Whereas a lot of nascent technologies, especially in the JAMstack world, are built for experimentation.

Developer ecosystem driving this groundswell of grassroots movements, and then you refine from there and move up market as the requirements get more complex and stricter.

We and our founders and pretty much everyone in the company actually has enterprise DNA in their blood, is the best way to say it.

We know how to talk to that audience, we know what they're looking for, we understand what that sales cycle might entail.

There's quite a lot of things that go into it, both from a product side, from a process side, from customer success side, from a sales cycle side.

I would say the product is definitely one large piece of it, because we are the beneficiaries of having amazing customers and at that enterprise use case, they give us also awesome feedback.

We really see ourselves as partners with them and they universally see themselves as partners with us.

We really work together with each and every one of our customers to really make sure that the product we're delivering for everyone meets these enterprise scale and these needs and complex workflows and use cases.

That type of feedback, it really is self -reinforcing and really honestly helps to drive our roadmap in a positive direction.

Brian: You mentioned that Contentstack has only been around for a couple of years, handful of years.

I know me personally, I've been at small companies who get into the enterprise world and there's this push and pull between the developer and the enterprise world.

There's features that are needed for enterprise, but there are features that developers don't care about, but we need features that enterprise don't care about.

This back and forth between the sales team and the developers, or the engineering team and the product team.

You mentioned "Equitable" and "Equality" between the two products.

So how do you do that push and pull and how do you hit that balance and how do you not make sure your product is good for all walks of life and developers?

John: I think it's always a negotiation.

You're negotiating with your sales team, you're negotiating with the market at large, you're negotiating with the customers, with pretty much everyone internally.

Obviously what the engineers want to build, and of course we have this equal stance between the business user and the developer user or the technical user.

What it really comes down to is understanding that for that type of use case, for that type of customer, put it on the sales side for a minute because obviously there's a sale involved as we're a closed source product.

We're not open source at all, so we do rely on our customers to survive.

It's a pretty lengthy and complex cycle.

We deal with a lot of stakeholders in these organizations, so we really do have to provide this solution that meets both needs of the technical folks as well as the business users.

They have this myriad of unique bespoke workflows that we have to address, and it really comes down to catering to both audiences simultaneously and understanding that at that level there's no such thing as a one-click integration.

There's no such thing as these simple sign -in to little plugins and widgets, there is a need for very complex, bespoke solutions to their exact use cases that we have to do our best to cater and hold their hand through that solution come to fruition, but also provide the flexibility to customize it themselves.

Brian: You mentioned you're a PM at Contentstack. Are you the only PM?

Are you focused on the enterprise side, and then you have another PM for the developer side?

John: I'm it.

Brian: You're it? OK.

John: I could say Head of Products, but it's a department of one.

Brian: I'd claim that title. You just got to stake your claim.

I'm senior Beyonce Advocate at a GitHub, so if the chance ever comes, people will notify me that Beyonce's at GitHub.

That's what I do.

John: I need up to update my LinkedIn.

Brian: Excellent. I'm curious though, what's-- In the enterprise world, what's the killer feature that Contentstack brings to the table that makes enterprise excited about it, and that you're winning with?

John: I think it's a mix of both process and product.

Ultimately, we have to design the product itself to exist and flourish at that scale.

If it's millions of operations or pieces of content or whatever it happens to be, the scale is much more complex, deeper and broader.

Of course supporting those types of use cases is one thing that a lot of organizations, when they're in a POC phase, they might run into those particular limits and they may not be called out on any marketing site.

If you look at 15 CMS marketing websites, they're all going to say very similar types of features. The devil's in the details.

Each one of those particular features is going to have some devil at the end of it where they're going to say, "It looks great on paper, in a 3 second marketing website functionality or feature comparison.

In reality, during testing, that's where the difference is made.

Brian: I assume there's a lot of migration from a Drupal or WordPress world.

Do you get a lot of those conversations?

Mind sharing the benefits around why you would not go through some traditional CMSs, that maybe they came through a web 2.0 or late 2000s, maybe they're stuck on?

John: Yeah we do, for sure.

What's interesting is during those conversations as well, WordPresses and Drupals and traditional legacy CMSs have created these workflows that actually work really well for the business user.

A Headless CMS fundamentally is no different than a traditional CMS in the way that the application-- Or, in the way that the user experience flows.

They still have the need for workflow, they still have the need for permissions and roles and all these user segmentation things, especially at that complex and deep level.

It's really a technological update.

There will always be incremental improvements, like the WordPress platform, but what they're hadn't been was an evolutionary step forward at a deeper technical level.

How that content is being published and interacted with and managed, so that's really where the biggest difference comes in.

Brian: Curious. I want to zoom out a little bit on the conversation and this talk about CMSs in general, and where we've come from.

I've spent all morning working on an actual site using Gatsby and the structure itself, it has no CMS attached to it, but it has the equivalent which is the JSON files that I can populate and it populates onto my page.

It's pretty common in Gatsby, the Gatsby world and static site generators.

I'm curious if me as a developer, I'm throwing the site together as a one off, like "We're doing this one event and we want to talk about it, we want to have a page for people to walk to and then I'm going to never ship code to this ever again, unless we do it again next year.""

So I should be able to hotfix 2019 to 2020, then we're doing the event again. I'm curious, should developers be looking into--?

And I'm talking outside of the enterprise worlds, the developers who have only start approaching Headless CMS and leveraging this, when will we see more adoption, as far as it goes, generally?

John: Yeah. I think there's a couple questions they probably need to answer.

The first one is whether they have a need for portability.

You mentioned that the CMS you were using, it does have a head, so it's not quite headless, but it has the option to publish a structured JSON Doc.

If that particular document never needs to be updated, at some point in the future, maybe you don't have access to that exact CMS.

Or if you do have access to that CMS, but you simply need to revisit that article and update a few things and have both the old website possibly updated, and new one also updated.

If there's a need for portability to basically make sure that there's a canonical version of that content that's always up to date, no matter where it lives. That's the first question they need to answer.

The second one is on reusability, when I mentioned when you're updating it year after year, possibly you're not going to want to just--

Maybe the site itself is forgotten about, maybe there's a full refresh and it's a totally other microsite or static site, but the content itself will most likely--

Maybe you're using half of it, maybe you're using only a third of it, but you probably want to go revisit it, take some cues from what was already there, and then like move forward from that point.

It's oftentimes never going to be a complete bottom to top do over.

There are portions of most sites, even if we think "We're never going to use them again, we're going to throw them away in two months after our event is over," that do ultimately end up getting reused, whether that's picking something off the shelf from a technological perspective or even picking up that content again and updating it.

Brian: Yeah. I'd love to see, hopefully people listening to this, adopting this model of content management because I think I'm really hammering this event idea but events like HacktoberFest where everybody can get together and ship code together, but then you have these one-off meet-ups.

So it's either create your own meetup account and then set up this meetup or use this template to host your own site.

There's another event, the Global Speaker CFP Day, was another event very similar. Everybody forked a template and then shipped it.

It seems like there's a lot of opportunity for "If there is a model that could be reproduced, that you can clone the existence-- If it's your Contentstack or whatnot."

I'm sure, even at these enterprises, I don't know, we didn't really get into these use cases at the enterprise level, like "Are these marketing sites, is this your full on site?"

But I know for a fact, some of these agencies who are shipping brand assets are using a CMS to recreate that same asset brand template, over and over again.

It seems like a lot of value for people internally to have the model to be able to reproduce this thing really quickly rather than bottom up.

John: Yeah, exactly.

If you were to graph out, visually, how much our projects spider web from a single point and then the distance between how far those points actually reach, no one listening can see this but my fingers are basically end to end right now, fully outstretched.

Then you try to say "What are the common elements between point A and point B?" There's probably quite a bit of reuse and portability there.

That simply has to be thrown away and recreated.

It actually comes down to what we're going to talk about later with the picks.

It's this idea of the knowledge work that we've all become accustomed to doing exists in silos, however, our brains don't exist in silos.

We create a Google Doc and then we share with people and everyone collaborates and then we say "OK, that's great, content's done" and we forget about it.

Then a year later, we're like "Crap, where did that Google Doc go?"

Brian: Yeah, searching in Google Drive is challenging on large organizations, for sure.

I'm literally doing this with my team right now, where we're-- Our team really started when I joined, so I was employee number one on the developer relations team.

Then we grew from there at GitHub.

Now we're setting up all these processes, so if we speak at an event, "What sort of activity should we like plan to do, or what sort of people should we look for that engage in the community?"

We have these checklists that we're reproducing over and over again every time we need to approach an event.

I think it's a model that we tend to do a lot. It's kind of like a sales model.

We tend to develop relations in sales, they're kind of similar, but a lot of people that want mention that. The model is reproducible and we just need to have a template, fork it, work with it and then ship it.

That's the same process we've been doing where we're not sure, because everything lives in markdown on GitHub.

So we started a Google Drive, but that's really not the best place to start, because most people don't want to collaborate there.

Then we go to the GitHub, but GitHub is not the best place because in-line commenting on actual markdown is a challenge at the moment.

John: Then you're side by side with GitHub's Markdown cheat sheet and like "How do I do a bold again?"

Brian: Yeah, exactly. Yeah. Only certain elements can leverage those as templates.

Mainly comments are the only places that you can leverage some of those hotkeys in the WizWig.

It's an interesting thing to think about, in that the reproducibility and reusability in the context of everything that you approach.

I'm curious, going back to your initial introduction and the CMS, it sounds like you've been in the CMS world for a while and seeing the transition to Headless CMS.

Are we going down--? You're at a company that Headless CMS made, so this is not the best question to ask.

But it seems like we're going down a path where now everybody has their own decoupled version of X or Y.

So how do we manage the future world where we choose different things and then the whole Google Drive problem of trying to find out "OK, I saved this somewhere, where do I go to find this?"

John: Yeah, totally. You could see on paper and I think a lot of the CMSs that have a decoupled, instance or version of themselves or they maintain a monolithic CMS and they create this adjacent API that basically can fetch content from in a structured way.

I say "OK, great. Decoupled is the best of both worlds. You have your head and then you also have the ability to do all the headless stuff, if you really want."

I think there is a larger conversation that's not being had, that will ultimately--

It's been had in some circles, for sure, but it's definitely not part of the larger Zeitgeist around Headless.

Basically around this 360-- I wish I had a better way to verbalize it now and I guess that's part of how the conversation is still evolving.

This idea behind a monolithic CMS, or I guess a decoupled CMS, has the ability to publish content.

There's not a lot of ability to take what was done, do a retrospective on it, and then find out if it worked or not and then update it and move forward.

So there's this idea of in marking world where it's like "OK, we have our analytics tools, we do something, we find out if it worked, and then we lose the stuff that didn't work, do the stuff that did work a little bit better."

That doesn't exactly exist in the publishing world and the content world.

The CMSs that say "We have an API." like "Sure, just create the API and you can publish it to any Vue or React or Angular app you want."

That's great, but it still is a terminal thing. They do it, it ends and then there's just like "Now what?"

Where we're hoping to go is this idea of more of a content hub where, not only do you have the ability to publish things out, but you also have the ability to see the performance of the thing you publish and maybe you see it inline right next to the thing you just published.

Maybe you are able to pull in all sorts of other insights and data and information from services that are adjacent, but very related to the content your publishing like a product from SAP Hybris or pushing out to your preview environments on Gatsby and this entire ecosystem that's in a very meaningful way all of a sudden becoming connected, 10 years after Rest hit the mainstream.

Now we're starting to see after this gestation period is really coming to fruition.

Brian: Going back to Contentstack, we didn't really talk about-- Do you have hooks or integrations with common CI platforms to trigger builds on saves from Contentstack or anything like that?

John: There definitely are ways to accomplish that, for sure.

We have obviously your vanilla web hooks or your standard web hooks that trigger on a variety of rules you can set.

We have three pretty major sensibility points, both on the dashboard side, and then two within the entry editor, itself and then obviously custom fields, as well.

Then of course, you can certainly set up your CICD workflow and add Contentstack as a portion of that workflow to update and do pushes, either with your environments, or with your internal GitHub processes or your build process or wherever you do decide to use it in your stack.

Brian: That leads me to one of my picks, so I just want to give you a chance to-- If there's anything else we need to talk about.

We didn't really talk about scaling, working with large projects, enterprise. Did you want to touch on that, real quick?

John: Sure. We regularly see, going back to enterprise scale, projects where there's 60-70-80 different languages for example.

You talk about localization, we think of English, Spanish, French, German and you're like "Great, that's it. I did localization."

However, if you think of localization in the context of a market, you might have two dozen Spanish speaking countries between Central and South America.

You might have a half a dozen German speaking countries. You might have all the Nordics.

They all have their own language, but they also have an individual market.

Managing all these different variants of this massive piece of content 60-70 times, that also is the type of scale that we pretty often see.

Going back to our conversation about scale and tying that off. That's something that is tremendously complex and goes way beyond most capabilities today.

Brian: Excellent. I'm going to transition into some picks. Feel free to still talk about and introduce all these constructs about CMSes in your picks, if you like.

I really want to talk about picks, because my pick is some of the work I've been working on right now. I have a talk that's going to be at Full Stack Fest.

Around the time that this podcast is going to come out-- The video for the talk will come out after the podcast, for sure.

My talk is based on CI and CB workflows in the JAMstack.

All the process, I'm applying that to my day to day work, coincidentally playing this, but we launched an add on feature to GitHub Actions which is CICD. I'll talk about that as well.

My platform for wording all this is I had an idea where you have markdown files, and I would like to template those markdown files, essentially with variables.

If I know I'm going to have the same title going to show up throughout the entire document, I only want to set it once and then I want that document to then compile with that variable replace.

It's a common construct, Ruby, ERB templates do this, a lot of CMSs already do this for you, but GitHub issues don't do this for you.

I'm basically using GitHub Actions with CICD to do this automagically for me.

I've got this mostly working. This will be done by the time I have my talk ready.

I spent Saturday, Sunday working on this. I'm leading into my second pick, so I'm moving away from CICD, but I built a RubyGem for the first time.

I've been writing Ruby for about 7 years now and I've built a RubyGem based on reading a book "How to Build a Ruby Gem."

The title of the book came out a while ago, Ruby Gems are basically essentially like NPM packages.

So you just take Ruby code, package it and put that on RubyGems.org.

I had an idea to take the code I took to find the variables and then compile it and template it throughout the entire file. I made that a RubyGem, so it's called Marky Mark Down.

Check it out on RubyGems. I've got 0.3.0 is out already. Programming is hard, I made a lot of mistakes. I'm already on version 0.3, but I'm pretty happy so far with the API.

The funny thing is I was so heads -down over the weekend and trying to figure how to do this.

Ruby does this by default so the Gem is not that necessary, which is hindsight, but it was a fun process to learn how that process works.

How to get a RubyGem packaged and get people to use it as well.

Also, my last pick. I'm going to Barcelona and you had mentioned the fact that Spanish language, there's different markets.

It's not just-- Central America , there's a lot of different dialects so I'm going to Barcelona, which is also another dialect between--

Different than Castilian, which is the Spanish I learned in school with the proper Spanish, but it's way different for South America.

With that being said, I've been practicing Spanish so I hope I don't fall flat. I won't practice now, because I'm pretty insecure about it. I've been watching Narcos: Mexico.

Earlier episodes, I had a pick and it was Narcos.

I would watch this on the plane and whenever I travel, I would only watch this one show, thanks to Netflix's offline downloading.

I would watch it with Spanish subtitles, as well.

That way I learn Spanish as I watch the show that's being spoken in Spanish.

It was challenging, but since I was in a closed place, on a plane for a certain amount of time, I could really pay attention and listen, as opposed to being distracted at home.

John: Did you practice on the plane, too? Were you speaking to yourself very quietly?

Brian: I haven't really been doing that, not out loud.

There was a situation when someone behind me, who only spoke Spanish, needed assistance in a wheelchair and they put them in the wrong seat.

The flight attendant couldn't explain that to them, because the person who put them in the wrong seat already left.

They had to figure out "Can you can you walk? You're in the wrong seat, you should be in this seat."

I was like "What's going on? I kind of know Spanish, but my Spanish is really bad, so maybe I'll wait for someone else."

I thought this would've been a good point to say "I learned Spanish and I did it and I said it, but I got too scared. So I just sat there."

Listener, if you are a Spanish speaker, flex it as much as you can and be confident in that.

Someone right after me came on and he was fluent in Spanish and told her exactly, he was like "Caminele," or whatever.

See, I'm speaking Spanish and it's really bad. I'll stop right there. John, what are your picks?

John: Yeah it's a quality language to learn. I think you can never go wrong, learning Spanish.

I know a little bit, enough to get around and survive. When I'm traveling in a Spanish speaking country I don't think I'd be able to pull it up now off the top.

Funny story, I was going to live in China for a few months during grad school to study.

I downloaded the Rosetta Stone and I was like "I'm to learn Mandarin on my 12 hour flight to Shanghai."

I'm sitting on the airplane, and of course, you have to speak back into this thing for it to let you progress.

It's telling me all these Mandarin phrases and I have my headphones out and I'm yelling into my iPad.

I'm not going to even say the Mandarin phrases now, I forget most of them and I'm going to butcher it.

Everyone around me was like "Who the hell is this guy? This crazy person trying to speak Spanish into his iPad, in a super loud 747."

Anyway, that was the very short -lived Mandarin course trying to get to China trying to learn Chinese.

Anyway, my picks. First one, I think you mentioned drinks and entertainment, which I thought was a really interesting topic.

I definitely do have a drinks and entertainment's pick, and it's basically the theme of consolidation and optimization of food and drink.

From a drinks perspective, this was the summer of the Claw. Anywhere you go in San Fransisco, when it's warm out, you see White Claws.

Any gender, guys and girls, and they're delicious. It's carbonated water, basically no syrup, very low sugar and there's a little bit of alcohol.

It was the most refreshing thing you could ever drink. It's basically all of the good stuff, none of the bad stuff.

Then you have this evolution of alcoholic kombucha, pretty soon I've heard of alcoholic kombucha plus CBD.

Then it's alcoholic kombucha plus CBD, plus vitamin D, plus maybe a little bit of caffeine.

Who knows, stuff to make you sleep better five hours later.

Brian: It's like the Jamba Juice for a White Claws.

John: Yeah, exactly. At Jamba Juice and all these smoothie shops you have your to -the -max, composed smoothies and drinks where it's a shot of this, a shot of that, a little touch of this.

Brian: "Enhancers" is what they call them.

John: Exactly. All these enhancers.

Brian: Sorry, it's the JAMstack, but for drinks.

John: Yeah and it's funny, I actually have two picks. But I'm realizing there's an overarching theme between both of them.

On the food side, you have your meatless burgers, and all these optimized, soy -based products.

Of course, there is positive repercussions for the environment and all these are the things that come out.

However, it's also this theme of being very opinionated about the things that we consume and the things that we use.

It's like "Let's trash all the bad stuff and let's keep all the good stuff and let's optimize our life, in that way."

That actually leads me into my second one, I didn't even think about this when I was writing it down.

On the code side, it's really having opinionated solutions. We think of the open source movement.

We think of-- Hearkening back to what we talked about earlier about when Rest API first was released, basically everyone was espousing the fact that your world is your oyster now that you have these APIs.

You're almost like a used car salesman, where it's like "What does this car do?" And they go "Anything you want."

It's like "That's actually not very helpful. Let's talk about a solution." It's very solutions oriented.

You have Gatsby coming out, and they're very opinionated.

They go "We could have done anything. We could have made a very un-opinionated platform."

But we said "We're going to hang our hats on React, we are going to hang our hats on Graph QL, because we think those are actually just really cool technologies that we think are going to solve a lot of problems."

I think there is this other rise in the technological side, where now that we talked about before, APIs have gestated the fact that there's a lot of interoperability and interconnectivity between services and platforms.

Now you're starting to see these end to end solutions that people are talking about and people are developing and they're like "This actually is how we think things should be done.

You could've done it 100 different ways, this is the one that we think is going to serve you the best, or at least it serves us the best."

I think that's actually a really interesting evolution in the digital services and basically digital apps.

Brian: Awesome. I'm really into having opinions given to me, especially when I'm trying to ship sites I don't care about, so I can use them every year.

Which is why I chose Gatsby, it's the perfect platform to learn a new thing if you already know React, then learn GraphQL through Gatsby, if you know GraphQL and React through Gatsby.

It's a nice little platform to approach things. Somewhat like your White Claw thing too.

If you like White Claws and you've never had a kombucha, why not have both?

John: Yeah, exactly. Take a little bit of alcohol, a little bit of gut biome - healthy stuff, a little bit of carbonated water, maybe a teeny little bit of flavor.

Throw it all together. It's all the good stuff and none of the bad stuff.

Brian: So they say.

John: Yeah, maybe a little bit of bad stuff.

Brian: On that note John, thanks for coming to talk about Contentstack.

Enlightening me about all these composable drink mechanisms. Listeners, keep spreading the jam.