About this talk
This talk focuses on front-end strategies for Drupal, led by experts Rich Lawson and Lisa Spinette from Evolving Web. They discuss how to approach Drupal architecture by evaluating team structure, internal capabilities, and editorial flexibility. The speakers emphasize the importance of understanding when to utilize design systems and the benefits of using just Drupal for simpler projects versus the need for multi-site or decoupled architectures for more complex requirements. They provide real-world examples illustrating how to maintain flexibility while ensuring governance across multiple sites. The session concludes with insights into choosing the right strategy based on the specific context of projects and team capabilities.
Full transcript
All right. Hi everybody. We'll go ahead and uh get started here. Um so we're going to be talking today about uh front-end strategies for Drupal. How's every everybody's Drupal convent? Good. Yeah, seeing some positivity out here. So that's great. Yeah, good to see. Um so yeah, we'll we'll jump in. Um so my name is Rich Lawson. I'm an associate director of technology with Evolving Web. Um you
can see my contact information there. I've been working with uh you know evolving web for about a year and a half now. Have a long background in Drupal. I've been working with Drupal for over 17 years now. Um a lot of different capacities and uh yeah I'll turn it over to uh Theresa. >> Hi everyone. Nice to meet you. My name is Lisa Spinette. I am a
lead trainer and uh tech lead at evolving web. I have been working with Drupal for past 12 years maybe. Yeah 12 years. So yeah it is really nice to be here. >> [snorts] >> All right. And um I'd like to provide a little bit of uh background and information about evolving web. Um not only do we specialize in Drupal um but we also have a uh a
training program that we run where we've trained thousands of Drupalists. Um you can see you know we're a diamond certified partner um part Pantheon's partner of the year last year. We have a lot of different credentials up there and we also have um you know where all of our uh projects are strategy driven and so we work with a lot of world-class organizations like you can see
there and the last note about um evolve digital is this is our conference that we have um so we've run a number of these over the years or kind of a kind of a different take or you know like kind of trying to extend out like the Drupal camp sort of an approach where we really bring in a lot of like design and and strategy and others
where um you know we all get together and it's it's a great place to learn and uh we will have upcoming events in Boston in the summer and New York in the fall. So if you sign up there um you can get 35% off once we make the announcements about when those will be. All right. Um so today we're going to be talking about um kind of
you know creating from a front-end strategy perspective um the strategic um framing that we will use throughout the uh talk and then we will talk a little bit about um when just Drupal is the right choice. We'll get into multicight a little bit uh headless decoupled and then you know kind of some takeaways for you and uh leave some time for questions at the end. All right.
Um, so to frame things strategically, um, you know, Drupal isn't, you know, when you're when you're thinking about front-end strategy in Drupal, it isn't just a single decision. Um, there's a lot of give and take and complexity and trade-offs that you need to think about from the perspective of flexibility, complexity, and your team structure. And the correct decisions to make will depend on the context of all
of those working together and where all of those fall. Um, so I I kind of think of it as like this sort of triangle where if you're thinking about um all of these and how they work together, you can arrive at better technical decisions uh you know for the front end. And so um some of the different uh questions that you will want to ask yourself at
the beginning like let's say that you're starting a new project or you're thinking about kind of rearchitecting and rebuilding your front end would be you know thinking about your internal versus your external teams and you that you're supporting. Um it it could just be an internal team. It could just be that there's like a little bit of external help coming in. But what are the skill sets
of those teams? Like what are their capabilities? What makes sense? And then um you know from a editorial flexibility perspective um what sorts of you know how flexible does everything need to be? Uh do you need a lot of variance? Um how many total components are you supporting? Um you know thinking about those sorts of things uh for the components and where they live and who owns
them. Um, do they live in Figma, Storybook, Drupal? Is there a single source of truth? Um, and who owns the decision-making and changes for all those components? And then, uh, finally, what level of complexity can the team sustain in the future? Um, what are what's the comfort level? Um, you know, have you thought about what you're building in terms of, you know, third party libraries and technical
sustainability in the future? And I will turn it over to Theresa for the next section. So this section is going to be about when Drupal or when just Drupal is the right choice right. So here we are not anti-archchitecture we are actually prosized pro right size architecture to begin uh before we talk about the actual approaches or anything we must ask ourselves do we actually need a
design system right and it is not like will it be nice to have one it is really will the project benefit from having one because a design system is not just a front-end decision it is actually an organizational commitment. So it means that we will have to maintain components and align teams and document patterns and make sure that everything stays consistent over time. And what we've seen
is that a lot of the teams assume that the answer is yes, just by default, especially for high visibility or high priority projects, right? But when we step back, the answer actually depends on a couple of factors. You need to know how many sites our brands are we supporting. How many people are actually involved in contributing to the front end? How often is the content or the
layout expected to change in your different pages and how much we actually reuse across the whole website or even multiple websites? Who knows, right? So all of these um all of those answers are going to tell us what exactly do we need. If you do have multiple team members, if you have multiple teams, if you have multiple brands, if you have a lot of reuse, then a
design system might might bring a lot of value there. But if you have only one site, it is a very small team, there's relatively stable content, there's not a lot of things that are reused. That same is investment can actually slow you down. So that's where we start to engineer, right? And in that moment we get that a solution that is actually more complex than the initial
problem. So we have to think about that. Now we can do things with just Drupal and uh doesn't really mean that it is basic right Drupal has a lot of stuff it has a lot of uh architecture a lot of structure we have structured content we have components that can be reused we have thoughtful editorial user experience and we have a lot of front-end consistency even without
a full build built inside of this just Drupal approach. Uh we have a lot of different uh tools and all of those tools are different answers to the same problem. It is the same question. It is the flexible layout which is part of a big part of what we have to deal with, right? But just Drupal gives us paragraphs. It gives us layout paragraphs. It gives us
layout builder and more recently it gives us canvas that allows us to have this new editorial approach to building a pages and that's from legacy systems to the current trends right but we also have um best practices that follow all of that you can make you can get many design system benefits without a full platform for investment just by using the new things that Drupal has like
singular components. You can also integrate all of the all of this with storybook if your system needs it. And in general uh doing componentdriven thinking. The editor experience is another part of this. We can think about the editor experience decisions also affecting the front end. Right? A lot of the times, especially with traditional Drupal approaches, we wouldn't think about that. That was just like, oh, it's the
side building. They are creating content types. They are putting these things together and that's it. But the content editors, the content editors, the experience of those users is actually very important. It it can also affect the front end strategies that we choose. So, just a couple of examples there. Um we have paragraphs which is structured and guided. We have layout builder which is more flexible also a
little bit riskier. We have layout paragraphs again somewhere in the middle of those two and in a lot of cases we have to do migrations from one system to the other to make it easier for our users. Considering all of these things, um I want to show you a couple of examples of strategies that are based on just Drupal and different ways in which we have approached
them. this is the first example. It is a website for the Northwest Territory Sparks in Canada. This was a website that existed in Drupal 7. It was very old. It was migrated to Drupal 10 very recently. Um, it was a small site. It had information about parks. It had multiple landing pages. The idea was to attract users to be able to go to all of these parks,
right? The idea of this one was to build it quickly. The content team was only of like two people. That's all they have. they we had a clear content model for the couple of content types they had and we needed those two content editors to be successful and still deliver flashy [laughter] and nice looking pages right that are going to attract people to actually reserve at those
parks. So in this particular case we went with just Drupal. It was uh we created a library of components. All of that was using single directory components of Drupal and then also uh we went with a paragraphs approach for the back end. So it is one of the simplest examples you can find where just Drupal works. Even then as part of this project we created a component
library that could be reused in other sites with different tweaks and so on as as of the styling of But that was uh the experience with this one. What happens here? What is the key message of the example? That simplicity, even if it looks boring, right? It doesn't sound like, oh, this is super amazing. No, but simplicity works when the structure is clear, right? And that's fine.
That's perfectly fine. This is another project we had. This is a second example. Uh BC builds is a sub project of BC housing. BC housing is a public body responsible for housing uh particularly social housing in British Columbia and Canada and we were providing consulting services to their team for the maintenance of the football websites. There was these particular sites for that campaign that existed in WordPress,
but they were moving away from WordPress and we only had like two months to deliver a site in Drupal because everything else was in Drupal and it needed to go live like on that date. That's it. Nothing else. So, this was in theory a hybrid project. It was transitional. It wasn't supposed to stay for long, but we had a couple of pages to build. We had some
Figma designs and we had to make the things look exactly as they looked before in the WordPress website. So in this case um what we did was use layout paragraphs because we still needed to provide the flexibility to the content editors. you know with paragraphs it is just like very boxy and not very good for content editor sometimes if they want to be able to see what
they will see in the front end with leg paragraphs we had a step ahead right we were still making use of that structure form paragraphs but allowing the users to have that wizzywig like kind of feeling. So we did that and the way we had to actually build all of those pages and deliver a project in only less than two months was we created mostly primitive components
and a couple of advanced components. So things like an accordion uh that was an advanced component that was created or a listing of a housings that was more of a grid with some different stuff. But everything else every even even every postcard that you see there is not an actual postcard. It is just a section with a text on one side and an image in another side
and then buttons in some different places. But then that gave the ability to the content editor to move things around and decide what the layout will be. So we had a side options on the components so that we could change a little bit how it will look like. And with this we were able to get uh some of those design system benefits without actually fully building one.
Not even a full component library, just like little primitive components with a special style options went the whole way for it. And the funny thing is that at the end it was not transitional. The site is still up and it is being reused for more and more stuff. So it worked. If we want to go into the land of more complex sites uh but that still fit
into a just Drupal narrative, we have Norwestel. This is um a telecommunications company in Canada as well and they um they need a lot more flexibility. They have a lot more content and they have a lot more features. So in this case there is a lot of custom code as well but that's back end we won't deal with that and we do have a set of components
uh that are used in this case for this one for the editorial experience builder was the thing we did that allowed more again visual flexibility the editors had more control over everything they want to do sometimes they can even uh edit some HTML in some components because that's what they need to do. Uh we have built-in rules for every different section so that they can we can
limit what kind of elements can be shown in what parts and there is also multiple style options for them to be able to build their own components in the different pages. Now this is a just Drupal project again and we have some small React applications embedded into the Drupal site. So we don't need to go full decoupled to actually have small react applications working in there. There
are applications like um a channel listing tool. There is an application like uh internet usage estimator. All of those are react applications that are embedded in the site. And this one is a commerce website. Uh funny thing about this one as well is that all the front end is done uh on template and using form API as well in some parts. So it is a completely custom
um experience for for the commerce card and it was all created with simple just plain Drupal. Now important thing here is yes there is a lot of flexibility but flexibility without guard rails actually becomes a governance problem. So that's part of the things that we will need to think about here. These are three simple examples. Let's say what happens when we have platform migrations. So this is
the story of the Georgia windet college. So here they had a website that they migrated very quickly and it was using a site studio. So everything was done in the front end by someone and now they needed to move they wanted to do a refresh of the site but there were a lot of components on it and doing a refresh of the whole design in an Aasite
studio website becomes very very very complex complex because it it was not just a a refresh in terms of changing the color and that's it. But it was also changing the structure of different components. And if you have used AIT studio, you might know that it is actually very heavy and a little bit difficult to to to work with for these kind of tasks, right? So in
this case uh what we needed it started our engineer and what we needed was to have that redesign. We have a flexible scalable componentbased architecture with enhanced content editing capabilities. that's what we try to build and by moving it to Drupal uh with just Drupal without site studio we actually reduced a lot the complexity the general complexity of the website and improve the maintainability without actually losing
the capabilities that the website what happens in this case choosing just Drupal for this makes the things easier for later right especially considering the things that we were trying to achieve here at the And that just Drupal approach allow us to keep using paragraphs. We use single diretory components and we even used a component library that they can keep using now for all sides. So again this
make future changes also easier. Another yet another example this is the last one I promise is Ontario security commissions. This is an important website in Canada. For this one, it has a lot of content there. It has a lot of content editors. There is a lot of governance involved in here because it is like government website it is an existing Drupal website. What happened some months ago?
they updated their brand guidelines and we had to apply that to the website. So we started by changing just the logo and then they were like no we actually want to change the colors and the fonts and then they were like well we actually also want to change a little bit some of right classic. So what happens here? Yes, there is this redesign required because it was
already just to Drupal and we had already building in a way that was using component-driven thinking every every element that we had in the site was already thought of as a component. So when the moment came to that redesign, even though we had to think about not breaking existing components, it was a lot easier to not break them in this way than if we had been coming
from site studio for example or if we were um using traditional approaches, right? We would have had to do a little bit of more work. So for this one we adjusted the front end approach. We updated our dependencies. We were able to um use component likes. In this case we used UI patterns instead of SDC [clears throat] but it is still following the same philosophy. So that's
what we did and at the end for that full redesign more than 40,000 pages. I think it we didn't really require any migrations. things went well and this is basically sometimes as I mentioned before just Drupal actually makes sense in all of these examples there are different artifacts and outputs that we can have and I think they still apply for the future uh examples that uh reach
is going to mention but for example uh an output for this approach is the actual paragraphs or components and we will have uh the layout constraints that's also important to decide to define so that we can actually implement them. Uh we can have story book in some projects we have it in some projects we don't and there might be documentation as well right might be lightweight might
be heavy it depends on the project you're working on. The thing is that most team don't really need more architecture just need better decisions within Drupal and there are going to be cases where this is what we need to do. We don't really need to overengineer it. We don't really need to go and do extra stuff for it. How do we choose? Well, we need to choose
the right layout approach. We need to prioritize it or clarity because that is going to change what we will work with and we will be adding complexity complexity sorry only when needed and at the step and at the stage that is needed. some considerations about just Drupal to wrap the question the the section sorry um is that in reality Drupal just Drupal isn't just a per the
perfect solution right sometimes you will need other stuff but just Drupal is a set of tradeoffs on the adv advantages side one of the biggest ones is transparency you are working directly in Drupal there is no instruction layer So there is no separate system to debug which makes things easier to understand and to maintain over time. Um it also gives you a lot of control over the
things like privacy and data since everything stays within your platform. Uh from a team perspective, it lends it leans into Drupal strengths like community, collaboration, collaboration, sorry, and flexibility, but also um you can customize it in any way you want and you can still get other stuff added like the case of Norway with the React apps. All of these benefits come with trade-offs, right? So you do
need certain level of expertise and I know that a lot of front end developers don't like Drupal. I know a couple over there. Um [laughter] they don't like Drupal a lot. So and they prefer to do other stuff, right? So it also depends on what your team like you're going to choose one thing uh trading it off for another. So especially to structure content uh to structure
it well make good front end decisions without relying on heavier systems. You may have limitations compared to more specialized or abstracted solutions. And while it is simpler in architecture, it still requires time and resources to do it well. Right? I had a case where uh we were printing a field like directly in a in a in in a template instead of actually using the configuration from Drupal,
right? And then months or years later, we came back and oh, we did a change in a configuration, it's not showing up. Of course, it's not showing up. It was hardcoded in some weird way. So, it it requires time and expertise to to do it well. So just Drupal works really well when you want to keep things straightforward and maintainable and your team is small and you
don't need a lot of uh reuse. But as soon as you start needing more standardization or more flexibility on the front end then that's where other strategies actually are going to serve you best. And with that note, Bridge will talk about Multisite. All right. Uh, thank you, Theresa. Um, so um, a lot of these same themes will kind of um follow through in these other sections and
um, and so in focusing on multi-sight um, we're going to add some complexity to support multiple sites that share a single codebase. and what the implications of, you know, we'll examine the implications of that. Um, so I'm going to be using the pro provincial health services authority site, PHSA, as an example. Um and what we were really um our goal for this particular project was to create
a platform to support a large network of branded sites um in in healthcare and multi-sight is really powerful for this. Um but it does have some complexities and to set the stage for this a little bit um we built the platform out on aqua site studio site factory um I was throwing back to the site studio from before um but yeah it's site factory um all of
the different content types except for um the landing pages were um using paragraphs. So if you think article, event, basic page, service etc. um we were using um just paragraphs but for the landing page we wanted to have some additional flexibility. So we included layout builder and then we opted for an iterative roll out of the different sites and stages and we already have four different sites
that have been launched. Um and so you know you can see there that what we did to structure the theme across the different brands. So if we're thinking about this in terms of everything that uh deresa talked about like in a lot of ways this is just Drupal but extended right and there are some implications that we're going to talk about in terms of the way that
everything is is structured. Um so one of the things that we did is we built a base theme and then we have a single sub theme per site. Um, we use Gulp and Tailwind on the project and, um, going back to what Dreesa had talked about before, we use single directory components. And, you know, when you think about the assets, um, a lot of those things do
carry through. Um, so we had a a shared story book for all of these different sites. Um, and that was based on Figma designs. And then um as I mentioned we have the base theme, the individual themes and then we also used a feature matrix to kind to help um identify you know which components would be available on the different sites. And we're going to talk a
little bit more So multicight isn't just about sharing code. It's also about standardizing decisions. That was one of the the key factors that um we thought about in this project and we'll often think about when we're using multicight. Um and so what we want to do is we want to be able to standardize things visually but not in a rigid way. There still needs to be some
flexibility. So component sharing and both component and feature governance. Um I mentioned that feature matrix. We also had a component library. Um what I what I'm referring to with the feature matrix is basically you what you do is it can be very simple. It could just be a spreadsheet. Um but what you do is you for each of the different sites you basically work with the client
to determine okay you know which components will be available on each of these different sites to basically you know come up with a good toolkit for the editorial team for you know in terms of what they would be using. Um so some of the feature modules that we actually built as part of this structure um you know uh they set up a baseline and so all of
the sites would have that same capability and that you know all it would be consistently enabled and then in other cases we were basically setting that up to provide particular components or features to each of the individual sites and then you know the editorial team doesn't have to think about anything so they're just going into the interface and they're picking and choosing they're they're focused on the
content and not you know having to be trained to do this specific thing for this specific site. Um in terms of new features one of the implications of using multicight is that your feature intake is it should be more structured. Um, and what I mean that by that is basically when you're you're determining whether or not you're going to build a new component, for example, um, you
know, plan that out. And, you know, you want to make sure to think with the client about, um, like what, you know, what do you already have available? Um, you know, we it often reduces the one-off features and you can get a little bit more flexible, get that flexibility that you want by extending existing patterns. And you know you can consider things like including optional fields to
basically have a variant um of a particular um component. So a really simple example there would be you know just this this radio button here where you pick left or right for your alignment and based on that this particular card will have you know the image aligned left or right. And then um one one thing that's really great about having the single codebase is that um you
know your development speed can really increase um because you know the developers can jump in and out of the codebase much more easily. You don't have a separate set of code for all of the the different sites and um you know but there's also the trade-off of the fact that with um Siteactory you do have where all of the releases are going to be happening at the
same time. um you don't get to pick and choose um you know on that uh and then it als and because of that it requires a lot of coordination right so from a UAT perspective a quality assurance perspective just making sure that um you know you've got everything tested and ready to go um and one of the things that we really wanted to do with this platform
is to have it be adaptable in terms of the technical solutions and so um you know I've been mentioning these shared components the feature matrix I have this visual here that shows that for the different sites like you could choose different colors. I'm going to have examples of this here shortly, but you know for um site six for example, you've got like these four different uh components
enabled versus you know site 5 only has one. Just as a simple example of the flexibility that we have in determining exactly where everything is available and and what will be um applicable to specific sites. Um, and then we have, you know, CSS variables for, um, automatically applying different colors for the different sites and their subbranding. We're going to see the the example of that in a
minute. Uh, and then there's also CS variables, um, CSS variables included in the config so that when the pages are rendered, the site specific variables are used. And so that's how we can really have like very brand specific um, you know, uh, you know, features and and just the look and feel built right into the theme. And then um we also do the same thing with um
icon sets and other sorts of configuration that are uh are helpful with that. And so to work around um you know some of the issues that I mentioned about the the single codebase we'll often use the environments to help us test out for the releases. And we just keep in mind that you know if we have a release to you know the staging environment for example that
all of the um sites are affected by the code on that site. So here you can see an these are examples of um some of the components across the different sites. So you know you can see that um you know the logos and the colors and the iconography are changing and so you have the same components but you end up with a different expression but you obviously
have that like standardization that you're trying to drive you know to maintain the brand. Um and so I I mentioned before that we had created a single storybook instance um that is uh publicly accessible. Um if a new component is added for a site um it would appear in storybook and we would then determine whether or not we would add it to any of the other sites.
So that that's something that's part of that toolbox but we would actually have to uh intentionally go through go in and and enable that for like the first site that was built for example. Um, and you know, a storybook also provided us with a way to, you know, show off the existing features. Um, because each site that we would build, we would have a a discovery and
it would be a different set of stakeholders. And so they may or may not know a lot about what all the capabilities are and everything that's available. And so it gives us a starting point in that process to have those conversations and determine, you know, what the right requirements are for that site. And it gives us, you know, also that starting point where we can kind of
maximize in terms of the level of effort on the sites like from a front-end perspective to make sure that we're spending time appropriately and that we're making use of all of these great things that we've already built. Like let's let's take advantage of that. Um, and so, you know, that was really helpful from that perspective. All right. Um, so how do you decide whether or not uh
multicight is actually the right choice? Um so you know multi-sight works really well when um you have you know multiple brands with a shared structure. Um so we've been seeing that right like you you saw all the different brands presented there um and they're all sharing the same codebase when you need that consistency and governance um like I mentioned with the feature matrix and the way that
we you know handled everything with uh feature modules and when you have a centralized development team. Um, where it struggles a little bit is if you have highly unique, you know, site requirements like the special snowflake type of sites where, you know, you have like, you know, it's going to create this issue where if you were to try to meet all of those requirements and have it
on the platform, then it's going to just have so many special cases that it it throws things off a little bit. Um, you might want to just have that hosted like off the platform. You could still do that in Drupal, but, you know, maybe it doesn't make sense for it to be there. Um if you do need to do independent um release cycles, it depends on the
capabilities of the platform that you're using for the multi-sight, how much that comes into play or if you have weak governance um where you know like it's going to be really challenging for you to kind of um you know you don't want things to be quite that rigid. So um you know what I wanted to talk about next so you know increasing the flexibility a little bit
further and also the complexity we can get into headless and decoupled and um one of the things I wanted to do so um the reason kicked us off by talking a little bit about the progressively decoupled but I wanted you to have a visual right away I mean you know a lot of these things are have been in the toolbox for a while now um but you
know like these are things that we're thinking through as we're determining you know what approach we want to take from a front-end So you can think of the just Drupal as being kind of like the the coupled Drupal, right? And so if you look at this like the yellow and the orange are the portions of uh they they're identifying the front end basically that are seen by
the end users. And so um you know both uh you know most of uh Dresa's examples as well as that PHSA the multi-sight examples we were really in in that in that region there. And then um with progressively decoupled um you do have you know it's typically a react component um that that we you know from our perspective that we're basically um progressively displaying within the app.
So you have like part of the front end that is basically you know working through react and it's its own JavaScript you know separate component versus fully decoupled or headless is where you have Drupal and other backend systems driving things behind the scenes. We won't worry about that. Um, but you have the front-end application. It could be Nex.js, it could be a variety of different things where
everything is displayed through that front end application. And so, one of the things to think about like let's say that you determine that you do need to go decoupled, it's it's figuring out how far you should go. Um and so if you are thinking about um this within a Drupal context um you know when you go fully decoupled you're typically thinking about you know like this single
front-end layer and again there can be multiple backends including Drupal um whereas with a progressively decoupled site um you know you are um really thinking about like particular apps um a lot of the time it would be like targeted in terms of the interactivity that you would need. Maybe you want a little bit more of a, you know, like an app-like experience. And so you determine that
that makes makes sense. And to give you a couple of quick examples of that, um, it could be, you know, a global site search with an Algolia backend. Um, that also maybe has some, you know, like uh cards that pull in from Drupal. Um, and and so you've got this this app that you've built that does that. or it could be a user university program finder um
that has Apache solar as the back end and maybe similarly is pulling in you know content from uh from the Drupal side as well. Um and so you build out that application and it works within the theme within the overall Drupal theme. All right. Um so decoupling uh from a flexibility with uh some trade-offs. um you know if if we think about it uh from the perspective
of um you know like what is the impact and what are are you are you losing um so with that separate front-end layer you lose um some of the benefits of what you get from the front end from Drupal um so there may be a lot of front-end developers who kind of have some issues with Drupal themes but you do get a lot out of the box
in terms of accessibility and other things that you don't need to really solve for um and you know so then you have to account for that yourself. You have to make sure you're using the right libraries and you're accounting for all the accessibility on that new front end that you build or even within that that app that you're building um if it's progressively decoupled. Um and then
you know you're ending up with a much more API uh driven architecture. So you have to um you know have the ability or be thinking about like integrating the different systems into that front end uh that are are powering you know from a backend perspective and um you know you end up in a situation where you you know you can end up with like really independent uh
front-end development and it separates out your concerns a little bit and you know like one of the things that you get with like the fully decoupled is that you know you don't necessarily have to know anything about Drupal. um you know you could you're basically interacting with APIs and and so if you understand how to do that like that's a that's a plus and so you know
I think the key here from from my perspective is that when you're decoupling you know you're no longer constrained by Drupal you can kind of do what you want to do but you lose some of those built-in advantages on the front and then um from a team perspective it also has some um changes in terms of how the the team will work um so for example um
you know it's shifting the logic out of Drupal and into the front end apps like you can control for that by having like APIs that handle you know a lot of logic for you but like in terms of the actual like front end itself it's it's shifting um and then you have to have you know some additional coordination between the front end and the back end um
so for example um like let's say that there's a release on the back end because it's separate right you have a you know it's decoupled and so if there are API changes that um aren't accounted for on the front end then you know you can end up with a you know a botched release where things are not working well. Um and then there's also some increased like
you have to worry about dependencies and you have more responsibility on the front end versus if you're just kind of you know having everything within in Drupal like with npm and and that sort of thing. And so you're no longer um just working within Drupal you know you're building the either one or more applications outside of it. Um so for uh challenges that come along with decoupling
you know you do have increased architectural complexity um because you know you've got multiple applications it's just inherently a little bit more complex um and then you just have some differences in terms of what where your front-end expertise lies. If you've got a team that is wellversed in Twig but they don't know React or the opposite you know that will affect your decision a little bit. I
I've actually you know um one of the decision points for for me on some of the different projects um has been you know what are the capabilities of the front-end team uh for a client um and then content preview can be kind of tricky sometimes with decoupled um you have to allow some time to solve for that there are some good solutions out there but you know
it can be a little bit challenging and then uh you know just coordinating with the teams like I was saying like in terms of releases and um and then you know There are a lot of technical patterns that we would we often see with decoupled Drupal. Um, you know, in anytime that you're pulling anything out of the Drupal backend, you would be typically using like JSON API,
GraphQL, maybe REST. But, um, one thing to keep in mind is that you don't always have to do that. Like for example, in that one example that I gave, we actually built out a progressively decoupled app that we didn't have to enable any of the backend Drupal stuff. Um all we were doing is we were actually interacting directly with Apache Solar and just pulling everything from there.
Um and so um you know that you know worked well. Um and then uh for front-end frameworks um you know Nex.js is very popular but there's other examples there like NX and Astro um you know there's there's a number of different things that you could check out in terms of a framework that you would want to use. Um and then you know there's some complexity in terms
of you know how you would be handling things like authentication and just your build deploy pipelines that that kind of go a little too deep. Um we don't want to get into that uh right now. So finally some examples and some more visuals here. Um so we worked with um Princeton University. So this is I I want to show you you know progressive decoupling what that looks
like in practice so you can actually see an example of that. Um, and so we worked with them on basically this Princeton international site and um, what that is is a a Drupal site that encourages their students to explore the different international learning opportunities. Um, so it's seminars, exchanges, et, etc. And the progressively decoupled part of this is um really focusing on allowing um students to be
able to uh search through available programs and you know plan out their course of study and really build out through inter an interactive tool their curriculum. Um and so we decided that it made the most sense to build that as progressively decoupled. Um it's reactbased uh and students are able to go in and and build these itineraries. And here you can see the mobile view of this.
And so in addition to being able to, you know, build their own plan and share it, students were also able to add notes and do other things. So if you you're looking at this on the left, you know, you have um kind of the progressively decoupled portion where you can kind of see these interactive elements where, you know, you can move things up and down, you can
add notes, you can you can work with it. Um it it you know, it has a nice experience to it. And then all of this gets saved to you know their profile through um you know the back end. And then on the right you have the part that is the Drupal theme you know where you actually have like the the header the menu etc all that you
know wrapping around it. And then um for a fully decoupled uh example or a headless example, I wanted to talk a little bit about um our Planned Parenthood um project that we did to promote the Planned Parenthood direct uh application. And um and so that what we were really doing there is we were building a promotional site um fully fully headless that um was promoting an a
new application that they had um called Planned Parenthood Direct. And so you you know everything that you see here is not Drupal. Um it just gets the information from Drupal. And so it's a marketing site that um you know offered um it's offered in each state. Um and you know it kind of leads to that CTA there where um you know the app can be downloaded. You
know we worked out all those accessibility details that I said you know where everything is fully accessible. Um we do have the uh library of reusable components um that can be you know used in the future um to build out new content and you know if we ever want to extend things a little bit and then um you know it's it's hosted on Pantheon using their decoupled
architecture um and it's built in Nex.js. So um you know just some takeaways from the uh just this this uh decoupling uh section here is that fully decoupled works really really well um with like multi- channelannel delivery. I I didn't I didn't talk about this so much but um you know the idea here would be that the output would need to be multiple different channels. So for
example web um mobile apps um it could also be digital signage things like that. So when you think about like okay where is all of this going it you know that would drive more of a um you know like an API first kind of mentality uh for your sites if there are multiple backends also. So maybe you have Drupal and you have a CRM and you have
a custom applica you know API that you need to interact with and you just want to have that seamless experience where you have a single front end over the top of everything it works really well for that. Um, if you have complex front-end needs, like you have a lot of interactions and animations and things that you want to do, uh, it can work really well there. And
if you have a strong front-end team where, you know, like for particularly for the the, uh, progressively decoupled, they would have to have both JavaScript and, you know, Drupal theming capabilities. Um, and that would drive that a little bit. And then um you know progressively decoupled uh yeah would work best when you have um areas that are very targeted uh that you want to have additional interactivity
and animations and things like that. Um if you have an existing Drupal front end and you want to basically enhance it instead of like rebuilding it in a different way. Um or if you have like a lower complexity tolerance where you just want to make sure that you know you're keeping things more on the simple side which can work really well. Uh and overall you would want
to avoid decoupling when you know you don't have as much front end expertise or going back to you know one of like our kind of you know messages you know if if the complexity isn't justified. So a lot of the time like if a client just has Drupal and they just want to do like you know building a decoupled site with just Drupal like you're you've got
a lot of tech technical complexity if that's your only backend and you don't have any mobile apps and you don't have um where you're you know digital signage or any of those other sorts of channels you you're kind of creating a lot of of work for yourself um and you aren't able to take advantage of as many of the benefits. All right. And with that, I will
turn it back over to Daresa for to wrap things >> Yeah. So, to wrap things up, if if you're going to remember one thing, we want it to be this. The frontal strategy isn't really about the tools, right? It is about uh the goals and the trade-offs that you have on your projects. So, it is easy to focus on what you're using, whether it's paragraphs or volume
builder or whatever it is or decoupled or whatever it is. But those are just implementations, right? The real question is what is the problem? Like it doesn't really work to say, oh, I want to make a decoupled website. That works for for testing and for learning and we want to see how to do do it, right? But just because it's not a good answer when we are
building a site for a client. So we we need to know what is the problem that we're trying to solve and what is the complexity that we are willing to take on as well because every approach we've talked about today has benefits and it has disadvantages and they have trade-offs right so if we say it simply uh just Drupal is uh allows us to keep it lowers
the complexity it is faster iteration it has a strong editorial guidance So that's good. But multicight allows us to standardize decisions across teams and across sites as well. It enables the reuse and governance in the website or in the organizations. Uh but it requires coordination and shared ownership. So that's important to consider and couple it adds extra um and control over the whole front end. It enables
it enables richer experiences in general, but it also increases complexity and shifts responsibility onto your team. So none of them is better than the others at all. They are just different ways of balancing. Remember the triangle that Rich showed at the beginning. So they are different ways of balancing those three things. Flexibility, consistency, and complexity. And one of the most important things that we have learned is
that most of the projects should stay as simple as possible for as long as possible. I I love to say no to something. It's like no, why do we need it? If there if it is justified, if we are willing to take it, that's perfect. But otherwise, complexity isn't just a technical cost, but also something that the team has to maintain and work with, understand and support
over time. So when you're choosing your front-end strategy, don't start with the trends. Start with your theme with your team and choose an approach that balances all of these things. the complexity of your project, the size, the structure of your team and also what you can realistically sustain The best running strategy is not the more advanced. It is actually the one that you can sustain. So, thank
you. >> If you have any questions. >> Yeah. Yeah. Thanks everybody. [applause] Okay. >> Uh for your multi-sight uh approach when you mentioned uh deciding what components were available per site uh was that just like field level configs for the paragraph field which ones you enabled or do you have some other approach as to like their packaged in modules that you would enable on certain functionality on
one site versus the other? Yeah. Yeah. So the uh the question was for the multi-sight whether or not um we're controlling that at like a field level um in terms of what's available or if it's actually like at the code level. Um and so uh we're we're actually controlling that through those those feature modules. Um and so it would just not be available like within the like
if we do have a selector for a component like it it won't be available at all. Gotcha. >> Yep. Any other questions? >> Okay. All right. Well, thank you >> Oh, yes. Thank you.
