This is a transcript. For the video, see Decoupled Drupal: Past, Present, and Future - Part 2.

[00:00:00] Michael Meyers: Hello, and welcome to another Tag1 TeamTalk. Today we're going to be diving into decoupled applications. I'm Michael Meyers , I'm managing director at Tag1 Consulting. And today we're joined by Preston So, Tag1's editor in chief and the author of Decoupled Drupal in Practice. This is part two.

We're going to be diving specifically into decoupled Drupal. If you haven't already, please check out part one where Preston gave this amazing overview of decoupled applications and systems really worth checking out. Preston, you are the authoritative figure when it comes to decoupled Drupal, you wrote the book, you helped Dries in the community, shape the philosophy. Is Drupal a good option if you're looking at decoupling an application?

Preston So: Yeah. Great question. You know, it is, it is kind of funny. People still reach out to me asking about my book and in certain chapters in the book. And I told them I wrote that that book was published three years ago. That's pretty out of date. but you know, I really appreciate those kind words and it is something special too , and kind of what people consider to be the Bible of a decoupled Drupal.

You know, decoupled, Drupal has evolved a lot in the last, I would say, gosh three to five years. And ever since I've been really deeply involved in decoupled Drupal, been really amazing to see a lot of the evolution and the decoupled Drupal ecosystem and in the community.

So what I will say is that absolutely. I mean, I still absolutely have full faith and I believe and I'm not just saying this as a an author who's trying to make money off of his book, or, or as the editor-in-chief of a company that makes a lot of money off of Drupal.

I do still think as a technologist and as somebody who is a neutral evaluator, that Drupal is a very compelling system for decoupled application architectures that are, are, are really all the rage today. And I'll, I'll share just a little bit about why that is. The first is that Drupal has always been a very forward-looking ecosystem when it comes to serving different applications that are not in Drupal's wheelhouse.

The Drupal web services ecosystem has been around for. Many years, I mean, more than 10 years, really. There've been some, there's been some kind of manifestation of web services within Drupal's ecosystem and this commitment to kind of external consumers and external clients has really served Drupal well, because as Drupal and the late in the mid teens began to start building out some of the Rest APIs that are now commonly used.

It had a really great foundation to rely on. And, unlike some of the other options that are out there and I'll, and I'll just name one, I don't mean to kind of discourage people from using this platform. I use this platform myself, but Contentful for example, which is a diamond sponsor of our Decoupled Days Conference this year, Contentful came up with their approach to web services and their approach to serving data a relatively long time ago, and a specification that's very unique and a specification that works very well. But for people who ar coming from different backgrounds, it might be a little bit of a rude awakening because they're not used to some of the standards that are solely in Contentful's on a kind of web services.

One example of this is. Drupal serves all of its data through an API specification known as JSON API, which is commonly used across the world, many different Rest APIs around the world use the specification. So if you're coming from a, a, a background where if you used JSON API before, or you've used some of these ecosystem tools before that has to do with JSON API.

You know, putting your application on Drupal is just slotting over your same validation, your same tests, your same client SDKs, all of that, and just moving them over to Drupal because it works perfectly out of the box. If you just have the same JSON API structures, it should work just out of the box because our JSON API specification within Drupal is fully compliant with the JSON API spec.

The second reason I would say that Drupal is still a very, very good option is actually - sort of an addendum that I would say I have to add to my book, which is that back when I had finished my book, Decoupled Drupal in Practice back in 2018, GraphQL was a very kind of up and coming kind of approach to querying different databases and systems that serve content.

And what's very interesting is that, you know, GraphQL has become very popular and many people use it and Drupal provides a GraphQL API. Now things have changed a little bit though since the time that I wrote my book. So just to update the leadership and just to kind of add that addendum or errata to my, to my book, Decoupled Drupal in Practice. GraphQL is something that in Drupal no longer just exposes the content model as a GraphQL field. as they're known in GraphQL and simply allows you to kind of let go and just kind of have at it based on the content model.

And the reason for that actually has to do with the way GraphQL works on the inside. GraphQL is not just about kind of providing a approach for querying kind of set data or set structures of data. really meant to be more flexible. And really meant to be something that people can really tightly customize according to their needs.

And so one of the things that's very interesting that I've been watching over the course of the last. you know, three to four years, is that the team working on GraphQL and the module was originally developed by a friend of a Tag1 TeamTalk show Sebastian Siemssen, a Fubhy on drupal.org, GraphQL is now no longer something that just kind of is something you tack on.

now something that actually is much more rich in that you can customize different providers for GraphQL. And you can actually write your own APIs in GraphQL, according to what you want to do for your own applications. by leveraging GraphQL module in its current state, which is GraphQL v4 now that has led to some frustration in the community, right?

Because, obviously this new version of GraphQL means that you can no longer just kind of install GraphQL. How about working GraphQL API, there is a significant amount of additional work that has to happen on the GraphQL side, where , you know, the people who want to build an API have to write the providers and write.

The schema out for all of the different GraphQL queries that they want to enable. So it becomes a little bit worse for those who are building applications on top of GraphQL on Drupal, but it came, but it becomes much better for those who want to have much more control and much more flexibility over how their GraphQL API actually looks on the Drupal backend.

Michael Meyers: So do you, is there a preference, like Rest, JSON, GraphQL if you're going to build an application to decouple that page in Drupal today, is it totally situational and impossible to say? Or would you point people specifically towards one of those options?

Preston So: Oh, wow. Well, woo, a really good question.

You know, , one of those things where I would say that both of them have their place, right? JSON API and GraphQL, both are compelling for different reasons. JSON API is very [00:07:00] compelling because it is entirely compliant with the fielding constraints that Roy Fielding set out in his dissertation about how Rest's principles should work.

The underlying foundation of Rest APIs, as some of you may know, is an acronym that stands for Representational State Transfer. And in a nutshell, what Rest is really about is HTTP driven methods that allow you to drive updates and drive query is and drive all these things that are rooted in web technologies and rooted in the way that we operate on the web today.

One of the very interesting things about JSON API is that they've taken this a step further, right? They've taken this a step further by saying that there should also be links between these resources that allow for developers to really richly access a lot of these different resources not through separate queries and separate requests.

But nearly by accessing those things through the API response in and of itself. [00:08:00] And there's a lot of different terms that kind of fly around related to this. I would definitely recommend reading up on my former colleague, Gabe Sullice's', his blog posts on the subject of HATEOAS, which is hypertext.

Oh my gosh. Hypertext as the engine of application state, which is this very important paradigm for building applications that allow for this kind of HTTP driven linking to take place. So what I would say is if you're somebody who's building. You know, applications that rely on relationships between data, links between data and also potentially things like pagination that relies on a very kind of strong sense of where you are in the data.

I would definitely recommend that JSON API is a great solution for those things. However , today I think there's been a very big, a large amount of momentum towards what we call a graph driven queries or graph data, right. Or graphical data, which involves the notion of being able to kind of, kind of tailor your [00:09:00] response from the API, according to how you're going to tailor it in your query.

And GraphQL has really become very popular because people really like the ability to kind of dictate what they get back from the server. Right? One of the issues obviously of Rest.. One of the, one of the obvious issues of the approach that I described with JSON API is that you're kind of stuck with what the server gives you.

Right. You you're kind of like, okay, well I'll give you this request, but whatever you give me is what I'm stuck with. Right. And that kind of means that you might get too much data or you might get data. That's not really formatted according to how you want it. The GraphQL has really kind of filled in that gap where saying, if you need to have much more flexibility over how the responses come back, And not so much about the relationships between that data.

Then go ahead and use GraphQL, because you're going to have a lot more flexibility over performance of that data and how it actually filters out into your application. so both of them have their place, right? I would say that , you know, I still use JSON API on my personal site to drive my website from Drupal.

I think a very compelling API. I [00:10:00] really, really like the you know, what I like about JSON API is that very - , a verbose, but also very clear, right. whereas GraphQL, I would say is not verbose, but sometimes not very clear. So that's where I would maybe think about the trade-offs.

Yeah, always pros and cons. One of the things that I think has always been Drupal strength is its site building capabilities and empowering non-technical users to control and build web applications. I think why a lot of enterprises. Adopted - how does decoupling impact features like layout, builder and site building creating content types and taxonomies , and you know, things like views , you know, do we lose them entirely?

Do some of them still work and benefit? So the answer, of course, with all these things, is it depends. Right? So, you know, you shared several examples that I want to go through one by one. So one is content types obviously, and content models. [00:11:00] What's pretty lucky is that, you know, because of Drupal's robustness with content modeling and because of Drupal's robustness, when it comes to how it models content, I actually think that that's not a big concern.

You know, whether you use GraphQL or JSON API, and really quite flexible. Where you begin to run into problems is not so much in a taxonomy terms and that sort of thing, but more in terms of , sort of these visual elements, right? And the things like presentational elements. And as we said, in part one of this series about decoupled applications, one of the biggest reasons why developers and architects love to decouple Drupal is because it allows them to separate concerns very clearly, and kind of draw a line in the sand between a rendering and between the data.

And of course, when you begin to kind of say that, okay, not only do we need to consume data, but also lay out information from Drupal in the front end, that kind of violates the separation of concerns and kind of blurs that important line in the sand between these two. Very important disciplines.

[00:12:00] So you know, one thing I would say is that there's, there's there's the philosophical answer is that if you're trying to drive layout, that should really be something that's driven by the front end application. And this is something that I would say most software architects agree on.

Right. But of course as we know, from our experience with customers, and as we know from our experience with people who are, who are paying us money, not so easy. And when it comes to lay out, what's really good is that Drupal obviously provides the ability to consume some of those things in the form of configuration entities.

If you're using the quarterly app builder it requires a pretty large amount of work. It requires you to kind of really think about how you're going to surface this for the developers who are building your front end application. but it can be a really powerful tool for people who want to be able to drive layout through this sort of approach.

The other one you mentioned was views and views is one that lies kind of in the middle. Right? So for those who aren't familiar, Views is Drupal's canonical kind of query builder for putting together arbitrary listings of content or arbitrary listings of data in very [00:13:00] compelling ways. And there are various levels at which you can tap into the power of Views to power your applications. There's Views Rest exports, which is obviously just kind of a simple replication of, of a view for consumer applications, but very brittle, right? Which means that you're kind of stuck with what you have in views and you can't really do much with it. There's also an emerging module called JSON API views, which is a ostensibly trying to drive you know, the ability to have views that not only are serving really good data resources, but also adhere to the JSON API paradigm that Drupal now has adopted quite a bit.

But when it comes to presentational elements I think there is one particular initiative that I want to call out here that is doing some really interesting work and that everyone on, on, on this webinar should, should definitely follow. And that is the decoupled menus initiative, which is happening within the core Drupal contributor community.

And this is an effort to try to allow for the sorts of menu management, right? This is kind of a [00:14:00] presentational concern that kind of lies on that knife's edge between the you know, rendering concerns and the data concerns and is really focused on how can we allow for somebody who is a Drupal site builder, right.

Who doesn't know any code, who wants to manage these menus and kind of drive how these menus are appearing in the front end. How can they drive that within Drupal and how can the developer on the other side of that line, in the sand interact with those menus in a very rich way. So, this is an example of how Drupal is beginning to try to bridge this gap between, you know, across this abyss that is widening that is the separation of concerns between the data delivery and the rendering mechanism that people are really, really fighting, very hard to keep separate.

And I'm very interested to see how it works personally. You know, in my view, I think that the separation of concerns is kind of a foregone conclusion. And I think that we kind of need to accept that. and but , you know, I'm very excited to see what sorts of interesting, [00:15:00] innovative things they come up with.

And I really, really am very happy as you know over the years, I'm happy to be proven wrong on some of these assumptions that I make, so very excited to see the progress of the decoupled menus initiative. And I'm hoping to see a submission from that team for our Decoupled Days call for papers this year.

Which by the way is, is ending on April 1st, not an April fool's joke. If you have any, a headless CMS or Drupal decoupled Drupal related talks, our call for papers is open and it closes on April 1st , midnight Eastern time. And we're going to be virtual this year. I want to make sure everyone who's listening to this has an opportunity to think about submitting a talk.

We'd love to have your content at our conference this year.

**Michael Meyers: **That would be amazing. Yes. Please submit your ideas. So. You know, Another great thing about Drupal is modular nature extensibility. You know, if my organization is putting together a decoupled site, are there any considerations the developers need to factor when building their modules or [00:16:00] is it simply plug and play?

Preston So: That's a really good question. So this has been a source of a lot of debate over the years. And so I'll share kind of ,you know, and, an impartial view of some of the things that have happened. Because Drupal has always been monolithic because Drupal has always been kind of a server side architecture that is end to end that doesn't have any sort of internal separation of concerns between these layers.

One of the really interesting things about Drupal is that it allows you to install these modules, but the thing is these modules are only relevant or , actionable on the Drupal site that is inextricably linked with the, you know, with the site that you're building at that time.

So there's been some other kind of ideas out there. There's been some interesting kind of possibilities that people have come up with. One of the ideas that I found very interesting , from some folks is the notion of providing a kind of a two-pronged approach to modules, right? Where one module one library is [00:17:00] for Drupal and that's the PHP library for that module.

And then one other module one other kind of library is the JavaScript library or the front end library. That provides the UI. And that is actually in very interesting , a very interesting case of codifying the separation of concerns, actually within the module architecture , which, which already does happen in PHP obviously.

And there are you know, examples of that within the modules itself, but a very interesting idea that as we move into more JavaScript driven UI , should we enforce that same separation of concerns that we use to build applications every day within the very ecosystem, plugins and modules that we need to use?

t's a very interesting kind of thing. I think there's a lot of complexity involved in sort of a lot of the thinking. but I think the decoupled menus initiative is just one of the examples of people who were exploring this liminal space between , you know, how we can enable the separation of concerns to really thrive, but also enable the sort of , really nice, uh composability right.

That Drupal is famous for in terms of its site building capabilities.

[00:18:00] Michael Meyers: Excellent, as always Preston. This was amazing. I have so many more questions for you. Hopefully we can come back and do this again in the future. for those of us you know, who are just joining us in, in the segment two, please remember to check out part one of this conversation, a general overview of decoupled applications and systems, all of the links.

That Preston mentioned. We're going to put in the show notes below. if you really liked this talk, please remember to upvote, subscribe and share it with everyone you know. You can check out our past talks at tag1.com/tag1teamtalks. We'd love your input and feedback on this show and future show ideas.

Please email us at tag1teamtalks@tag1consulting.com. And a huge Thank you, Preston. Appreciate you joining us today. fascinating love talking to you. This was a lot of fun for me and thank you to all of our listeners for joining. See you soon.