Talking Drupal #389 - Headless - Fact or Fiction
John: 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: Thanks. So it's a treat to be here. For those of you that don't John: 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: 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: 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: Doing great looking forward to hearing more about headless and super where this discussion takes us. John: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: which is probably how people were doing it before. But this gives more flexibility. Awesome. John: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: we appreciate that. Well, Martin: 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: 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: 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: 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: 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: You should have danger sirens that go off whenever Yeah, we sound Jacob: good as its developers? Nic: 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: for the usual though, I don't I don't necessarily agree with that. But I'll let you finish your point. Yeah,
Nic: 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: 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: 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: 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: 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: 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: I think it's, it's okay.
Jacob: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: Yeah, we're getting to the same place like the new title of the show is going to be headless? It depends. Yeah. Nic: 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: 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 t
2023-03-12 23:06
