Talking Drupal #389 - Headless - Fact or Fiction

• What is headless
• What started you writing the blog post
• Where does headless make sense
• Does headless perform better than Drupal
• Are APIs always important
• How does progressive decoupling work
• Where does headless not make sense
• Are people putting too much faith in headless
• What is the future of CMSs

John  0:06  
This is talking Drupal. weekly chat about web design development from a group of people with one thing in common. We love Drupal. This is episode 389 Headless factor for fiction. welcome to Talking Drupal. Today we're talking about headless and if it's really all it's cracked up to be with Martin Anderson-Clutz. Martin is an aqueous triple certified Drupal expert. In addition to certifications for usability and a variety of other web technologies. He lives in London, Ontario, Canada, and works at Aquai as a Senior Solutions Engineer Martin, as always, welcome to the show, and thanks for joining us.

Martin  0:46  
Thanks. So it's a treat to be here. For those of you that don't

John  0:49  
know, I'm John Picozzi Solutions Architect at EPAM. And today, my co hosts are joining us for the second week Jacob Rockowitz. Its modular module maintainer at the Big Blue House. Jacob how are you?

Jacob  1:04  
I'm okay. Thanks for having me back. Again, looking forward to this discussion, something I've definitely talked about in my own blog occasionally. Yeah, it's great to be back.

John  1:15  
Yes, and Jacob is the maintainer of the webform module, and now the schema.org blueprints module. So check. Check those out in your in your spare time. Joining us as usual, Nic Laflin, founder at enlightened development, Nic, how are you?

Nic  1:33  
Doing great looking forward to hearing more about headless and super where this discussion takes us.

John  1:41  
Fabulous before we dive into our primary topic, we have some words from our friends at Nerd Summit. Jen, tell us all about nerd Summit.

Jen  1:55  
Hi, my name is Jen. Are you a nerd? Yep, me too. And I want to make sure you know about nerd summit and inclusive community building three day tech conference being held March 17 through 19th 2023 at UMass Amherst in Amherst, Massachusetts. I work in software development, but I'm actually not a developer. And what I love about nerd Summit is the wide variety of professions and experience levels that are represented. Nerd summits Friday and Saturday sessions will cover a wide variety of topics including accessibility, leadership and career goals, tech tools, Drupal, development, best practices, and much more. Our Friday keynote is the art of live coding. And Saturday's keynote is creativity under constraint and utilizes real life Legos. There's also a Friday evening party and Sunday is dedicated to even more trading sessions. Tickets are just $50 and include breakfast and lunch Friday and Saturday. Reduced price and free tickets are also available. Because it nerd summit.org To get your tickets and to sign up for our slack and newsletter. sponsorship opportunities are also still available for this year's conference. Check it out nerd Summit, and E rd S u m m i t.org. And see you there.

John  3:18  
Thanks, Jen. I appreciate that. And actually, you know what, interestingly enough, not myself, Nick and Steven will be at Nerd summit this year. So if you are a listener, and you are heading up to Western Mass for nerd Summit, be sure to say hi, we would love to love to chat.

Jacob  3:39  
Yeah. lemaise Well, I'm going to be not at Nerd summit because New Jersey camp, which is closer to me is happening the same weekend in Princeton. So if you're closer to that camp, that's a great camp to go to.

John  3:49  
There you go. You can everybody is everybody's getting back out again. So you can divide, divide and conquer. You can say hi to Jacob in New Jersey or Nic, Steven and myself in Western Mass. All right, before we jump into our primary topic, Martin, can you tell us about our module of the week?

Martin  4:15  
Thanks, John. I thought this week we would talk about the JSON API Search API module, which allows your headless Drupal site to also provide a search service. So it's module that was created in November of 2019. And the current version is eight point X Dash 1.0 Dash release candidate three, which came out in January, so just over a month ago, and that release added Drupal 10 readiness. It has 25 open bugs 12 or 25 open issues, 12 of which are bugs, and is currently in use by just over 700 sites. Now it's a module that is supported by Santaro and the current maintainer, J's toxic works for them. Have a module was originally created by Matt gleeman, who has been a host on this show a number of times already. So in terms of the way JSON API Search API works, it really provides or exposes, I guess you would say the search API as kind of a JSON API endpoint. So instead of using kind of a dedicated service, like Algolia, like many headless websites will do. It allows you to to use a custom route that can be used for sort of full text and filter queries. So that you can really create sort of, you know, the standard result or search results experience that you would you would be used to with sort of a more traditional or unified architecture in a Drupal website. Because it leverages Search API, you can use it with either like your local database, a solar or Elastic Search core. And really anything that search API has a connector for, also does have support for facets. And it's probably also worth mentioning that an alternative module you could look at is something called soul rest, which more or less uses Drupal as kind of a pass through directly to solar, to send queries, but obviously, that solution is is more specific to solar itself. So anyone have any thoughts about JSON API Search API?

Nic  6:27  
I've not used Wharton. Yeah, I've not used it myself. But I mean, search API is definitely one of the cornerstones of complex Drupal sites. So having the ability to kind of use use that with whatever back into Elasticsearch or solar or whatever, and kind of interact with this on the front end is, is super powerful, I think.

Jacob  6:49  
I could take a slightly different approach, because like you bring up Algolia, and I'm using Coveo, which is another search provider. And something that more modern search providers or services are doing is API's. And so this is proxying. Through to if you had an Algolia back end, conceptually, and by the way, I think the like, for example, a search API Algolia module has no front end, all it's there for is indexing data. And then the assumption is you're going to call their API's directly. And in both covalent algo, Lea from my experience, you'd benefit more calling them directly. You don't do the hop through, you get their full documentation, you get all their features, you might even get a slight performance gain, because you're not proxy. You're not proxying the request through Drupal. And the example would be they have load that like Algolia and Coveo have crazy load balanced servers that are more performant than most Drupal site. Sorry to say that, but they're probably poor performance that I've used,

John  7:49  
I've used, I've used Algolia on on a front end, actually on a Drupal front end, and like it was lightning fast. And the API was really, really great to use. So I think like, if you're using Algolia, like there, you know, I happen to be a Algolia fanboy. So I mean, like I'm a little bit partial, but I think we're like this module kind of fits in is where you have solar on your back end. And you're building a headless site, right. So there are a lot of people that are doing that their hosting provider is providing them with solar, it's built in, quote, unquote, built in, right? This makes that connection a lot easier. And, you know, it essentially allows you to be able to index the site and use use it similarly to Algolia. As far as like, Hey, we're going to have you know, components on the front end pulling that data and doing stuff with it. But

Jacob  8:50  
those the solar provide API's are that's where we're getting into this difference here. Like I assume it provides API's but not API. I mean, I'll call these like API first. I mean, their whole business is

John  9:00  
right, right. Yeah. So I mean, this would be like, Hey, we indexed it. And then now, like, this module is providing API's from Drupal to be able to use for the search front end. So like in that, in that case, like we're removing, like, you know, without Golia, like, you get Algolia indexing and then organizing and providing the API's and the functionality on top of that. So like, you know, I think algo LEA is replacing solar in this in this use case.

Jacob  9:28  
And one thing I will say that this module seems really good for us. A lot of times people do overkill on search, like you have a news page and you want to let people search news articles, and there's 1000 news articles. The the search is a keyword and that's it or a facet. And this puts that layer in front that makes it a lot simpler. Like once you implement it, doesn't it? You don't have to think about your back end anymore. You could just literally change from one index to another. And I I've worked at organizations that change their search index every few years it happens, you know, outside of Drupal upgrades It's just politics or, you know, right? Try this try that.

John  10:03  
This also removes a little bit of a barrier to, I think, right. So like, if you're thinking of moving from like a monolithic coupled solution to, to a headless solution, right, one of the factors you may be considering there is like, oh, we have the, you know, we're using solar, and we have it tuned and configured exactly how we need it to, like, how do we translate that to, you know, to our headless front end, and this, this kind of helps remove that barrier, right? Because you can, you can still index, you know, have solar index the way that it needs to, or Elastic Search or whatever, you know, whatever the search, search services, and then still be able to provide this through API, because I mean, that's like, that's the key here, right is like, hey, like that data needs to be available through an API. And like, we've already kind of harped on the fact that algo Lea provides that out of the box, but like, if you didn't have the ability to, you know, move to a service like Algolia, or didn't want to, because you know, you've spent the time you've invested in solar. Right. This is, I feel like this is probably making that jump a little bit easier for folks.

Martin  11:08  
I think the other thing maybe worth mentioning, too, is there's also added flexibility here, because search API has such a rich ecosystem of modules there as well, then, you know, there's there's lots of, you know, community provided modules, a couple of which we've actually talked about as module that week already, that that can be dropped into sort of, you know, give some more nuances in terms of how those search results are returned.

Nic  11:32  
That actually really raises another question for me, Martin, is this JSON API integration, work with like, one of the things that I do fairly often with Search API, when I'm exposing that to clients is or to end users rather, is create a view that searches a specific index or a specific facet? Does it work off of those as well? Like, if you create a view, does it give an endpoint for that view to hit on a particular page? Are you doing all that logic on the front end? Like if you want a particular search field to search just newsletters, like Jacob said, or news articles? Are you doing that all on the front end? With just kind of like, baskets, are you able to build that in Drupal and just request an endpoint?

Martin  12:17  
It's my understanding is that it has facet support. But I don't know that it really is specific to have you in the same way that, you know, traditional architecture would be. So it sounds like in that kind of a use case, you would probably have to do a little bit more of the work on your own in terms of how you get that query built.

Jacob  12:35  
Yeah, the readme has the most documentation and it's all index based. It's basically taking the index entity, the search API index entity, exposing it through the JSON API, and then just allowing filters. And I think that makes sense. It's like keeping the scope of this module very focused and views you can expose views to API's, I don't necessarily think it's JSON API compatible. But you can just take a view and just add like a JSON, a JSON endpoint, to return datasets,

Nic  13:07  
which is probably how people were doing it before. But this gives more flexibility. Awesome.

John  13:13  
All right. Well, as always, Martin, thank you. And now on to our primary topic, which Martin is staying to join us for. And as he is, he is our he has our expert. So you know, Mark Martin, we're really putting the show on Martin's back here. So we are talking about headless factor fiction. And this topic is actually based on a blog post that Martin wrote a couple of weeks ago. So I was wondering, Martin, if you could start off by kind of giving us an overview of what the blog post was about and what we're kind of going to talk about today.

Martin  13:53  
Yeah, absolutely. So I would say the, the inspiration for the blog post really came out of a number of conversations I was having. So as part of the Acquia pre sales team, you know, I talked to lots of different folks who are either, you know, already bought into Drupal and looking for the best place to host it, or potentially looking at changing their CMS and trying to decide between Drupal and competing technologies. And so, have had a number of conversations where people have basically said from the outset that it's going to be headless, which is definitely fine. You know, Drupal has great support for headless. But one of the, you know, foundational books in sort of the pre sales field is called Start With Why right, so you really understand, what's the reasoning behind certain decisions, particularly if, you know, from a technology standpoint, you know, some of those things have already been been decided understanding the motivation that drove that decision is going to make for a better conversation in terms of you know, how you can meet their needs. And one of the justifications that I had heard for people again and again in terms of why they wanted to go headless was because they were so written that their site would be faster if it was on a headless architecture. And, and I've definitely, you know, seen compelling demonstrations of, of headless sites that are lightning fast. But at the same time, I also know that, you know, traditional or coupled, or as I like to say unified Drupal sites can also be very fast and have built sites that are even hosted on relatively modest hardware where people have said, you know, you know, what's the secret sauce there? Because it seems like that that site loads almost instantly. So I decided to just sort of, from more of a technical level, try and unpack that a little bit in terms of seeing, you know, those claims around headless sites being faster, you know, is there is there any evidence to sort of, you know, prove or disprove that. And also, you know, if there is even an advantage to to headless sites, from a performance standpoint, you know, how much of a potential benefit are we talking about? And so, one of the things that I looked at is using the core web vitals, so there was there was an episode of this show, a few episodes back where we talked about core web vitals and why that's important. But one of the key considerations that that informs that is really around performance. And Google has really great reporting around core web vitals, you can just go in, put in Drupal, you can compare it to things like Contentful, or content stack, or you can also compare it to things like, you know, next Jas and Gatsby, and actually, Drupal performs pretty favorably to all of those. And so you know, given that all of those technologies are really specific to headless, and Drupal, according to Google's reporting performs better than they do. All the I think the main argument that I was trying to make by showing that is really just that having a headless site doesn't guarantee that it will be faster, you can definitely build fast sites using headless technologies. And there are lots of great examples of those around. But there are also some examples of headless sites that are not fast, and probably for a lot of the same reasons why some Drupal sites end up not being fast. So you know, from a, from a technology standpoint, I was I was just trying to sort of probe that idea of is one approach inherently, more likely to give you a fast site than the other?

Nic  17:24  
I was curious, what version? Do you know what version of Drupal that these statistics were based on? I mean, within Drupal seven, Drupal nine, or just Drupal period,

Martin  17:35  
I would assume that they're just a blend of whatever version of Drupal sites on the internet are running. I mean, one of the things that to be honest, occurred to me, as I was thinking about that reporting is that I would think a lot of headless sites that are using Contentful, or content stack as a back end CMS are probably statically rendered, at which point, I'm not sure if Google would even be able to tell that. And so the fact that those show up in there may indicate that those are sites that are more doing like client side rendering, which is inherently less likely to be as fast as if it was like statically generated so. So the fact that those even show up may also be a bit of an indication of the approach taken on those. But again, I think that underscores the point that even in the headless world, you know, sort of the skill and expertise of the team doing the implementation really does matter.

Nic  18:26  
So you talked a little bit about the motivation already, but what what specifically motivated you to actually write an article about it and look at the numbers so to speak.

Martin  18:38  
So I think when I started, I wasn't necessarily writing an article, I was just sort of collecting some thoughts that had been bouncing around in my head as I was having some of these different conversations. And then, as I started to find some things like the core wave vitals reporting, that that seemed like it lined up and, and sort of structured these things out in a in a fairly, I don't know, linear but but to tell a story in a way. I actually shared it with a few folks that I know and, and it seemed like there was some, some good response, it seemed like people thought it was worth sharing the community. To be honest, I was a little worried at first that it might be a bit of a of a third rail, because I know there's so much excitement around headless and I didn't necessarily want to, to deflate any of that excitement, but but just to make sure that it's kind of an honest conversation. We're using these technologies, where they're the most appropriate and for the right reasons. Interesting.

Jacob  19:33  
So I think the question now starts, we have strategies, where do you think headless makes sense? Like there are use cases where people are using it, and we can assume that they've, they've actually done their due diligence to make that decision?

Martin  19:51  
Yeah, great question. So I think certainly a very comprehensive take on that question is over resource you can find in I think, was a Dreis blog post from 2019, where he really has sort of a conceptual model in terms of, of how to work through that decision of whether whether a headless approach is appropriate. And also, you know, on the spectrum of choices around decoupling Drupal, you know, which is the most appropriate one. So, you know, anything from, you know, a fully coupled site, where it's Drupal is both the front end back end, fully decoupled and or approach where Drupal is sort of dynamically serving out content through API's having statically generated as as one of the points in that continuum and also progressively decoupled, which is really something closer to a couple of Drupal site, but having headless components within it. So lots of different approaches there and, and providing some, some thought points in terms of, of how to decide which of the approaches again, within that sort of overall continuum is going to be the most appropriate for any project. So I thought that was a really good resource, and there'll be a link in the show notes for anyone who wants to sort of go back and read that. But, you know, for the sake of the conversation today, we could we could talk about maybe some use cases, where I think, a headless approach is, is going to be a really good fit. So you know, anytime a site needs to show real time information, so you can think like live sports, sports scores, or I know, there are sort of, you know, mass transit systems that use Drupal, and have kind of those, those headless API's as a way of, of sharing those things out in a way that makes it very performant, those are definitely excellent use cases. Anything that has to have a very dynamic or application like experience is definitely going to be a good fit for for some form of of headless. But again, you know, even something like the progressively decoupled or hybrid architecture sometimes can achieve some of those. Another really good use case for headless sometimes is if you need to have kind of one CMS that's going to manage content across a variety of different front end sites. So you can definitely do that with things like, you know, multisite paired with, let's say, you know, context, or I think there's a module called domain that can do some of these kinds of things. But headless is actually a pretty good fit for for those kinds of, of applications as well. I do think that having good front end expertise is is also part of that consideration. So if, if your team is really more sort of, you know, marketers with a little bit of site building understanding, then then pushing them into the headless pool is a bit of a like, you know, shove into the deep end and hoping that they can, you know, muddle their way through and in some cases, particularly, things around the content architecture and being able to adapt that over time. Another big advantage of going headless is if if the, the organization doing the implementation has kind of, you know, front end and back end teams that are really dedicated, then there's, I would say, typically a lower level of coordination that needs to happen between those teams, they can sort of agree on, you know, how the API's need to be structured, and then each kind of go off and do their own work independently. So that's, that's definitely a strength of the headless approach. And then also, I think, if you've got us, you know, or an organization that has a website, where they know that they're going to constantly be sort of evolving that front end, they want to be a little bit more bleeding edge in terms of, you know, overhauling it every six months to take advantage of everything that's sort of new and the most exciting. Having that decoupled approach means that, you know, they have to do the minimal amount of work to the back end to accommodate front end changes that they know they're going to be making on a more aggressive basis. Yeah,

Nic  23:48  
I think it also depends the which flavor of headless you're going to write you me because they're static. Then there's also things like React or Vue js where they're, they're headless. But there's still a lot more interactive than just kind of a static site generator type thing. But yeah, I think that last one is one is a good use case that people sometimes forget about. If you're going to be chained. If you don't want to migrate your data every time you want to change the front end, then having a strong API in the back end that you just have to integrate with allows you to change that. I think another one too is that sometimes is under consider, I don't know if that's the way to put it is appreciated, maybe underappreciated is security. I think sometimes it's easier to make a headless site more secure, because you can lock down kind of the Drupal side of things a little bit more. Since you're just interacting with it on the on an API side but that's not to say that, you know, front end architectures and frameworks don't have their own security concerns, but especially if you're on the static side and it's a lot easier to make that secure.

John  25:03  
It's interesting. Josh Coney from Pantheon, co founder and chief strategy officer, Pantheon has been posting kind of some blog posts about headless and one of them is escaping the website relaunch. And you know, I think you just kind of touched on that a little bit, as far as, you know, headless, possibly being a solution to kind of escape that, that relaunch replatform. kind of cycle where, like, you know, and I think overall, like for the web is probably a whole nother show topic. But I think overall, for the web, like we're moving away from that, like, every three years, I have to relaunch my website, where in reality now that Drupal has a stable upgrade path, like it's more like, every three years, like, I just really need to like repaint my website with different colors, and maybe maybe make some architectural improvements, because we found that things are not working right. Well, also just

Jacob  26:02  
evolving it every I would say it's not every three years, you redo your websites every year, you're evolving different sections, especially on the Enterprise giant websites where they got 100,000 pages, you just can't redo it, you can't, it becomes impossible. So you're taking piece by piece, you're like we need to improve our search, we'll go Going back to our module, the week, you improve that, and that's recipe decoupling really makes that possible. Because you can gradually decouple pieces and gains that targeting

John  26:31  
agree agree with that 100%, you know, I'm working on a kind of a platform that's going to support a bunch of Drupal based platform, it's also headless. That's going to support you know, up to 100 sites, when it's all said and done. And like I the vision I have for that is that it evolves. And, you know, you in Crete, you you produce better features improve features, but you don't ever really have to, like, upgrade or do like, we're not going back to the days of like a six to eight, Drupal migration, right? Where you're like, Oh, it's a brand new site, we're gonna rebuild the whole thing. Like you're just you're just systematically improving.

Nic  27:07  
One of the place where it kind of makes sense to that I didn't, I apologize. I don't, I didn't hear you touch on Martin. But if you did, that is when you're pulling information from multiple pools. I mean, it kind of goes back to our episode last week with Valhalla, right? That's one way to go to, but if you're if your front end is pulling from Drupal, multiple Drupal sites, and, you know, maybe content Contentful, or something for the blog, and a bunch of other things, have this really make sense there. Now Drupal can integrate with those things. And I've done that. But a lot of big organizations will use one tool for one job, and use like a headless architecture to kind of pull everything together, themselves.

Martin  27:49  
So yeah, I think e commerce is is very common in that use case, you see more and more, you know, using Drupal as sort of the place where the marketing information around products is, is sort of stored and managed by the marketing team, but then everything transactional ties into the commerce back end, that is tied into like an ERP system. And those are really brought together in some flavor of a headless. So whether it's, you know, a Drupal unified site with, you know, decoupled components for the different commerce elements, or, you know, some flavor of of, you know, that headless integration, for sure.

John  28:25  
It's interesting, because Martin and I were both at Florida Drupal camp a couple weeks ago, and we were talking about this topic, because my talk in Florida Drupal camp was was about, you know, headless, and how you can you can build an omni channel web platform using Drupal and headless technologies. And, you know, we both came to the conclusion, and I can, I'll let Martin speak for himself. But I think we both came to the conclusion that like, it's very situational, right? You have to you have to know what all the moving parts are, and whether it makes sense or it doesn't make sense to go down this path. One question I have, you know, we kind of talked about what, what kicked kicked off this whole, this whole thought drain for you. And I think you're very, you're very accurate in the fact that like, you can build a headless site poorly that doesn't perform well, you can build a Drupal site poorly that doesn't perform well, you can go in the opposite direction, right? You can build a headless site that performs very well you can build a Drupal coupled site that performs very well, right. It's very much about how it's built. Well, you know, what's happening under the hood and we've seen it we've seen Drupal, you know coupled Drupal sites be very performant and very fast with caching and all that stuff. I'm wondering if if it's possible Can you you know, apples to apples, you know, decoupled Drupal site to headless headless site Right. which one performs better? Like if all Things are equal right? Caching, structure everything. Can you get a Drupal site to perform as well as a headless site? Or can you get a Drupal site to perform better than a than a headless site in, you know, again, all things created equal?

Martin  30:20  
I'm tempted to dodge that question by saying, I don't think it'll ever be entirely apples to apples. I, I've definitely seen lots of Drupal sites that are very fast. And I have some have definitely seen some examples of headless sites that are very slow. And don't want to name names at this time, but

John  30:44  
we appreciate that. Well,

Martin  30:45  
I would say in general, I think a lot of the headless frameworks. So if you look at like a Gatsby, or index js, I think out of the box, they do some sophisticated things that for Drupal team would require a little bit of implementation. So you think about like converting things to web P, setting up your image styles, there are a number of things that I think maybe some of the the headless frameworks are potentially a bit more opinionated in terms of some of the things that they do out of the box, I do still think it's possible to over rely on like, you know, the amount of JavaScript frameworks or libraries that are being pulled in and some of those things, and I think that's where you see a lot of the headless sites sort of start to creep into an area where they're getting dinged for things like core web vitals is is, you know, either the amount of JavaScript being loaded, or even just the sort of execution time of running that when the page actually loads. So yeah, do you?

John  31:41  
So do you think you see in like, in a coupled solution, right, do you think you see increased load times specifically around like, the loading of other entities? Like if you were to do like, what we've been talking about search quite a bit, right, or, or E commerce, right, where you have a page that's kind of loading other entities like, is that typically where you think you see like a decrease in performance on the Drupal site as where, like, it's a lot, I wouldn't say easier, but it's perceivably faster to load that on a headless solution.

Martin  32:17  
So I do think that, you know, again, talking about what some of these, these headless frameworks will do out of the box, you know, they'll do things like prefetching, which on the Drupal site, you could use, like the quick link module to potentially do some of the same kinds of things. But even in terms of, of some of those more dynamic layers, and sort of having to load nested entities and some of those other things, Drupal, actually, you know, as an infrastructure, or, you know, like, if you think about any of the major hosting platforms for Drupal, they've all got all kinds of multiple layers of caching built in. So you know, it's either like, you know, Memcache, D, or Redis, probably varnish, some form of CDN. So a bunch of different pieces, where it's only a very narrow use case, where a user is, is typically going to really encounter the full latency of, you know, building out everything from sort of a raw database cache, most users are actually going to get something that's cached, you know, even at the CDN level, where their experience for that is going to be relatively the same as if that was, you know, serving a static rendered file in the same way.

Jacob  33:30  
Yeah, I want to echo that I just like, I think, like, you gotta sit back and just be like, what's the strategy for website it's caching, it's serving users the information they need and only what they need. And that's key to performance. And then you brought up this execution, which is a really inch. I think that's the nuance that people run into, is execution, like the perceived user experience, when you're doing a search or you're navigating, you're sliding through a carousel. And one thing I will say what I like about progressive decoupling is this notion that or even react being component driven, you can get into a component and give someone a user experience in that component. That's exactly what they're looking for. And that perceived performance is much greater, because you're not reloading every page. Like if, you know, they're just paging through content, and it's faster, it feels faster. And sometimes you could struggle to bring that into Drupal, even. Even the fact that like, react and next has like pre loading prefetching little all the little nuances built in that create a better I would like to say perceived user experience, like from a user's perspective.

Nic  34:34  
And perception is reality, right? So I think one of the things too, that people forget about a lot of these decoupled solutions, especially react in my experience is generally the way that people do people, developers, a lot of times this is a blanket statement, not meant to be a blanket statement, but it I'm going to say it a lot.

John  34:57  
You should have danger sirens that go off whenever Yeah, we sound

Jacob  35:03  
good as its developers?

Nic  35:05  
Well, no. So I was gonna say is a lot of times with React, they really only worry about that second interaction, right? That first interaction is going to take forever, because you're downloading 25 megabytes of JavaScript to get the react on the page. But then and then it's downloading your 20 megabytes of prefetch data and stuff. But once that's done, well, everything is lightning fast, because it doesn't have to go back to the server. Right? And you know, I'm, I'm generalizing a lot, and I'm a bollock. But. But

John  35:36  
for the usual though, I don't I don't necessarily agree with that. But I'll let you finish your point. Yeah,

Nic  35:40  
but, but. But I think that that's something that's different between, you know, a, a PHP application versus a JavaScript framework, right? Many times, the perceived performance is faster, just after you've already loaded a lot of the stuff. Once you've done that, things are very quick. And then on a PHP application, you're loading it when you're going to a new page. Yeah, there's prefetching and stuff. But if you go to a completely random link or something, then you're it's gonna have to load that and you're gonna have to wait, whereas you don't get that flush with, with React, or Angular or whatever.

John  36:18  
You kind of you kind of straighten it out, I guess, I guess I can agree with that statement. Now. I was basically going to say that like, I think everybody from from a client standpoint, right, like developer aside, like, if if a page you have two pages side by side, and the React one takes 30 seconds to load, and the Drupal native one takes five seconds to load, the client is going to be like, Well, why does this one load so much faster than that one? Right. So I think you have to like, you have to figure that problem out. So I you know, I don't know that it's necessarily developers developing things as much as it's like, you know, that perceived, you know, speed, right. But, I mean, I guess based on what you said, right, you have the ability to kind of say, like, Hey, we're gonna load the first bits of content on the React side in five seconds, and the first bits of Drupal content in five seconds. And then background load both of those, right, it kind of, it kind of negates that, right.

Nic  37:15  
And I just want to call up before before I get the angry, oh, actually, I've never gotten angry letters from our listeners. But before the return. Now, I do know that react, you can load just what you need on the first page, you can, you can do some server side rendering and stuff out of the box. So a lot of times people just especially for more straightforward integrations, they just, they just load, react, and then just let it handle all this stuff as you go through the site.

Jacob  37:39  
But I we sat back and I just want to throw out there, I would never suggest that. Okay, so Drupal is for enterprise, I'm going to make that broad statement. And in the same way, I wouldn't tell someone to start building a site using PHP, I wouldn't necessarily say you start from react, you start from next Jas or Gatsby. And next, Jas is like investing huge in fixing that performance issue. It's crazy what they're doing, like, I'm trying to look up the name, but basically, they're rewriting webpack to be like, 15 times faster with better compression. So that that, like they're mitigating all that user experience issue, that latency and the SEO thing, which we haven't even talked about, because it doesn't exist anymore. But you have to be using a framework, if you were just like, I'm creating a React app, you're gonna get all these past hits that people talked about. But if use next Jas or Gatsby, they're solving these really, really complex problems, and I will, I hate to say it, but they're solving it at a much larger scale than Drupal ever could. Because lots of different people are using next Jas a lot more than Drupal. So they're taking into account they're solving in the millions of webs, the 10s of millions of websites, and Drupal is, you know, million, a few million websites out there. And JavaScript just has more developers. I mean, I just want to throw that more, they're more eyeballs looking at JavaScript these days.

John  38:57  
So I mean, I think we're, I think we're like, we're gonna keep coming back to the same, the same underlying theme here. If for our listeners, right? It's not so much. One is faster than the other like it very much. And somebody speak out if I'm, you know, I'm off base here. But like, it very much comes down to like, the, you know, how it's built. Right. And then the architectural decisions of whether it makes sense for you. And then I think Jacob just touched on something interesting. there as well, right is like, there's a lot of functionality coming from, you know, Jas frameworks, that's, that's, you know, improving things, right. So, so making making the experience better, but also, it the team dynamic kind of factors into this, like, you know, I'm seeing quite a few clients that are coming and saying, like, hey, we have react developers on our team. We don't have Drupal developers, like how are we going to, you know, how are we going to reconcile this we want to be able to use our existing team. Right? So, you know, I think that the team composition is an aspect there, too. I guess that's a long winded way of saying like, you know, at the end of the day factor fiction really comes down to like the situation you're trying to solve for, right?

Jacob  40:18  
Well just step back, it's more than team development, because I've talked to some large agencies. And they're just like, we want to do headless because it's easy to recruit JavaScript developers. I've heard people go so far to say that they see a team having a breakdown of a team of 10, front end JavaScript developers and three back end Drupal developers. And I think we just have to recognize Drupal is not that interesting. It's Php, it's old, it works.

John  40:42  
I think it's, it's okay.

Jacob  40:45  
I'm just I'm like, and it's hard to say that. But it's like, Drupal is shifting into becoming this very stable back end. I mean, if I was going to make my generalization about it, where we are trying to build something that's like, a future proof back. And once it's in your infrastructure, it does what it does really well. And as soon it doesn't break. Yeah, it's and I mean, I'll rant for a second and say, knock on wood for that one. Well, and I'll read say, I think Drupal is for content, like I keep, I might write a blog post, and that's the title of it. Because that if we own that, then we're like, oh, it serves content. And then everything else is, you know, nice things around it. And, and your front end, people can do amazing, incredible things, if we keep them great content.

John  41:29  
I agree. I agree with I agree with all of all of those points. And it one of the points I make in the talk that I delivered it in Florida Drupal camp is that like, I consider Drupal like the glue or a traffic cop for a lot of services and a lot of implementations, right? And it's really good at that, like, hey, Drupal can integrate with everything Drupal can can send data or receive data from anywhere, right. Awesome. Like, that's, that's definitely a great place for that. As far as the team thing goes, Jacob, I agree with you. I think like back when I was with we, you know, in agency life, smaller agency life, like, and we were building couple of sites, like our front end development time was so much more than our back end development time. It was ridiculous. Like every project, we're like, how can we decrease front end development time? And like, here comes Java scripts, like auto auto left field, like, Oh, hey, if you use a framework, like you could, you can go back to building websites the way you used to, and not have to use, you know, Twig templates and do all this other stuff. And not to say that that's bad, or that's wrong, you know, I think that there's a place for it, but like, it is a path to do every single cost, right. So I also wonder, and this is totally off topic. But you know, I also wonder like, at what point do we like go, oh, you know what, like, Let's ditch the twig theming layer. And let's just move to a Drupal JS framework for the front end where like, you just build the connections and people go and do you know, do what they want, how they want.

Nic  43:08  
I think we're a ways away from that happening. Okay, so shifting gears a bit. The module, the week this week had API in the title twice. And a lot of times we talk about API's, Drupal is great as an API hub, or in, you know, API's are for headless. But one of the questions that we had is our API is important from a Drupal perspective, even if you aren't going headless?

Martin  43:36  
I'd have to say, Absolutely, I mean, I think one of the things that makes Drupal so flexible is is really its rich set of API's. I mean, oftentimes, when I'm talking to developers who are maybe a bit skeptical about Drupal and and its capabilities, even just showing the API documentation page that lists out such a rich set of API's that allow Drupal to to really be molded to some very specific use cases, I think, is incredibly powerful, and also makes Drupal really flexible in terms of being kind of that omni channel solution that can feed your content out to, you know, digital signage and mobile apps and lots of different applications. It's not sort of, you know, strictly just useful for web apps by any means.

Jacob  44:24  
Can I can I echo something, really, I built a couple of sites. And I didn't turn on the API's. And then when I turned on the API's, I had a mess. Because my field structure, the data structures were just not clean. And I strongly advocate even if someone's not going headless, they have no like, no one even needs the API's. But they know somewhere down the line, someone might want their data, meaning their websites on the web that says, It seems like that's an inevitable thing, because Google wants your data they're gonna want at some point, Google's gonna be like, do you have an API? And I think turning on JSON API from day One, even if it's not publicly available, just to review as you build out content types in your data structures, make sense is huge. Because also, the other mistake is you want to like I made the mistake with JSON API or any API, you only want to expose the data you think someone's going to need. So it's well structured and you never change it. And one of the problems this is a core issue is you turn on JSON API exposes everything. And even by turning that on, you start start thinking a little more about, well, what what is our content? Because you don't actually I would throw out there. I don't know if you need to expose image styles, or that's not something I would worry about immediately down the line. If you're going decoupled, you need image styles. But you do want to look at what's our blog post? What's our fields? Are we using taxonomy? Does this make sense? And turning on API documentation? I mean, I'll also one other thing is, that inevitably makes the point when you turn on API documentation for a content type of like, oh, kind of makes sense of good field names and descriptions for everything. Like it just encourages people to think that way. Because they, they're, they're reading, what's the expectation, the data structure? I think it helps future proof your site, even if you're not ready to decouple for five years from now, your, your team's thinking about it.

John  46:14  
And I think like, like I said, Right, I agree. I agree with Martin here, like API's are important, even if you're not going headless, right, because like, as I said earlier, like Drupal playing the glue or the traffic cop in this scenario, like, not only do you need API's in but in some cases you need API's out like, you know, a lot of a lot of folks like to integrate with like Salesforce, for example. So like, if you're taking data, and you want to be able to send that back out to Salesforce in some way, way, shape, or form. So, you know, I definitely think the API's are important.

Jacob  46:50  
So, Martin, it's, you know, we're talking about headless API's, but like, and we've mentioned, progressive decoupling, but, you know, how would you describe progressive decoupling works in the real world? And is it easy to a good sound approach for someone to do? Or are you add, I mean, one way to put it is, if you have a couple type Newstar, progressively decoupling Are you adding layers of complexity be one thing that comes to mind?

Martin  47:15  
So I would say, a progressively decoupled Drupal site, the way I've seen it implemented the most often is really sort of having that unified architecture, Drupal is the front end back end, but then embedding within it, some kind of headless components. So whether it's using something like the components module, or you know, some other strategy to basically make those available, could be as blocks, or as, you know, paragraphs, whatever the the sort of layout system is giving content editors the ability to sort of use some of those elements that are either pulling data from Drupal through one of those API's, or maybe even from a completely other data store. So any commerce framework, you know, some other content platform, those kinds of things, is it is that making it more complex, it typically would be making it more complex, but I think it potentially also gives you maybe some of the benefits of both approaches, right. So you get the ability to have more interactive elements where they're needed. But at the same time, you can still have some of the flexibility of using Drupal as the combined sort of, you know, back end and front end. So I think there are still some advantages for particular use cases of having Drupal as as both the front and back end. And so being able to sort of, you know, pick and choose where you want it decoupled. And where you don't is is it can be beneficial for forts, definitely some teams are the the other form of progressive decoupling that has been talked about on this show is actually actually having sections of the site that are fully headless, and some that are sort of, you know, fully unified. And so that's one that I've not seen as often, but is is definitely an interesting approach. And, you know, it sounds like some of the organizations that have gone down that path have had some success with it.

John  49:07  
Yeah, I actually, actually, when we were talking about Algolia, that's where I we actually progressively decoupled Drupal site was like, we had a few search functionality features on a site and those were all coming from Algolia directly on the front end. And it worked. I mean, it worked really well, you know, we we dropped those components into Drupal blocks and, and, you know, place them where we needed to. So it worked. It worked really well in that regard. And I know bounteous actually, I think went through a progressive progressive decoupling exercise. And they have a couple of blog posts about that as well.

Nic  49:47  
One of the other advantages about it is it allows you to be a bit more agile about a project or an upgrade as well. Were split it split it up over a few things. So for example, if you Have a really complex enterprise site that's been built over years and years and years, rebuilding that whole thing. And from scratch, whether it's decoupled or not, might take 234 years. But if you progressively decouple it or progressively rebuild it, you can say like, we're doing the blog now. Right? We're doing the, the user management. Next, we're doing this next we're doing the E commerce next. And if you have a big enough team, or multiple agencies, you can just say, like, Hey, your responsibility is the blog and your responsibility is the cart, right? And you can allow different teams to work on it and have a common goal.

Jacob  50:43  
I could, I have some experience, it's slowly happening with this. And the challenge is relationships between content, it like that becomes this, like you have these different pieces that moves slightly differently. And I think it's solvable. But it that's the big challenge when you start breaking the site into these pieces. And suddenly it moves to, you know, it's going one parts going through next, Jas, but you want it to have an entity reference to something on a page in Drupal, and you're tracking that. Or, I mean, even having two sites and sharing content between is a tricky thing, what what's great is Drupal has so many solutions to these problems, like something that is people don't even know this about the Migrate module, but you can do Drupal to Drupal migrations. And I want to be clear, not Drupal six to seven or to eight, but like you have a Drupal 10 site, that's an old architecture, and you're building a new architecture. And you can migrate content back and forth between them using the Migrate module with ease. I mean, the data structures are so similar, that that's an easy migration, you're not doing a lot of custom data massaging but you're able to restructure things and clean them up or convert data entity, you know, convert your images to media, by the way, I have one of those sites, we didn't use media didn't exist. Now we have to use it. That's a huge lift, I can't, it's overwhelming to convert, you know, 10s of 1000s of images to media and create a good user experience. So absolutely.

John  52:05  
So we've kind of we've talked, we talked about performance, right? And like, you know, the performance gains benefits, and how we can kind of neutralize, neutralize that across. But Martin, I'm wondering, in your mind, where does it doesn't it make sense to use headless? Like, where would you say like headless is, is kind of a dumb, a dumb solution, in this regard.

Martin  52:31  
So the analogy I think about sometimes is, you know, gas powered cars versus electric vehicles. So for a long time, electric vehicles were only small, and they had limited range. And so it's very easy to say that it was like only a good solution for people who lived close to the city center and had to make short trips. And you know, could afford to buy this more expensive vehicle and so on. And then, you know, somebody had the idea to make an electric vehicle as sort of the high end luxury vehicle, which sort of, you know, changed the thinking around electric vehicles, and now we see them being more and more commonplace. And so it's a technology that those places where it doesn't make sense, are becoming fewer and fewer. And I feel like headless is sort of the same kind of a thing that we're probably initially a lot of places where, you know, you wouldn't want to use a headless site, if the menu is going to change frequently, because you know, it used to be that that headless to go headless, meant that all of that was managed in a static file. And so you'd have to have a front end Dev, you know, update the the menu file every time somebody wanted to add a page into the navigation structure, where as a lot of that is becoming more dynamic. And so you start to see the same thing around, you know, translation, we talked about search earlier. And so I think that the footprint of places where headless doesn't make sense is getting smaller and smaller every day. And so it really becomes more around some of the other considerations that we've talked about. I think, you know, based on my own experience of working with a headless site late last year, one of the things that I saw is updating the content architecture in headless site definitely requires a level of programming in terms of, you know, creating templates, and some of those other things. Whereas in Drupal, you can like, create a content type and add different fields and switch between formatters and then use layout builder to sort of define how those things are going to be structured. And maybe it's not going to have the level of finesse as if you actually had a dedicated front end go in and make everything look clean and polished. But but you can build that out pretty easily with just, you know, sort of basic site level expertise. So I feel like if you've got a content architecture that needs to evolve, and maybe it's just a site builder going in, who doesn't have a lot of, you know, JavaScript or react experience, then that's maybe a good use case for just sticking with sort of a traditional Drupal architecture. But as you know, the number of those use cases I think, grows shorter every day.

John  54:55  
Yeah, I was I was actually I was thinking that right like where you Have like that use case of like site site builder heavy kind of interaction, right? You're gonna, you know, you're going to rely on your theme in Drupal quite a bit to kind of make sure things look right look good and allow them to kind of go in and create new content types and do those sorts of things. But yeah, that's not easily achievable. I think in in a headless architecture, especially, we're adding content types or components. I think, like, you can build systems where headless could support something like that. But it's got to be more of a design system structured, you know, component library.

Jacob  55:42  
Well, I'll also just say like, if we're talking about Drupal, it's like if you have a team of three developers and your your government site, you have three developers, let's go that scenario government site, you're allowed to use Drupal, you have three developers on your team, you should stay coupled to Drupal. If you have three developers if you add, if you decouple, it gets so complex and hard to manage, it doesn't make sense. But then if you take that scenario outside, I use government because I know governments can be restricted to Drupal. If you're a small organization, you have three developers, and you're like I want to build and I want to be as progressive as possible. You probably should go headless. I hate to say this on the Drupal talking Drupal podcast, don't use Drupal. If you don't use Drupal as your back end, go to a SaaS provider, even aqueous dabbled in that have a cast service where your back end is just your back end. You're not managing configuring like Contentful, you get it, you turn it on, you got and the price gets ridic can get ridiculous. But your goal is to get you want to meet your client's needs. So you want to get a stable back end, and then have the front end go off and be as progressive as possible and keep evolving. And yeah, I see that even on small teams, you're you might be especially a new startup, you might want to start headless if you expect your organization to grow. Because also you could go with Contentful, USE IT spend the money, it hits a you know, then you start hitting a quarter million dollars a year and you're like, Okay, I'm going to go to Drupal and move the backend over. And that's easy, too. You know, if you built your content on, not as easy but easier.

John  57:18  
Yeah, we're getting to the same place like the new title of the show is going to be headless? It depends. Yeah.

Nic  57:28  
We're coming to towards the end of the show. I'm curious what you think, Martin, do you think people have been putting too much faith in headless over the years? Or do you think? What do you think that people have this is finally starting to grow into what people are trying to throw at it?

Martin  57:44  
I mean, I think there are and have been for a while exciting aspects of the headless approach. And so I can definitely see why people would be excited to go that path. But I do think there have been cases where people kind of put the tactic ahead of the strategy to some degree in terms of sort of deciding that that's the route they wanted to go down, because they were excited about it without necessarily considering if a particular project was was always a good fit. And there may be a degree of sort of, you know, the saying of when your only tool is a hammer, every problem looks like a nail. I mean, I definitely have been guilty of that on the Drupal side of just sort of wanting to build things in Drupal, because to me, it's it's easy to spin up a Drupal site and solve certain things that it would take me longer to figure out even though, you know, some other solution for, you know, an arbitrary team that didn't necessarily have significant expertise in one area, or the other might find easier or better suited to that particular task. So to some degree, it's probably also who you're talking to, and and their understanding of how easy it is to adapt a certain technology to a set of problems. So that's probably a long winded way of saying there probably have been cases where people have gone to headless where, at the time, it was maybe still had some some rough corners in terms of of that being the the technology to implement. But, you know, I think as we've said it, it gets better and better in terms of meeting a broader range of of use cases every day.

Nic  59:22  
I also want to point out one thing that I think there's an advantage to being an early adopter, on some of us, too, that we haven't we haven't mentioned, and that's why I think there's two, one is publicity. Right? Sometimes Sometimes it's nice to be able to say, hey, we're one of the first organizations to use Gatsby. When either as an agency or as, you know, the end client, right. The other thing is, if you adopt a technology early, you can build expertise in that and you can, if it's an especially if it's an open source technology, you can help influence how it matures in grows, right? If that's something that's important to long term.

Jacob  1:00:05  
So Nick, you avoided one that we haven't talked about, maybe we have, but cost, I have seen some very large organizations that have these massive Drupal sites like you know, 150 Drupal sites. And they're paying for hosting for all the, you know, the Drupal has got a lot of infrastructure to serve pages, and they've gone headless, and they see the costs go down really fast, like on that scale, the savings is huge, not a small sites, 200 sites. And if they're literally reducing the cost by 50%, we're talking millions of dollars of savings. And simplicity, like I've seen, and I won't name names, but it's like a pharmaceutical site where they also just, their sites are static, they just need the security of write the content, the drug comes out, hit publish, boom site, hosted for, you know, a few $100 a month and not $10,000, you know, a month or whatever price it is. And there's, I've seen that gain a lot like that scale. That's the argument I've seen when they go headless is called Yeah,

Nic  1:01:07  
that's a great point. And especially if you if you go static with a lot of this stuff, where you have Drupal, kind of the back end, like you can have a much more underpowered Drupal site, if it's just content editors, and then the static server you can throw, especially if you throw something like varnish in front of it or on Netlify. Like, yeah, it's just, it's dirt cheap to serve that kind of stuff. Absolutely, it's good point.

Jacob  1:01:31  
So I can help us wrap up because I had this question. I was gonna ask you, Martin directly, but I think we've all batted it around. So for all of us, it's like, where do we see the overall Future of Content Management Systems, I'm calling a content management system, because that's the broad term of a Drupal, headless how we're going to manage our build our websites, I think the proper term to lie which reason is to build our experiences that we're creating on the web, because it's not about websites anymore. It's and Drupal is trying to fit into that not it's not a CMS, but I think that helps marketers see about good old term. So Nick, yeah,

Nic  1:02:06  
I'll jump I'll jump in first. I mean, I don't think triple is going anywhere, right. I mean, I've, if it does, I'll be very sad. But I think that a couple of things that CMS is doing, especially with Drupal, that are more painful, in a React World are things like that the actual content entry, like that whole system has to be, that whole system has to be built up if you're, if you're purely a React site. The the database. Database is a database certification of the content, right? Normalizing Oh, that's a react by default uses like MongoDB, which is a no SQL, like normalizing that getting the data clean, like you end up having to you have to do a little bit of this if even if using Drupal as a back end, but especially if you're using Mongo, or Dynamo DB has your back end, like every time you call the data, you have to be like, Well, does this data actually exist? Is it in the right format, is it because you can put whatever you want into it, like, and that's something that Drupal like sanitizing the data, make sure and making sure it's valid, that kind of stuff, Drupal does great out of the box. The other thing that triple does, that is difficult in those situations, translation, user management, role management, all that kind of stuff. Drupal kind of just we take we sometimes take for granted. And it's I've built those systems before, it is difficult, it is painful, like, especially when you're getting to like the granularity of the permissions that many times we we get richer, but like you can you can give people not just crud permit level permissions for content, but ownership crud level permissions. Or with a few modules, you can say like this person can edit this field, but not this field, other collaboration, those kinds of things are difficult and not difficult. Maybe not difficult, but take, take a lot of time. If you're going to do them correctly in a headless situation, and Drupal excels at that kind of stuff. So I don't think it's going anywhere.

Jacob  1:04:27  
I'll go next because I mean, what I want to summarize what you said and kind of echo like, I think content authoring is going to be one of the biggest things people are going to double down on because that's what is important. If we want to create rich user experience we have to have good content and make it easy for someone to author it. Even omni channel like I always been thrown off like when you're a Drupal site admin you're authoring content to think of it displayed on a page but rarely do you think of how it will be displayed on voice or read out loud on Alexa and how we get those previews working and then get I hadn't thought about when you bring up premiere. ations workflow roles, that's all content administration. And those two sides, I think Drupal is going to keep excelling and focusing on that we're gonna have to double down on the authoring experience and improve it even more. I do think Drupal has got the best authoring experience in the CMS market because of the flexibility. Because you can't it's not one size fits all for building relationships. It just depends on the scale. And Drupal offers four different ways to be like, Oh, here's related people, here's inline entity references to people, here's paragraphs, if you really want to do it that like there's just so many different ways to provide an experience. I see that as a very important thing. And the only other thing that I've hinted at is I really see, CMS is needing to become ridiculously stable on the back end, as like future proofed, you're going to build a CMS back end, and that's it, your organization's gonna stay on it. And they're just going to evolve the architecture and never read it, either. Maybe they reply for that would be they would never do an upgrade, it would be about a strategy to keep it evolving. So that there's my add on.

Martin  1:06:05  
I can go next. Gen. Mine,

Jacob  1:06:08  
do you want to do the wrap up?

Martin  1:06:11  
Sure. For last saw I don't know about that. But if you look at the the analysts like Gartner or Forrester, they've actually dropped web CMS as a category that they analyze, because according to them, it's basically become a commodity. So you think about, you know, used to be that it was sort of, you know, Drupal and WordPress and cloning a couple of these other ones. But now with sort of, you know, the the wicks and the Squarespace is and a variety of other sort of, you know, SAS and CAS type options, there really is a lot more in terms of, you know, just options available. And so I think it's interesting that, that Drupal, I feel like is is coming back in a way to, to sort of how it used to be a bit more when when I started using Drupal, where a lot of the modules were not so much around being kind of like developer toolkits as really being more sort of full fledged solutions. So it used to be that there was like a job search module that was the whole job system. And it was, you know, had a bunch of sort of functionality basically baked into it. And so as a site owner, if you needed that you install this module, and it was basically ready to go. And I feel like, like recipes is moving, that moving us back in that direction. I think even things like schema.org blueprints, makes it easier for people to sort of add these sort of sections to their website without sort of having to have as much Drupal expertise. So I'm hopeful that that by making it easier for site owners, you think about project browser now to you know, add some of these things as a solution go into the UI, they can can quickly build out their website and have something that's more than just, you know, going through and configuring sort of individually piece by piece, you can really sort of rough out potentially a fairly robust application in a short amount of time without having to have a lot of technical expertise. And so I think that's that's definitely an area that that I find exciting about the the direction Drupal is moving in right now.

John  1:08:16  
Yeah, so I mean, I think you all have hit on the benefits and and it technically I agree with everything. I agree with everybody. I will say that we've been highlighting it throughout the show. And one thing that I want to add is that, you know, you can you can choose as j as Jacob said, you can choose their, you know, SAS solutions out there. Contentful Squarespace, as we've been highlighting through the show, you know, there are It depends what problem you're trying to solve, what solution is going to work best for you? I think where Drupal excels above a lot of these solutions, and to be quite frank Jacobs said it earlier, you know, where Drupal helps industry helps, you know, corporations and is the, you know, what can be considered a corporate CMS is this flexibility, you know, every client that I've ever worked with, has especially, you know, if a marketing team is involved, or you know, a site owner is involved or multiple, you know, brands or units are involved. Flexibility has been a huge, you know, a huge factor in their decision making process. Right. And I think Drupal has the most amount of flexibility because as we all know, you know, we can do anything with Drupal. I like to tell our clients like we can do anything with Drupal with enough time and money. Right. And I think overall, you know, I don't know specific cost structures or some of the SAS solutions, but I think you know, they get you pretty close to What you need, right? But they're not as flexible in content architecture, content modeling, right? They're not as flexible in the ability to pull a module off the shelf and have an integration or a feature, ready ready to use, or the customizations because, again, when you think of your corporate entities, they still have legacy systems, they have to integrate, they still have specific internal systems that they have to, they have to integrate with. So, you know, I think overall, when you're looking at, you know, when, when you're looking at Drupal, it may not necessarily be the cheapest option up front, right. But I think in the long term, especially going back to that model of not having to do major upgrades every year now being able to feature enhance, and to improve as you go, right? You're looking at a much cheaper, much cheaper, year over year solution, a much more flexible year over year solution. And really, you know, the solution that's probably going to support your organization for for the long term. So, yes, I agree with all of you. And, you know, I think that, you know, clearly I'm a Drupal fanboy. So maybe, maybe my opinion is a little bit biased, but based on what I've seen, you know, I think that the flexibility, and the customization is, is key and what people are really looking for, because the second you go to a SASS option, and that's option doesn't do that one thing that the marketing team needs it to do, or that one thing that a C level employee needs it to do, like that solution is dead to them. That solution is is not not solving the problem, right?

Nic  1:11:41  
In this in the cost scaling to know thing like, yeah, many times, like, it's, it's kind of twofold to like, a lot of these test solutions is like per user. So if you have a large organization that has 500 users that need to be able to edit content. Well, I mean, yeah, there's gonna be added cost to Drupal too, because you have 500, people editing content, you need bigger servers, right? Than you do if you have five editors. But yeah, it's not going to be it's not going to be 50 bucks a month per user, right? And same thing for a lot of these tasks. Companies will charge you by traffic, right? And if you have a bump in traffic, it's like, well, now our bill just went up by $50,000 this month, whereas Drupal can have traffic goes up, you might need bigger servers. But that scale is, you know, even if you're adding a couple of I don't know,

John  1:12:29  
I think triples caching layer and the ability to add something like Cloudflare in front of it can help with that. But I feel like our next our next factor fiction show is going to be SAS factor

Jacob  1:12:39  
fiction. It's I think we just start with raw, like Drupal is a real for enterprise stuff, it's really good thing to have in your infrastructure. It's like, it just if you expect to be building sites that are large, to have this in your toolbox, and you what, Martin, I think the whole question is deciding the right way to use it. It's a tool, it's not a hammer, it's, well, it's a set of tools, and you got to figure out the right way to use it in your infrastructure and evolve it. I also think one thing we didn't say is like you should use it, maybe not go headless. But keep thinking about it. Keep monitoring, every project you get you have to almost assess with this benefit from a React front end.

John  1:13:22  
Yeah, I mean, I go back to I go back to it's the glue or the traffic cop in a lot of in a lot of organizations, right? Like you can, you can it's it's the Swiss Army knife of, you know, back ends, if you will. Martin as always, it was a pleasure having you and it was a very insightful and enlightening conversation. So thank you for joining us. Glad to be here.

Nic  1:13:48  
Do you have questions or feedback you can reach out to talking to people on Twitter with the handle talking Drupal or by email the show at talking drupal.com You can also connect with our hosts and other listeners on the Drupal slack in the talking triple channel. And if you have suggestions for guests or topics we take those to heart as well.

John  1:14:08  
Just like nerd summit did today, you can promote your Drupal community event. On talking Drupal. Learn more at talking drupal.com/tdpromo.

Nic  1:14:19  
You can get the tangible newsletter for show news, upcoming Drupal, cancel local meetups and much more by signing up for the newsletter at talking drupal.com/newsletter

John  1:14:30  
And thank YOU patrons for supporting talking Drupal, your support is greatly appreciated. You can learn more about becoming a patron at talking drupal.com and choosing the become a patron button in the sidebar. All right, as we bring this show in for a landing, Martin if folks wanted to reach out to you to debate headless or talk about many of the modules that you have or anything else for that matter. How would they go about doing that?

Martin  1:14:57  
So they can find me on all the major socials channels as mandclu. Or they can read blog posts like the one that inspired our discussion today at mandclu.com.

John  1:15:08  
And we will have a link to that blog post in the show notes. For easy, easy clicking. Jacob, thank you for joining us for the second week. If folks wanted to contact you, how could they go about doing that?

Jacob  1:15:21  
I think it's very similar to Martin that you can reach me at jrockowitz.com and Twitter and on Drupal, Slack and drupal.org. All using the same handle.

John  1:15:33  
And Nick, what about you

Nic  1:15:35  
can find me online pretty much everywhere nicxvan.

John  1:15:40  
And I'm John Picozzi. You can find me on all the major social networks as well as drupal.org @johnpicozzi and you can find out about EPAM at epam@.com

Nic  1:15:51  
And if you've enjoyed listening, we've enjoyed talking. See you guys next week.

Transcribed by https://otter.ai

+