ScreamingBox Technology & Business Rundown

SPEAKERS
Dave Erickson, Ondrej Polesny

Dave Erickson 00:32
Welcome to the ScreamingBox technology and business rundown interview series. Today we are talking with Andre Polesny, who is a Developer Evangelist at Content.ai, a large Headless CMS platform. Welcome, Andre.

Ondrej Polesny 00:48
Hello guys.

Dave Erickson 00:51
Um, people's backgrounds are really important in the context of any position that they hold. So maybe you can tell us a little bit about your background in the development industry and how it kind of prepared you to be a Developer Evangelists at Content.

Ondrej Polesny 01:06
Sure, so I started my career as a DotNet developer for a digital agency based in Austria. Back then I was doing DotNet, some of the front end as well, because the project demanded it. But it was only, guess, two years later when I joined Kentico, because I used to work with Kentico in the past. So I joined Kentico, a traditional CMS vendor to work as a consultant in the Customer Success Department and I discovered that I can talk to both business users and developers. So it was a unique position for me to actually bridge these two together. And I spent over four years, you know, training developers, training business users, helping everyone to use the product to its full potential. And after four years, I figured that I wanted to focus more on the developer side and I also wanted to gather their feedback and learn how they use the system and bring it back to the product teams to improve the product. So I switched to a Developer Evangelism role. And at that time, Kentico was also kind of splitting between the two products. So the traditional CMS was actually renamed to Experience and the new Headless CMS that was just being developed was named Content. And I started working as a Developer Evangelist for the content division. So a full featured Headless CMS built for the cloud.

Dave Erickson 02:35
So in this role as Developer Evangelist. What is it that you enjoy about that role?

Ondrej Polesny 02:41
I always hated monotonous tasks. Like when, when I was working as a developer, I was afraid to look in JIRA to see one task that I would be working on the whole day; I always wanted a bit of variety and a bit of stress. Hence, the consulting position. But when I, when I joined the Developer Evangelism, it's, it's really, you're responsible for a lot of things. You have to train developers how to use the system, you have to get their feedback, you have to tell the world what your product does, and what is how it is better than other CMSs. So it's, it's a lot of things in one. And so that's, I guess what I enjoyed the most about it.

Dave Erickson 03:28
Maybe you can give a kind of simple, concise explanation of what exactly is Headless CMS.

Ondrej Polesny 03:37
So I wish there was just one sentence that I could say. But let's, let's try it. The Headless CMS is a storage for structured content. And Headless actually means that there is no visual representation of the content. So the, what it used to be in the past is that a traditional CMS was both the editing experience or editing platform for editors to manage content. And the live site where the content was actually displayed for the whole internet to see. Headless CMS is kind of decoupling that and it focuses on the best editing experience on content. It focuses on structuring content in the right way. So it enables content reuse and if you can deliver or it delivers the content to your application, regardless of what it is, if it's a website, if it's a mobile app, if it's anything else, it delivers the content via an API.

Dave Erickson 04:35
When you're using a CMS system like Content. Does it really matter what your developer experience is? I mean, if you came to Content as a DotNet developer, would you have a different experience with it than if you came as a JavaScript developer or some other type of developer like a Python developer?

Ondrej Polesny 04:59
So there are two sides to every Headless CMS story. First one is the content editing experience, right? That's the business users that are coming in creating content; they are collaborating, they are using workflows and everything, translators that are translating content, and so on. And then there's another story, another card for developers and developers are caring about totally different things than editors. They want the APIs to be understandable to the plane, to be always available to be fast. And, of course, they want to have the best tooling possible for their specific platforms. And as you know, every Headless CMS vendor tells you it doesn't matter where you consume the API, because it's an API, right? You can get the content anywhere that is able to create HTTP requests. But the truth is, the tooling is really important for developers because it saves you time for things like a Rich Text resolution for, you know, complicated, complicated content queries. So in those cases, you need to have an SDK for the platform that you're developing in. If you're a DotNet developer, or a JavaScript developer, if you're a Java developer, there are a lot of those developers. So I would say, maybe it's a brief statement. But I think that all of the Headless CMSs on the market now have SDKs, or other toolings for these platforms. So as a developer for these platforms, you should be pretty well covered.

Dave Erickson 06:34
So if, if a company or a group of developers or a startup or something, is looking at building a website for themselves, or building some kind of digital product, why would they consider Headless CMS over, say, a traditional CMS platform? What, what makes Headless CMS so interesting, because five years ago, nobody was talking about Headless CMS and now everybody's talking about it. What, what changed? Why, why is Headless CMS rising in popularity so quickly?

Ondrej Polesny 07:15
Because that was a technology shift. Like if you're, but let's let's start with, with the starter question, like, if you're a very small team, if you're, let's say a local business that wants to create a website, if you want, if you're not experienced in creating websites, and you want your website to be up and ready quickly, then nothing changed for you there, like WordPress is probably the best choice for you. Because you can create a website, have it up by the end of the day, and you don't need to solve anything. But if you're a tech company, if you're a startup, if you, if you know that you're going to be working on a website, you're going to be working on a mobile app, you're going to want to send your data to Facebook ads, or Google ads, or any other channel that you can think of. There's one aspect of Headless CMS that greatly helps you, you know, manage and orchestrate that content. and that is content views. Headless CMS actually forces you into structuring your content. It doesn't, it doesn't allow you; It does in certain ways, but it's not advised to create content in an unstructured way. And as a result, when you want to change something, be it your, your name, like we've seen Facebook changed his name to Meta. If you had to do a rebranding like that, you would just do it in a single place. Yeah. But the thing that changed in the past five years is that we've seen a rise of JAMstack, JAMstack static sites. You actually rebuild the whole website ahead of time. You know, that's the main point of JAMstack, was really a technology shift. And it's interesting, a lot of developers, developers were really happy about the developer experience, because it was built by developers. The tools in the start of the JAMstack era were built by developers for developers. And they always needed a place where they can store content. It started with Markdown files and the tool would just take all the markdown files; let's say those were blog posts or products, and it would turn them and generate pages based on those files. But as the tools want to grow more, because the developer experience is good to a certain point. But if you want the tool to grow and be used more widely on the internet, you need to add editors into the mix. Because there needs to be someone who creates the actual content. And editors, they are not really happy creating content in Markdown files, or doing comments into GitHub repositories and so on. So for those you need a Headless CMS of course, even developers like if you are managing multiple sites, you don't want to go into markdown files every single time you need to change, but you can actually value the nice UI that is available to you as well. So I think that, that was the big reason why Headless CMSs are currently on the rise, because JAMstack. JAMstack solved a lot of problems for, let's say, small, smaller to mid companies. Now, of course, we see the evaluation or evolution of the tools as they try to support more enterprise features, same as the Headless CMS. So I think that the main reasons why all of this started to be widely accepted and used is that it's solved the major pain points of traditional CMSs, and that, that traditionally was the maintenance, it was the hot fixing, it was the security concerns, it was many other things, you know, that, that you needed to actually have teams to maintain all of that. And as we saw these things moving to cloud a bit, I think this is just the next stage. And now you just need to pay a certain amount of money based on the usage rather than to pay a lot of money upfront for licenses for, you know, scaling of servers. That was a big part of my consulting work. I was helping clients to actually estimate what kind of server power they will need for their websites without actually knowing anything about their websites. So that was kind of fun. But all of these problems just went away, because now you don't need a big IT department to handle all of that, because we have JAMstack that greatly improved all of that on the presentational site. So that's the head of the website. And we have Headless CMSs that did the same for the backend side for the editing, you know, management.

Dave Erickson 12:00
And is JAMstack the most efficient or does it really matter from efficiency? And maybe you can give some examples of some of the front ends that work well with Headless CMS.

Ondrej Polesny 12:12
Right. So JAMstack is just a way of building websites. Yeah, it's not tied to any specific technology like you can build, it's just a way of building sites that you probably structure. Yeah, you've pre build the whole website ahead of time. And then when your visitors actually look at the site, you can serve the static files from any CDN. Yeah, there's the main point of JAMstack, but it can be built with JavaScript, it can be built with DotNet can be built with PHP, it doesn't really put too many requirements on the platform of your choice, because the only thing you need to output are the HTML files. Of course, JavaScript is the most popular because JavaScript itself has a very easy learning curve. It's really easy to get up to speed. If you look at frameworks like Gatsby, Next JS, and so on. They have starters that you can just get to your local station by typing NPM or not NPM. But you just clone the starter from GitHub, and you run NPMI, or run NPM Start, and you have the website in front of you. And you can start changing the content. So you're not caught up in details. And it's really quick from zero to actually having your website ready almost for republishing. So that's, I think that's the reason why JavaScript is so popular these days, because a lot of beginners are able to now get into tech, and, and learn very quickly how to build these sites and get themselves maybe employed as, as front end developers and get better very quickly. But as we see a lot of JavaScript based JAMstack sites, and it doesn't have to be JAMstack, even it can be an app like Facebook, maybe based on React. Yeah. So those, like SDKs that are getting the content from the CMSs, they can also be used on the client side, right? So you can build a full featured client side app with content as well. So we see a lot of those. But we see a lot of DotNet apps actually, as well, because then when you look at JAMstack, it pre builds everything, then you can put it to CDN. But when you look at DotNet, it doesn't go this way. But as you generate the pages, you can definitely set up caching to do pretty much the same thing. Yeah, when a page is generated, you can still store it in the cache and then the website is very performant, very comparable to JAMstack actually. So you can also build very fast sites with DotNet and we see a lot of downloads on the, on the DotNet SDK. So a lot of people are working with that. And then of course you have other channels and websites, mobile apps, Java is, is very used there.

Dave Erickson 15:05
And if you're a flutter developer, you can still use CMS, Headless CMS without any problem.

Ondrej Polesny 15:10
And that is a great thing. Like if you're using flutter for your development, you can use the same content that your colleague is using for the website development with JavaScript. And your other colleague is using Figma, you know, to build the designs and still using the same content from the same CMS. So there's, that's the greatest power of the Headless CMS. It's something that you potentially could do it traditional, but it will be very hard to implement.

Dave Erickson 15:36
Is there some kind of like, checklist, you could say, Okay, think about this, this, this, to figure out whether Headless CMS is really the direction you want to go?

Ondrej Polesny 15:46
Yeah, there's multiple approaches, and we could probably be here a whole day um, thinking about when Headless CMS would be a good choice. There is actually a great article that I can link you to. I can share the link with you after the podcast that actually shows five different frameworks that help you evaluate if your client is a good fit for a Headless CMS. It's some, I'm a bit biased here, because all of my new projects, they started with a CMS, because it's really easy to store the content, like in the past, a lot of the projects that at least I was doing started with MySQL, because I was doing a lot of PHP. And I always started in, in the database, defining the data model for my app. Now with Headless CMSs I don't need to do that, because I can start quickly with the CMS, just click through the few content types, and start working on what it actually matters, you know, the app implementation. So I would say, depending on what you want from your project, and what your teams want. It's, it's about the editor experience, depending on how many editors you have, what kind of experience they have, if they were working with WordPress before, all of these, it'll kind of come into the mix. And then it's about the developers. And because right now, when you look at traditional CMS, like Sitecore, or even our experience product, it's tied to a specific platform, it's tied to DotNet, or other platforms of other CMSs. And it might be easier for you these days to get a developer for JavaScript for React or for View. And in those cases, it might actually be the deciding factor of your tech stack that you're going to use for your next project. And developers actually, these days, they want to use React, they want to use JavaScript, they are happy because the developer experience is great. When you're facing a task, there's a very high chance that there's going to be an NPM package that, you know, solves the task for you. So that alone can be a deciding factor. And of course, then it depends on what your project actually needs. If you're working on a project that only displays some content, contact details and so on, it could go with WordPress. But if you have a system that is integrated with CRM that is integrated with an Ecommerce platform that is integrated with a payment gateway that needs to send out emails, that needs to send out push notifications, you know, all of these things, then you might want to use the best of breed solution for each of those tasks. And then as you're transitioning, maybe you're transitioning from a traditional system, in that case, because you want to have the cloud expenses under control, in those cases, you want to go best of breed for each of these systems. And in those cases, Headless CMS can be a very great option. So yeah, I think that would be the easiest way, how we can talk about it. But mainly, it's about, I would say mainly, it's about the digital maturity of your client or of you as if you want to build it, build it yourself, and how you look in the future, because definitely structured content is going to have your back in the future.

Dave Erickson 19:18
Is there some experience or some situation that definitely won't work? Well with Headless CMS?

Ondrej Polesny 19:28
Hmm, a good example would be for let's say middle sized companies that want a lot of features, and they don't want to look for different vendors, like if you want to go into microservices and you want to go with your whole business. It takes a lot of knowledge to make good choices. So either you can go to a digital agency that will probably solve this problem for you, or if you don't want to do a lot of decisions and potentially get burned um, because it's not that easy to orient now in the microservices space, then you might as well go with a traditional CMS. Because then the fact that you have all in one, all the features in one may be a very good benefit, because you pay, you know what you're gonna pay upfront, you know, because if you take standard traditional CMS, you put it into, let's say, Microsoft Azure, because you don't have any traffic spikes; you're happy with the performance of the system there, then it can be a very good choice for you, because you can estimate the costs and it's a very good chance that the system is going to work for you well. But then if you grow too quickly, or you get the traffic spikes, because you have an ad in a television, then you know it, you may start to overgrow the system as a whole. But it kind of sounds like a good starting point.

Dave Erickson 20:57
Is there a particular type of content that best fits CMS or Headless CMS systems? Or are Headless CMS systems completely independent of content, doesn't matter what type of content you're trying to push through the system?

Ondrej Polesny 21:14
So, it depends on what kind of content you have in mind. I have seen a lot of things. I have seen companies that were using the VR models, and that they were stored in our Headless CMSs, were using that to, I think it was a project where they sold or where they were selling art items through their website, and they had actually the models stored in content. I think it depends on your content model. But of course, if you want to store large videos, or large audio files, or large binary things, then there are better platforms. And we actually advise that to clients. Like if you want to store these things, you might as well use some Azure storage or other platforms that do this better. Because content, the content that we are focusing on is mostly in a text form. Yeah. The Headless CMS, or I don't know about other vendors, but our Headless CMS is built for efficiency and collaboration in workflows. So if you put a PDF there, or if you put a Word document there, it can work like that, but the Headless CMS, or one of its purpose, is actually to free you of using Word documents for collaboration. Yeah, so you can directly use, directly the CD CMS, to handle your comments to handle your tasks to handle everything you need to to actually get the content approved, and then you know, convert it to a PDF. That's, that's perfectly possible. So yeah, depending Do you have any specific type of content in mind?

Dave Erickson 22:59
Well, I mean, a lot of content now is text with images. Text with short video. But like you mentioned, there is content that is VR generated. There's now a lot of content NTFs. Who knows how they want to be used. Blockchain is involved in content, and who knows what type in the future. I assume that Headless CMS is most efficient with kind of standard text and image content, or standard size images and text, but that's kind of why I was asking is, are there limits? You know, if you wanted to make a whole bunch of videos and distribute large videos through a Headless CMS system, is that efficient? Or is that something it can handle? Or that's not really a good application? And kind of thinking of it in those terms for content?

Ondrej Polesny 23:54
Right? Yeah, I would say it's not a, it's not a best case, because the Headless CMS is not the best source for everything. Yeah. It's not a digital asset management. There are much better systems that are better suited for digital asset management that you can integrate into your Headless CMS. And you can let editors work on content items and select items from the digital asset management. The same goes for Ecommerce, and we have great platforms that do very well, Ecommerce scenarios. And in those cases, you might want to have the products there and in content, you want to just work on the marketing side of things. But it can integrate the Ecommerce platform into your Headless CMS, so that you can work on it efficiently. So I would say it depends on the type of content but as you said, the images, the text and other things, that's a totally standard case for working with content in Headless CMS.

Dave Erickson 24:52
The content strategy and the modeling of the content and the type of content you're going to do and when you're going do it and the content flows, it seems to me that that's a really critical thing that you kind of need to know before you start dealing with a Headless CMS system. Is that correct? And if so, how would you advise somebody to go about coming up with a content modeling or content architecture for Headless CMS?

Ondrej Polesny 25:24
Yeah, I definitely agree with what you said, if especially if you're a large organization. In those cases, you probably know what you want; you already have the processes in place. So we're not starting from zero. In those cases, when you're interested in content modeling, we have content modeling courses, so we have a lot of content modeling content on our blog. So that could be a nice starting point. And there are other courses online, for free that you can, you can look at, that will actually help you in your path towards the best content model. From my experience, that's a lot of, that’s a lot of work to get it to a state that you would be happy with, essentially. Because there are multiple roles connecting, and you have to work with all of them to make sure that the content editing experience is best. And one of the biggest problems of the past that I experienced, is when the developers are actually building the content model. Because in the past, it used to be like that. Developers were installing the systems, and we're creating templates for data that the editors had to work with. But these days, that approach doesn't really work because developers work very technically and they see the structure of content in a totally different way than what makes sense for editors. Yeah. So getting the fine tuned content model requires actually a lot of work. And yeah, there are content modeling experts, I'm actually not one of them. So I would, I would advise everyone to start there. And yeah, definitely assign some time for it, if you want to use content efficiently.

Dave Erickson 27:15
Does your content platform, does it have tools to help people do some of this content modeling or is it really something that is very separate outside of the Headless CMS?

Ondrej Polesny 27:29
Yeah, like, we have tools that allow you to implement the content model that lets you reorder the content model as you start using it. We have seen lines that help developers essentially, adjust the content model as you go with, with only code that helps with migrations. Otherwise, if you're asking about visual tools that, you know, help you build stuff, then we don't have to have any, anything like that. Because again, there are other tools that do this, do this much better. We internally, I think, use Myro, which works very well for these kinds of scenarios. But what we, as a Headless CMS vendor, because we're focused on enterprise, and with that focus comes with, comes also greater responsibility and the services that you need to provide. And we also provide this to the professional services for, one thing for developers where we can train them and we can show them how to, how to use the CMS to its full potential with the, with the JAMstack frameworks and anything else. And we also have a content modeling professional that can come, come to you, look at your content needs, and advise you on what could be changed.

Dave Erickson 28:48
You mentioned enterprise and how the responsibilities of an enterprise situation and say in SMB small business, small and medium business may be different, because their content needs are kind of different, but they all need to generate some kind of content flow. Some of it may be large, some of it may be small, but that involves, kind of, a scalability aspect, you know, between a traditional CMS and a Headless CMS system. Is one better for scaling up or for large scale stuff versus smaller or medium size applications.

Ondrej Polesny 29:27
Yeah. So there are two things. One thing is how the Headless CMS is Agile. Well, the Headless CMS, or at least the ones that I knew about, are built for cloud or those that are built for cloud. There are still some that you can install on-site. But most of them are built for the cloud. They are built with the scale in mind yet so you can scale the application and the teams know very well how to host it so that your editors, we're now talking about the editor experience, yeah, when they go into the app, and you have a lot of editors coming in at the same time. Yeah. So there's the scaling of the app. And that's the vendor's problem. Yeah, the vendors actually are handling how the app is running. And you, of course, have to use a database that's also built for speed. And then, then you have the other parts and there's the delivery of content. And because then, there's the critical part, because your website always needs to be online. And the content, even if the main application goes down, for whatever reason, the content always needs to be available. Yeah, because otherwise your mobile app might not,might stop working, your website might stop working, everything in, and that's where we actually get to SLAs and that's where your money lies. Yeah. So that's another part and the Headless CMS actually. Apart from a normal CMS, the fact that it's using the API to deliver content allows you to make this really robust. We're using a CDN network, Fastly, that actually delivers the content into all of the world. And it has a lot of nodes around the world. So even if one node goes down, your content still lives on all those other nodes. And even if the main application goes down, your content delivery is still in place, it still works. As if nothing changed. Of course, your editors can go into the app until we resolve the issue. But your, your live site, and all of your apps are not affected. So that's one of the things that relates to scaling, because if you have traffic spikes, now you know, with the whole situation, in Ukraine, we see a lot of DDoS attacks, that's something that can easily take your site down. But if the content is stored on a CDN, in the best case scenario, you have a JAMstack site that is on the CDN as well; then you're pretty much resilient to any, any of these issues. You also wanted to, wanted to touch a bit if I can on the Agile side of the implementation. Because, you know, having the content in a single place, I remember when I was working on a traditional CMSs, then we have to solve things like we are, we're using a team, we're using a central database. And if you change the structure of something, you had a lot of issues, then you have to ask your colleague to merge their changes so that you can get your website up and running, you know, to get the build ready, and so on. So the Headless CMS actually makes your teams more agile, because the content is living in the cloud. And, of course, depending on the CMS, but content allows you to create environments. So if you want to test some feature on production, you can just create a new environment from that production and it's still in the cloud. And you can switch just the, the content source in your project to that. And you can test your changes without affecting anything and you don't have to meddle with databases, you don't have to do anything; just change one project ID in your environment to file and work with competent, new types of content. And then when you're ready, you can push it and you can have it in production. So I think that this helps a lot with the developer experience, because you're not waiting two weeks for the next release until your changes are live. But you can get them there immediately and you have also, a very small probability that your colleague is going to be limited because you made an error. Yeah, I remember, when I was working for a digital agency, we had a we, we had a, like a, like a bet or something that when you broke the build, you had to buy everyone in the team of beer. So we got drunk every day. It was actually a big problem. So I like to say that Headless CMS is actually, they may not solve the problem a 100% of the time, but they definitely make you enjoy your work more and be more agile and be more effective.

Dave Erickson 34:19
What, what's your experience with low code and no code solutions and Headless CMS?

Ondrej Polesny 34:26
My experience, I don't have hands on experience with any of these tools, for one simple reason, because our customers don't use them very often. I think that, you know, because we're working mostly with large projects, I don't think that the NoCode approach actually works there. And when there were attempts at using NoCode, it actually required a lot of configuration even from technical roles. So it didn't make sense to actually use that, but with that being said, we know that. So there is a certain gap between working on content and as visual representation on the website, right? Because editors, they, for, for the past 15 years, they were, they were used to WordPress. We actually taught them that, as developers, we gave them with a WYSIWYG editors where they could make the text red and in Times New Roman, and we told them, like go nuts and create your website. And they get used to it, they get used to seeing everything right away. And while we see a lot of Omni channel attempts these days, and the largest projects that we have, are actually targeted at different channels than web. We still see that pretty much all of our clients, they have websites, right and the website management is one of the biggest things for any Headless CMS. So we also have, have an SDK that you can plug into your website that allows the editors to see their changes directly in the website frame. And what it actually enables you as we have it implemented in our site, is that the editor can, or marketer can go into the Headless CMS, create a new page, and build their own page only with predefined components. So we defined, let's say, 20 components, CTA buttons, text, hero sections, you know, and everything. And they can come in, they can give their picture URL, they can give it a name, they can define some other settings and they can build their page with components and see visually how the page is going to look like. So it's kind of a no code solution, you could say, but it definitely required not insignificant development effort first. And I think that's a very similar experience that a lot of people will have on enterprise level projects. Because those projects will never work with local solutions, because for one thing, there's probably going to be a lot of configuration options. And for a second, not sure how the performance is going to look like. But the large projects, they require a lot of performance improvements. So it might be an issue there. But I haven't worked with any of those local solutions myself. So I cannot say there.

Dave Erickson 37:26
Um, I would like to go back to a subject that you had mentioned before, and I want to just kind of get a better understanding. You were mentioning that Headless CMS deals with a lot of different channels. Can you kind of describe a little bit about what are the basic channels? And how are they kind of different? And why would enterprise be using one type of channel and small business or medium business be using different channels?

Ondrej Polesny 37:54
Like they can, they can probably all use the same channels as well. It's not that small businesses would be using different channels than enterprises. What we just see is that typically, the small and middle sized businesses use mainly their websites. So the website is their main use case that they have and everything. Sadly, also, the content model is designed very Web-centric. Yeah. The enterprises, and I cannot talk about specific projects, because we have NDAs in place.

Dave Erickson 38:26
We're looking for more general terms. Yeah.

Ondrej Polesny 38:28
The enterprises I've seen. They actually use mobile apps to deliver different kinds of experiences. They use the voice assistants to deliver content into their apps. They use, I've had a client and they actually wanted to generate reports and they wanted to store a history of financial reports in the CMS to make sure they can go back and they don't have to store PDF files, but they can generate them on demand. We've, We've had clients that want us to power content kiosks, from the same content that already happened to CMS. So its use cases like this is just when you are a big enough company, then you start working on these tasks, while if you're a small business, these channels are probably not that relevant for you.

Dave Erickson 39:20
General kind of concepts of how webhooks are used.

Ondrej Polesny 39:24
In general, they are just an HTTP request that travels from one system to another. Yeah, when something in reality, how it works, if we're talking about the publish webhook, it works in a way that you create the content item, you publish the content item, as an editor, and you don't care what happens. Yeah, that's, that's all you need to do. And the system actually takes that event of the content item, and builds an HTTP request with the data of the item. So you know which item was changed, and takes the data and sends it to a predefined URL. So in the, in the CMS, you can define, I want to react on published events of these types of items. And I want that request to be sent to a specific URL.

Ondrej Polesny 40:12
So you can have 10 URLs for the same event, you can have 10 events for 10 different URLs, it's perfectly fine. Typically, this is used in JAMstack for rebuilding of sites, or rebuilding of parts of sites that you can send a message to your hosting provider, hey, this page changed it, you might, you know, remove it from cache or rebuild the whole site.

Dave Erickson 40:43
There are a lot of different Headless CMS systems out there. How would you go about if you were in the shoes of a person evaluating Headless CMS, which Headless CMS systems would work for them? Are all the Headless CMS systems pretty much equal or do they have differences? And if so, what are, kind of, the differences somebody has to look out for when choosing a Headless CMS system to commit to?

Ondrej Polesny 41:12
Again, a very broad question. And I cannot probably answer it with just a few sentences. But I would say there are three groups of CMSs that you can distinguish. First of them is well, first of all, you need to decide if you want a cloud based or a self hosted. Yeah, most of them these days are cloud based because of all the benefits that I was talking about earlier. And then you know, there are three groups. First of them is, the free systems that are like strappy that are open source, you can get them for free. You can run them yourself, or you can pay someone to run them for you. And I guess that they make their, their business out of support, which switch is a very valid use case. The second group is the I would say, a very developer focused, or startups or CMSis that are very price friendly for newcomers into the space. Yeah, those could be prismic, storyblocks, or others that are very focused on a very on your happy path. Yeah, it's very easy to start with them, it's very easy to build websites with them, they have starts, for everything. And generally, you're going to be very happy with using them. But it may depend, it depends on how you use the system. Because he can grow quicker than the CMS can actually support. Yeah. Or you may, you may see that it works very well for you. You want to scale your app, you want to get more editors in, you want features like task management, for example, for editors, and then the CMS can be a limit of what you can do with your content. And then you have Enterprise Solutions. That's obviously us. It's contentful, its content stack, that don't only support you and your content needs, but they also give you all the tools around for content collaboration for, for all these, you know, use cases, like very good security, for the deployment model and the deployment model for the data center location, for example. Yeah, some security, people may have a problem with that, that you want your let's say you're in the European Union, you want to have your data stored only on the European Union soil. But it's also about if you're a really large company, it's about the isolation model if the vendor can give you your separate space, or if you're using a multi-tenant solution, because I would say that the, all of them are, are implemented that way. And then, of course, it depends on the SDK for your preferred, preferred platform. If you're a developer, it depends on the integrations. If you specifically want to use, let's say, one ecommerce provider, you might want to check if the integration with your Headless CMS is there. It's also about the documentation. We developers don't want to learn docs. But if there is a problem, we really love it when the docs can be really easy to find, and, and helpful. It's also about the security and data protection. Some of the CMSs are certified, some of them are not. If you're in the enterprise space, certifications, like ISO, or SOC2 are very important. Yeah, so in, in terms, but now we're a lot on the, on the enterprise side. In the end, it depends on what your stakeholders need and want. Yeah, it's what the developers want, what they want to work with. It's what the editors want in terms of the features they want to work with and how we can make their experience the best. And it's, of course, about the owner of the project and the budget as well. Yeah, because obviously, the best, best service and everything is with enterprise solutions. But then the price tag is, is also relevant. Yeah. And one of, one of the things, last things I say, I promise, I promise. And my personal favorite is the company culture fit. Like, we haven't seen this in the past too much. But when I was working as a consultant, we were pitching the CMS to one agency or one large company in, in France and one of their questions during the pitch was actually how Kentico treats its employees. And I think that nowadays, it's going to be more and more relevant, how the culture fit of the tools that you are using, is actually fitting your company as well. And what I, what I like to show this on is the support because the larger CMSs, the different the need to support you 24/7 if you can publish something on a public holiday, or during Christmas or whatever, there needs to be someone that can help you with that. And of course, it can mean if you're not spread out throughout the world, it can mean that people are working night shifts that are, that are long, working long hours and so on. So the larger companies can actually support these use cases as well.

Dave Erickson 46:50
Well, Andre, thank you so much for your time and going into the details and answering our questions about Headless CMS.

Dave Erickson 47:00
Thank you very much for taking this journey with us. Join us for our next exciting exploration of technology and business in the first week of every month. Please help us by subscribing, liking and following us on whichever platform you're listening to or watching us on. We hope you enjoyed this podcast and please let us know any subjects or topics you'd like us to discuss in our next podcast by leaving a message for us in the comment sections or sending us a Twitter DM. Till next month. Please stay happy and healthy.

END

Outline
1:06 - Who is Ondrej Polesny?
3:28 - What is a Headless CMS?
6:34 - What, what makes Headless CMS so interesting, because five years ago, nobody was talking about Headless CMS and now everybody's talking about it. What, what changed?
8:37 - What’s changed in the past five years?
15:05 - Headless CMS vs. traditional CMS.
15:36 - Is there a Headless CMS checklist, think about this, this and this; to figure out whether Headless CMS is really the direction you want to go?
20:54 - Is there a particular type of content that best fits CMS or Headless CMS systems or are they completely independent of content?
27:09 - Does your content platform have tools to help people do some of this content modeling or is it something that’s separate outside of Headless CMS
29:27 - How Headless CMS is Agile?
34:06 - What’s your experience with low code and no code solutions and Headless CMS?
37:26 - Headless CMS deals with a lot of different channels. Can you kind of describe a little bit about what are the basic channels?
41:12 - Are all the Headless CMS systems pretty much equal or do they have differences?