Hybrid Decoupled

BRIAN:
Alright. I actually, I pinged Ron on Slack. My guess is that he submitted this but he's not at Mid Camp. We'll find out. But, so the topic here is hybrid decoupled. In the previous session, I did a lot of talking. So I will ideally try to, not do a ton of talking myself. But, maybe just as a way to kick it off. If, I don't know, what would be best? How about this? What if everybody, we just run around the room to start just to kind of break the ice a little bit. And everybody just introduce themselves briefly and explain, you know, either, you know, why they attended the session or what they're interested in talking about. I will just call on people going down the participants list. Brian, I'm guessing that Brian is here for recording purposes. I think that's what I learned last time. Unless that's not true, Brian.

KLEMENT:
It's, I mean, I've not been informed of this. It looks like this is being recorded right now. But I am, I haven't made a co host but I have not been, nothing's been communicated to me.

BRIAN:
It's fine. But, do you want to, are you participating? Do you want to introduce yourself or?

KLEMENT:
Yeah, absolutely. Yeah. I'm Brian Klement. I work at the American Medical Association. And I have not done a hybrid decoupled or progressively decoupled website. Just one decoupled website with Drupal 8 back end and a (INAUDIBLE) front end. And then everything else has kind of been very traditional, monolithic Drupal. So kind of curious to learn a little bit more about this middle ground which seems like it probably would have served my project much better.

BRIAN:
Awesome, thanks. Thanks fellow Brian. How about Aaron?

AARON:
Sure. Hi, Aaron Grants. I work for Simborg Studio of Chicago, a small firm. I have yet to do a decoupled solution with Drupal and I'm curious to learn more.

BRIAN:
Awesome, thanks. Chris Greatens.

CHRIS:
Yeah. So I, I work for Bounteous. I am not a developer these days but I do spend a lot of time talking to clients, you know, and I've been involved in a number of different projects. I've never done a fully decoupled but a lot of partially decoupled and, partial to that solution so, (INAUDIBLE) here for.

BRIAN:
Cool. Let's see. I think I lost, I think the list might be shifting on me. But, David.

DAVID:
Hey Brian, can you hear me? I'm a developer at Georgia Tech and I have a lot of D seven sites but for new versions I'm making in 9. I think decoupled is the right way to go because the content editors already sort of appreciate the CMS. But, we'd like to make things spiffier with a front end and view, view JS. So I think that's really what headless or decoupled is going for. But, I'm interested to know what hybrid would mean. I guess maybe that's some of your front end is in the Drupal theme but some of your front end is in a JavaScript. I'm just not sure.

BRIAN:
Yes. I think we're going to have to come up with the answer to what hybrid means as a group. But, let's finish going around. Thank you. John, how about you?

JOHN:
Yeah. Hi, I'm John Stevens. I work with Denison University. I work on their Enterprise Apps team. Our portal, internal portal for the university, is built on Drupal 8 now. We had done a D seven to D eight migration. And in that process, I attempted to use view JS in portions of (INAUDIBLE) which I think is what hybrid is. Though, I'm also unclear of the definition. And since I had kind of done that by myself, I was just curious what other people were doing and how they were doing it and just, yeah. So that's why I'm here.

BRIAN:
Awesome. Thank you. Martin, how about you?

MARTIN:
Everyone. I work at Northern, which is formerly Digital Echidna. Here today because I worked on a Gatsby site. I worked one or two sort of progressively decoupled websites which is like having like react angular elements within Drupal site. And then I was listening to the talking Drupal podcast a week or two ago which I think was about this and it sounded really cool. So I was like, I think this would be an interesting session to see if there's any kind of new insights or what have you. So...

BRIAN:
That is cool. I was on that podcast. What do you know? Cool. I thought I could just follow the participants list but it's been shifting around. So did I miss anyone, other than me. Terry, yeah. Hi Terry.

TERRY:
Hi. Yeah, I have a small hosting company and there's some Drupal development and I've been kind of following. I haven't done a decoupled site. I've been following some of what's been going on with that. But I'm still not entirely clear on how it's supposed to work. And, I mean, the one thing that I got from recently was that, for instance, Web forms would stay in Drupal but a lot of the rest of the front end could be in Gatsby or I've actually been looking at node for some other stuff. So I'm thinking about that or maybe view. But, just interested to see what people are doing.

BRIAN:
Awesome, thanks. Yeah, and I am Brian Perry. I work at Bounteous with Chris. I have been interested in decoupled for a while and also always interested in component based approaches to front end. So that's how I've been kind of drawn to things like react. And even recently, Web components. I've done a handful of decoupled builds and most recently we rebuilt portions of the Bounteous sites in, I think something that would would fall into potentially this hybrid category. And that we had initially just a few pages that were statically rendered with Gatsby and then the rest of the site was still on Drupal. And I also attended this because Ron, I believe, maintains the component module which we used on that site as well. But, Ron's not here for me to tell him how much I like his module. Cool. I don't know. Certainly, open for this conversation to go wherever. But do we want to try to pin down what hybrid decoupled means to start? What do people think that means?

CHRIS:
I mean, I don't know. I'd kind of equate it to what I used to think it was like partially decoupled. It's not fully decoupled. It's not fully coupled. It's kind of some place in between, would be kind of how I would think of it.

BRIAN:
Yeah, I'm actually looking back at the little description that was in the spreadsheet. And it actually does say hybrid decoupled parentheses, a.k.a. progressively decoupled. So that clarifies a little bit. Are people familiar with the distinction between like fully decoupled and progressively decoupled? Sounds like some of us are, no? Anybody want to take a shot at what those two things mean to them?

JOHN:
So I could take a shot at the fully decoupled. So fully decoupled would be where you're, the site that is being served to users, the front end that they're receiving is hosted on, not your Drupal site. But the data for it is being served from the Drupal site. So basically, your front end site is going to your Drupal site for the data but it is by itself, right. It's fully decoupled in that sense. I think, right? Probably on a no JS platform or something.

BRIAN:
Yeah. I definitely say that that's right. And you get tons of flexibility on the front end. You can do whatever you want but you also potentially lose out on things that Drupal already did for you. You know, like, security related things, forms. So it's a trade off, yeah.

TERRY:
Well, one thing that I heard a while ago is that weather dotcom was a fully decoupled Drupal site. I don't know if that's entirely true but it's, that's kind of an interesting thing to me. The one thing I've never really understood is if that means that input is also decoupled. So, for instance, is editing the site also decoupled? That's, that's what I had. And for something like a site like that which is enormous and has an enormous amount of live data coming into it constantly, I can't imagine that that would be all done. That wouldn't be done manually on edit nodes. I mean, that would have to all be done programmatically I would assume.

BRIAN:
My understanding of weather dotcom is that it actually fell into the progressively decoupled category and was using the progressively decoupled blocks module. That was originally created for the weather dotcom project, I think. I mean, I wasn't involved or anything so I could be to be wrong. But, and then...

KLEMENT:
Yeah, I think it's right. I just shared a link. Oh, sorry Brian to interrupt. I did share a link. Acquia has kind of nice overview of different progressively decoupled Drupal approaches that was written a few years ago by Preston, so when he was still (INAUDIBLE) Acquia. And he's actually written a really great book, decoupled Drupal in general. But this does describe the weather dotcom example and a couple others, you know, kind of where they fall on the spectrum of like how much of the page load is controlled by Drupal versus how much of it is controlled by some JavaScript.

BRIAN:
Yeah, and typically, the content entry like this, the CMS part is handled by Drupal and is Drupal's, you know, traditional admin, you are in a decoupled Drupal project. If you were decoupling the front end and also handling content entry somewhere else, you know, at that point it might not even be Drupal anymore.

JOHN:
You might start to ask whether it's, like why even use your Drupal at that point. But...

BRIAN:
Yeah. So, oh, go ahead Chris.

CHRIS:
I wanted to say that, you know, there obviously are other CMSs that are, you know, built to be decoupled and even those, while the admin is decoupled, they typically provide the default front end to the (INAUDIBLE) experience. So you don't have to write it if you don't want to.

BRIAN:
Yeah. So as far as progressively decoupled, we've definitely talked about kind of some examples of that. Does anybody want to take a shot at, like actually defining like what progressively decoupled means to them? What progressively decoupled means to me. Or does everybody understand it well enough?

TERRY:
Well, I don't. I mean progressively sounds to me like it's going to become more and more decoupled as time goes on. And I don't assume that that's actually what it means. So I'm very unclear on the concept.

BRIAN:
Yeah, I'll take that one actually because that does get into to some of what I was jabbering about on that podcast recently. So progressively decoupled, at least the way I think of that. And the way that I think of that versus fully decoupled is basically what handles the initial page requests. So, for something that's fully decoupled, Drupal actually doesn't handle the page request on the front end. Your JavaScript framework node whatever handles that. For something that's progressively decoupled, Drupal handles the page request, the initial route. And then for some portion of the page, it hands it over to a JavaScript framework. It could handle that initial amount and essentially hand the whole page over to But it could also be a traditional Drupal page that has a couple of blocks that are handled by a JavaScript framework and use an API. And then what I've been thinking about lately is, it's kind of describing as like an iterative approach to decoupling. And so either of those approaches fully decoupled or progressively decoupled, at least from my experience, they tend to be kind of a big bang like overhaul of one's front end.

When people decouple a Drupal site, it's usually, you know, we've got our old Drupal site and now we're going to do this decoupled one, some variation on that. And what, on this most recent project for our company website, we experimented with trying to do exactly, Terry, what you described, where we started with a really small slice of our site and decoupled that. And then were over time, adding more and more decoupled content as it makes sense. So we actually, for the kind of initial launch of this project, we actually just took two pages that had like a drastically new design and build those out using Gatsby. But it still talk to Drupal API on the back end. And the entire rest of the site was still traditional Drupal. We updated some of the styles a little bit to match the look and feel the better. And we also did so that the header and footer that those were new. So we also syndicated the header and footer, the react components over to the Drupal side so they were used there. But still the vast majority of the content was all still just traditional Drupal.

And that, you know, that has had its challenges. But it also worked out pretty well. And that allowed us to prove that there was value in decoupling things, make sure that our content team wasn't going to murder us for doing this. And just that overall it made sense and that, you know, we were able to prove it out before we started introducing more decoupled content in the sections of the site.

TERRY:
So what, what parts of the site did you decouple? I mean, was it more of the static elements that you decoupled as opposed to the stuff that's always drawing from the database?

BRIAN:
Yeah, it was, the very first thing that we focused on, we had like two pretty substantially new designs that also had a lot of like animation and interactivity, things that would be nicely handled by a JavaScript framework. We ended up using react but we just decoupled those two pages and built those out using Gatsby. All of the data in, was still in the CMS in Drupal but the, those two pages ended up being statically rendered in advance. So the actual page request at the end of the day on the server, Drupal doesn't even bootstrap, doesn't get involved.

TERRY:
So, because I also host, is that, are you using varnish on the server or what? How are you doing that?

BRIAN:
Yeah, technically in this case we're hosting on Acquia. So, you know, it does use varnish but the way that we actually accomplished it is we, Gatsby by default builds to like a public directory, I think. And we just put that static public directory within the darkroom. And then set up a few HT access rules so that it knows what to serve.

TERRY:
So, but you did that with whole pages as opposed to portions of a page. So it's not like replacing blocks with, you know, like, I mean, you're talking about the header and the footer, kind of deal, I mean.

BRIAN:
Yeah, we did do that too. So the, we did two whole pages. And then the header in the footer in those new designs was different. It was like an updated version of the header and footer. So it would have been weird to have the existing Drupal pages have the old header and footer. So what we did for that, and this was definitely one that we just kind of figured out as we went along. But we exported the header and footer react components. We had like a separate Web pack set up to export those components. And we used actually the component module that I was talking about before that Ron maintains. And we use that to just integrate those two react components on the site. So it actually creates blocks that you can use in the standard blocks UI and place however you want. But those blocks just render those react components.

TERRY:
So, does the, does the react actually end up, does the actual, that actual JavaScript end up as just a library on the site or is it, it's just a reference to a library and in like your Twig template or something, right?

BRIAN:
Yeah. So what the, so the components that we build out they're, yeah, just JavaScript, JavaScript libraries. What the component module does is it use a YAMO file and you can define the library. So it automatically create the library for those JavaScript dependencies. But you can also define block configuration in there. So a simple example is for the header. We have some cases where it needs to have a light background and some cases where it needs to have a dark background. So we just added a block configuration where you can pick between the light and dark themes. And it just passes in the value for that as a data attribute. So that allows us to take that, you know, one little piece of configuration on the Drupal side but pass it into our react component when we render it. It's pretty cool. It's worked nicely. I don't know how practical it would be. I think it would, you know, the more components you have, the more it might make more sense to, you know, think about like something along the lines of fully decoupling.

But literally in a case where we just have a couple of components that we're trying to use and Drupal pages, it's pretty great.

JOHN:
Yeah, that's, that's kind of how we had done it. Since we were migrating from seven to eight, there were, and we had done an earlier migration that wasn't even in seven. It was in a totally different Java CMS. We had portions that were iFramed in the site and the interactivity on those was really poor. So what we did, unfortunately, it was before there was the components module because that would have been really cool for this. But we basically took blocks and turned them into view JS blocks. So it's just loading a view JS module inside of the block. And we did it for, you know, we were able to do it, you know, one section at a time. So like the first thing we did was for our directory search. And, you know, we were able to take that little portion. And instead of it reloading the page and doing weird stuff in the iFrame, it was able to utilize the newer view JS stuff. And it was a lot cooler, more interactive. And we didn't have to totally rebuild everything. We were able to just load view JS in through Drupal and it just worked which was kind of cool.

BRIAN:
And you, so you layered that on over time and added on...

JOHN:
Yeah. So like we, yeah. We did the directory one first and then later we had like a services status block and we were able to do it to that portion and just kind of bit off different blocks at a time. And I say we, and it's, I think it's, it was me. Right. But that's, that's important to distinction because, you know, if we had a large team, we could have probably tackled the whole thing at once and, you know, maybe it could have been totally decoupled. But since it was just me being able to do it progressively, taking one step at a time, it was a lot easier and it ended up working out pretty well.

BRIAN:
Very cool.

DAVID:
Well, Brian, I can explain what, the approach I'm thinking. I don't know if it's a good approach or not. So, with the, we're getting more. Yeah, we're getting more into, you know, the big public clouds with AWS and Azure. And Azure now has this static Web App which is supposed to be really responsive and scalable and available. And you just publish it out of GitHub. But, so I'm thinking it'd be great to have a front end with The view browser build that just consumes the JSON API. And I also really like the JSON APIs already built into nine and it's just sort of very uncustomized Drupal 9. And then, I was even thinking that I could somehow get all the JSON into an azure CDN and it would just all be cloudified. Like I could write a script if there is an, Drupally way to do it that just moves, you know. They'd be like sync button or something. I don't, or maybe, maybe there's Drupal stuff I don't know about that already does this. It just would move the JSON into CDNs and I'd have a azuresthetic Web App consuming JSON in Azure CDN.

It'd be super, super fast and scalable. And it's just that my content editors are using Drupal to make their changes.

BRIAN:
I definitely have not done that with the caching of the API. Mateo, who was one of the JSON API maintainers and also did the contentor distribution. I believe he's done talks that kind of outline a caching strategy for that sort of thing. So it's possible. I've never done it. I think he may have given that talk at a past decoupled days event.

DAVID:
Down look through the decouple day stuff. And then the other thing that I was turned on to, which might be helpful or not, is the Tome module, which I guess is a static site generator, Drupal module. I guess that would include the front end but that might be another way to do it. Just Tome everything into an azure CDN.

BRIAN:
Well, I guess the question that I would have about that is like your content. Like is it dynamic or is it primarily static? Does it change as though...

DAVID:
It changes at low velocity. So, I mean, there, any instance where I would have to change right away I'd be involved anyway. So, yeah, I guess the caching, right. So if you have content editors you need to change right this second and not get the developer involved, caching wouldn't be a good idea, right. But I think business practices are such that that would come up very often. And I think it's more important that we get these we get these spikes into university. So we have like registration going on now and we just get these massive spikes in traffic. And we definitely need that, like a public cloud solution. And procurement is such that that's probably going to be Microsoft or AWS instead of something like Acquia. So just trying to make the most out of Azure.

BRIAN:
Yeah, I would say, I mean, caching the API is definitely possible. But I would say that if you are looking at doing that, I would wonder if you could just take the extra step, which would be practical. That instead just statically build the content and then you wouldn't need the cache. It really depends on your content and your site.

DAVID:
Right. You're right. Well, but, you know, our editors like Drupal. That's what they're used to.

BRIAN:
Yeah, they could still use Drupal for content entry, but in that case. But, yeah.

DAVID:
Right, and the front end would be smart enough that it would recognize new pages. So if there's a call for the API and there's no good answer, you get the does not exist. But if there is a good answer then now that page exists, you know. But, I'd also want to make the sinking mechanism if it's not a Drupal one, if it's something else. I make just something that they can go and click. And however long it takes to redo the cache, they could just sit through the progress bar. So, so that's my approach but I don't know. I'm still noodling it. So thanks for the input. Appreciate it.

BRIAN:
No problem. That's what, that's what this is for.

DAVID:
Yeah, also as, another possible answer for progress, the meaning of progressively is taking the API and turning into like a react PWA, like progressive in that sense. But, I think that would be fully decoupled if you made a PWA out of a Drupal site.

BRIAN:
That's a good question, I'm not sure. I think there is, I want to say that there is a PWA module for Drupal.

DAVID:
There really is modules for everything.

JOHN:
I believe there is. I have not used it though.

BRIAN:
Yeah, and other, like the JavaScript frameworks have similar concepts, like I know Gatsby. I don't even know if it's a module. I think it's just something they offer out of the box. (INAUDIBLE) up is the same way. So I think it would actually be possible to have a progressive Web App that is still a Drupal site. I also don't have a ton of experience, yeah,

SPEAKER:
I know, if you build your (INAUDIBLE) which is angular, you can input all the required things to make it a PWA.

BRIAN:
Yeah. I, I personally haven't seen too much like actual use of the progressive Web App itself. Like I've primarily seen people setting that up to get the nice extra section on their White House scores. But...

SPEAKER:
Yeah, it's (INAUDIBLE) its, I think the coolest part about it is that you can download it right to your phone just like a regular app and bypass the App Store, which is nice. Yeah. Everything I thought there is, I would like that.

BRIAN:
Yeah, that's definitely one of those things like Web components which is like a newer ish technology that I wonder like why they, it hasn't gotten wider adoption.

SPEAKER:
Yeah, exactly.

BRIAN:
Cool. What other, what other decoupled things? We got, I think about ten minutes. Or we could just decouple ourselves from this conversation.

TERRY:
Well, an interesting thing you brought up, Tome. I know (INAUDIBLE) to the presentation a while ago at Drupal Chicago where he talked about using it with Lando to publish a blog site. And the good thing about it was that the site itself, the public facing site, was totally static. And yet you still worked in Drupal. To publish it, really, all you had to do was have the editor write a line of code, more or less in, I think in the, I can't remember, in a file. I can't remember what files Lando uses. I'm totally flaking out right now. But, and then it automates the whole process and replaces the static content with, that's currently on the Web server with new static content. So everything just gets published as a straight HTNL doc. There's no, now in that regard, there's no real interactivity going on. But he used the example of someone simple blog site. And the good thing about that beaning that you've totally taken away the attack surface to the Drupal, you know, the Drupal application.

So for security purposes, that sounds like a great idea.

BRIAN:
Yeah, Tome, Tome is really awesome. And yeah, if you want a static version of your Drupal site, that looks exactly like your Drupal site, it does exactly that. The other cool thing that Tome does if folks haven't used it, is it, to handle all that stuff, it actually exports your content as configuration as well. So like, just like you can export your site's config, you know, for like you're sending from the database. It also sterilizes all of your content as I think JSON files. So you can commit it to like version control. And that lets you like sync data between Drupal sites without having like a persistently hosted Drupal back end, which is kind of cool.

TERRY:
(INAUDIBLE) then the files I turn (INAUDIBLE) are YAMO files, of course. The one he presented was about, I don't know, 2000 lines long, probably. It's the biggest one anybody had ever seen. But, but in fact, you know, within Lando, it's just that one YAMO file did everything he needed to do for that one particular site.

BRIAN:
I know it would be a fun competition for a Drupal event like this. See who can bring the longest D YAMO file. I'll credit you, Terry, if we do that at some point.

TERRY:
Well, I didn't, I didn't bring any YAMO file. You'll have to give that to Aaron. I think he probably still has a big (INAUDIBLE). But, you know, he's also a contributor to too. So, I mean, he's really very familiar with all that stuff. So he did a great presentation on that. And it's an concept. And of course, that's another way of looking at decoupled, I guess, is that they are totally static site that then you just modify using your Drupal back end. But then that kind of, you know, begs the question, I mean, you obviously couldn't do an e-commerce site that way. You couldn't do any kind of a site that really needed to have user input. So that's that was kind of the problem with that.

BRIAN:
Yeah, there are ways around that, too. Again, you know, it's kind of a trade off. Like is it, is it worth the effort? But, a lot of the like static hosting solutions like (INAUDIBLE), wonder if anyone's has used (INAUDIBLE) is awesome. Does really cool things like static hosting. But the, one of the ways that they make their money is that they offer services to handle those kinds of dynamic things. So you can have a static site that has, you know, integration with Stripe for e commerce or another common example as such, right. You can't really have a Stack site with search but they provide a module that can give you clients like (INAUDIBLE) with your static site. But yeah, again, if if that stuff is really important, you know, maybe you really do need a dynamic site, who knows?

TERRY:
Well, having just been on the, on the last search session, I'm more convinced than ever that that's critical to really, to get any kind of user engagement, especially the bigger your site gets. And particularly if it's an information or a (INAUDIBLE) site for that matter. You've got a lot of products. You got to have really good search.

JOHN:
That's actually, oh, it's alright. I was going to say that's what we're going through right now, is upping our search game because it's it's just using the built in Drupal search and that's.

TERRY:
Yeah, that doesn't cut it.

JOHN:
It doesn't cut it. We had a lot of content.

TERRY:
You're looking to use solar search then, right?

JOHN:
Yes, yeah. We're looking at solar and I started looking at how to integrate it, like polling data from our, like we have a bunch of sites that isn't just the portal and trying to pull in data from those sites as well to integrate it in the search for the portal so that you can get to the other things. Just trying to figure that out.

MARTIN:
So the thing that I've seen with some of the existing like headless search applications, I guess, is that it seems like they're really meant to work within the client. So the idea being that it's like, in the client they're actually doing all that indexing that like, with more like a solar is actually being done on a hosted application. And I feel like that works okay as long as your site isn't huge. But it probably isn't going to scale very well if you've got like five thousand products. And then as soon as somebody hits the site, then the client has to go through and index all of that stuff so that it can do searches. So, I don't know. Like I feel like solar should still work with headless. But I know like from a security standpoint, there was always this like idea that like you never want to have your visitors talking directly to solar. You always want to pass that through like Drupal so that it's like making sure they're not like sending commands to, like purge the database or like, you know, any of that kind of stuff.

So I feel like you probably want to use solar maybe a bit differently. I think I've seen like at least one Gatsby thing that was maybe like Super Alpha or something that was like meant to let you use Gatsby with solar. But I feel like if you could marry those two things up, it would be great. Because I mean, even Drupal communicates with solar via like JSON and XML. So, you know, there shouldn't really be any issue with a headless application being able to do those same kinds of communication, right?

BRIAN:
Yeah, and I don't have a ton of experience in this area. But my understanding is that there are some search solutions that are more appropriate for like larger enterprise sites that don't do a lot of heavy lifting on the client side. But like, Algolia I believe, is (INAUDIBLE) people turn to for that?

CHRIS:
Yeah, that's what we're using in Wilson and it works pretty well.

BRIAN:
Cool. I think we are, yeah, we just hit, just hit time. Obviously, if there's anything you want to talk about, I'm sure we'd go a little bit over. But this was a great conversation. Thanks, everybody. And thanks to Ron for setting this up.(LAUGHS)

CHRIS:
We'll make sure to give him all the to do's, so.

JOHN:
That's right.

BRIAN:
Cool. Okay, thanks everybody.

TERRY:
Thanks Brian for hosting this.

JOHN:
Thank you.

BRIAN:
No problem, bye.