Transcript: Decoupled Drupal - Strengths and Weaknesses -Tag1 Team Talk #008

This is a transcript. For the full video, see Decoupled Drupal Strengths and Weaknesses -Tag1 Team Talk #008.

Preston So: Hi everybody, and welcome to another Tag1 Team Talk. I'm really happy to be here with some of my great friends and colleagues from the Drupal community, here today. By the way, my name is Preston So, I'm contributing editor at Tag1, and moderator of the Tag1 Team Talks, and author of, "Decoupled Drupal in Practice." Today, I'm joined by people from all around the world today, including Michael Meyers, managing director of Tag1, helped establish and is an advisor to the Drupal Association, a VP of developer relations, formerly at Acquia, and CTO of the first top 100 Drupal-based website. Fabian Franz is based in Switzerland, he's the senior technical architect and performance lead at Tag1. One of the five Drupal Seven core branch maintainers. He's also one of the top 50 contributors to Drupal 8 and maintainer of several important Drupal 8 core subsystems like Big Pipe, Dynamic Page Cache, and Theme API. We're also joined today in Hamburg, by Sebastian Siemssen, senior architect and lead react developer at Tag1, also known as "Fubhy", in the Drupal community and around the interwebs. And he's a contributor to Drupal for 10 years, maintainer of the GraphQL Module, and has contributed to over five dozen Drupal modules.

Today, we're here to talk about Decoupled Drupal, a topic that I know all of us have heard a lot about. Might not be so familiar with, but is on all of our minds. But first, I wanted to turn over the mic to Michael Meyers to talk a little bit about why we're all interested in this, and what Tag1 is all about.

Michael Meyers: Thanks Preston, Fabian, and Sebastian for joining us. Tag1 is the second all-time leading contributor to Drupal. We work on highly scalable, highly available mission-critical applications as well as architectural oversight and delivery assurance. Decoupled Drupal is something that comes up more and more frequently, with organizations that we're working with, whether they're integrating disparate systems like Adobe Experience Manager in Drupal, or migrating across platforms of Drupal like Symantec. Through a unified front end, they're able to pull together a lot of different systems and it's also just a new hotness. So people that are migrating to Drupal from other applications, it's one of the things that they always wanna talk about.

Preston: Absolutely, thanks Mike for that background. I think Tag1 is one of the major progenitors of a lot of the work that we have seen around Decoupled Drupal. Obviously, there would not be a lot of this availability of these amazing modules and contributed projects without Tag1's sponsorship. So, let's go ahead and dig right in, how about? And I wanna, kind of give a little bit of background, I imagine that a lot of our listeners and viewers today have not really worked with Decoupled Drupal potentially. So let's start there. I think all four of us have different viewpoints and different perspectives about Decoupled Drupal. But let's all agree on one thing, I mean we all agree that Decoupled Drupal is this idea that centers around using Drupal to consume data through an external application, and I think that's the core of what Decoupled Drupal is about. Separation of data that we have in Drupal from the presentation layer that is in a different place. I wanted to kinda stop there because there's a lot, that's a very general and broad definition, but it's not necessarily the definition that a lot of us are looking for. I'm curious, you know Fabian, how would you define Decoupled Drupal, kind of at it's core?

Fabian Franz: I think, you described that already very nicely. For me, Decoupled Drupal, that's also why I'm usually less of an advocate for it, at least not for the fully Decoupled Drupal experience is that you also lose a lot of what makes Drupal great because you're really just providing it, it's an API. It's really just an API. That's what Decoupled Drupal for me is. It's an API, and then you have a back end for content management, and inserting, et cetera. And that's still nice, but that's still cutting off a lot of what Drupal has so that's my definition.

Preston: And how about you Sebastian? I mean, you know, you've been working in the GraphQL worlds, the React world, you've been in involved in a lot of different technologies outside of the PHP landscape. Do these definitions of Decoupled Drupal resonate with you? Do you agree with this notion, that you lose a lot of the important functionality? I'm curious for your thoughts in this regard as well?

Sebastian Siemssen: Absolutely. So, I totally agree with what Fabian just said. You're definitely losing a lot of the things that make Drupal great. On the other hand, it gives you the flexibility to build something custom on top of the data model that Drupal provides. I'd like to add though, add though, that one more point that is really important for me, for Decoupled Drupal is that not only, decoupled for me doesn't only mean that you're separating the presentational layer from the data layer, but also you're making Drupal replaceable in this whole setup. So, you can only achieve that if the API itself is agnostic of the underlying data storage model that Drupal provides by default.

Preston: That's a very interesting outlook and I actually do believe that, that you know, this does threaten, in some ways, Drupal's place in a lot of the architectures that we work with. And I think it does have a lot of implications, you know, not just from a technological standpoint in terms of how people consider Drupal or represent Drupal in their stacks, but also how the community will kind of go in this direction, and what the implications are there. I also wanna turn to a little bit of the commercial side of things though. Mike, you know, you've been involved with a fair amount of Decoupled Drupal projects. I'm kinda curious you know, how is Tag1 and how have you been thinking about or considering Decoupled Drupal from the commercial standpoint and from more of the kind of customer mindset. Are there differences in how people perceive Decoupled Drupal from the point of view of Tag1's clients, or the Drupal, kind of commercial ecosystem at large?

Michael: I think it's generally considered an advantage. You know it's interesting hearing you guys talk about how there might be eroding some of Drupal's value. In my mind, one of Drupal's most powerful features has been its input/output capabilities. Sort of like the middleware of an application, it integrates really well with other systems. So, you know, the restful compliance, the GraphQL support. This only, I think, strengthens Drupal's ability to integrate with applications and then, you know, in the example that I gave earlier, historically moving from one version of Drupal to another, H9 is a very different scenario. It's gonna be significantly easier, but what Symantec did in providing a unified front-end across multiple websites has made it significantly easier to migrate over time from Drupal 7 to 8. They deprecate things, a single page to an end user can have information coming from a large number of different systems. So, from a client standpoint, the ability to decouple Drupal has been a huge asset. If anything, it's only increased their interest in the platform.

Preston: Absolutely.

Fabian: I also wanted to add to that, that we have to think about what decoupled want to define the definition even a little bit more. Because a fully decoupled would really mean that Drupal is completely replaceable, even all input/output forms. Even all content editing or whatever you're doing, you could use Drupal just as an application. In this case, it's still giving you this powerful entity system, its permission system, et cetera. But it's basically acting like a layerable thing or like a Symfony application, where really everything goes for that. While with, for example, acted more like a traditionalist aspect, the admins are still entering all the things on the traditional interface, but just the users are consuming this side and defending, but obviously you keep a lot more of what Drupal has to offer you. Then it's also less replaceable, obviously because you have full of this admin interface and everything like that and I think that that's an important distinction to make. For me, one of the big disadvantages of Decoupled Drupal is different and going the same direction as security. Plain and simple. If I have a content server, in the end, it's not my output product, regardless of how it's created. I get static HTML pages, so not even this consuming of an API, it's also decoupled, but it's even more decoupled as static HTML pages, they're pushed to some server. It's one hundred percent secure. No one can hack the static HTML pages. And, for me, that is a huge advantage of this completely decoupled thing. Yet, another part of it. But, there's not even an API anymore.

Preston: Absolutely, and I want to dig into some of the architectural and security implications here because I do agree with you one hundred percent Fabian. I do think that there are some interesting ideas that have been emerging, Gatsby of course, being one of them. I am a product manager over there and there's a lot of implications that I think we should dig into. But first, I wanna kind of introduce ourselves a little bit and our backgrounds to the audience. I think a lot of us have, we've obviously talked a lot about these topics. We know each other very well. But I don't know if the audience knows us quite as much. And I wanna jump all the way back to one of the things you said earlier, Fabian, about kind of this notion of different flavors of Decoupled Drupal. I remember back in 2015, there was that explosive, or not explosive but, you know, kind of the first blog post that Dries had written about Decoupled Drupal and where he introduced this idea of progressive decoupling. This idea that you can consume the API's that are served by Drupal, actually through Drupal itself and kind of maintain some of this functionality that we hold near and dear. But a lot of people realize as well that this wasn't exactly providing the best developer experience and over the course of time, my views have evolved quite a bit as well. I originally agreed with that kind of model and today, I think that there's really good used cases for monolithic architectures. I think that Drupal itself, that there are many used cases for people who use Drupal on it's own without any other front end, especially for users who don't have as much development experience. And there are also used cases for people that Decoupled Drupal. Just like the Symantec case that Mike just mentioned.

Fabian: The thing we were talking about was kind of like, what's kind of at stake of Decoupled Drupal? And Sebastian, I would be really interested to know what you think about that. Sebastian: To answer that question, I'd like to get back to your argument that you made earlier about Drupal and the Drupal admin interface and losing value from the things that Drupal provides out of the box when you're not working on a decoupled environment. So one of the nice things that I think actually add value to Drupal is the fantastic administrative interface and also the data model that you can craft and fine-tune and boot right around your requirements and the field API, the Entity API. These are the strong selling points of Drupal and usually when I'm talking to clients and trying to push them into the direction of building a decoupled site using Drupal, this is one of the main arguments. So you're getting a free administrative interface with all of the permissions and everything that Drupal offers out of the box in terms of access control and administrative overviews for free, and then you can build your decoupled site on top of that. And then there are multiple options of course. So you can use GraphQL, you can use REST, you can use JSON:API and so on. But yeah, for me, GraphQL. that was the time when it really clicked for me that this was the one thing that we were all missing in the API space, especially then because I was working on a very complex application using React, and it was just this one missing piece for me that totally made sense in the very moment that it was open source and announced at a conference. So, yeah, early in 2015, I then started working on GraphQL for PHP, first started trying to build a parser library on PHP. The NodeJS the Javascript implementation was just open source, and then yeah, quickly after that we started working on the GraphQL module for Drupal. I think we started releasing that on D.O in March 2015 and ever since then we have been working to try and find the right model. We're still working on that, but it's getting there.

Fabian: Yeah, I think that that's really interesting. And I totally agree. I think it's one of the hugest selling points is Entity and Hewlitt API, and they're currently pursuing a project in Laravel, and in the Starboard project one of the first things we're kind of doing is at least putting some light layers in that resemble these concepts of an entity and these concepts of feel, because it's just so powerful that a feel that you define it one and can validate itself and all of that setup also works with slide APIs your are consuming. So yeah, totally agree. And so my point was kind of like, you are only losing all the stability to use, Drupal just as an application, really just using the input output and then, but then as soon as you start to do the admin phase, you have much tools to still work with in that, and really great. And one question to look after, because any one task that, so GraphQL basically means the client can do the query, and kind of determine how it wants the data model that's stored on server look like on the client. Whether that be a layman terms definition, or am I totally off.

Sebastian: One way to describe GraphQL that I like very much is that the GraphQL contract defined in the GraphQL schema turns the responsibility between the client and the server, so the consumer and the data provider upside-down, where the server through the GraphQL schema defines the possibilities, the data possibilities that the server can fulfill, and the client from these possibilities, per request, defines exactly what the client or the consumer needs. So the client sends the query to the server in a specific format, and this format is, you can think of it as the JSON that you want to have returned from the API, but only the keys of the JSON. And then the server fills in these keys with all the values, and you're presented, when the response comes back you're presented with all the data in the exact same shade that you requested it in.

Fabian: And I have a really quick question because I always want to know that one of the other things that I really like about Drupal itself is the entity reference system that can be used when you have ten layers deep obviously, but if I have entity references, can I make great use of some of this GraphQL as well, like going deeper into spectras? Sebastian: This is exactly the point of GraphQL. As you can see already by the name, it's all about graphs. And all the data, no matter how you want to look at it, all data is always a graph, and especially in Drupal, we have deeply nested relational data structures, and so these are all definitely 100% suitable for modeling them into a graph. And yes, of course, you can traverse in this data tree and follow entity references all the way down to however many nesting levels you want. There's actually nice notion in GraphQL for schema and crew validation where you can prevent DDOS attacks against a very complex crew with high amounts of nesting layers by checking the complexity of the query ahead of time before executing it. Because potentially, of course, you could query for a list of 100 nodes with a reference field in them, and then go down multiple layers and then the listing becomes exponentially more expansive. So with the complexity--

Fabian: In the end you will have whole databases.

Sebastian: Exactly. You could totally do that. Of course, that's the question that gets asked quite a few times, on ICQ, how do you prevent complex queries DDOSing your servers? And that's exactly how you'd do it. Analyze the query ahead of time, and you can easily do it because the schema and the query schema are predictable, so you can look at the schema and the query ahead of time and analyze it using visitor's rules and patterns.

Preston: I think that that is one of the examples of how we've seen GraphQL take on this amazing reach not just in Drupal, but across the JavaScript community. People really love GraphQL. I love GraphQL, I use it all the time, and it kind of really is making me realize that we've opened the door with Decoupled Drupal to a lot of different API specifications, a lot of different, there's now more web services that people can use with Drupal. One example is JSON API, obviously, and Core. We have GraphQL thanks to the efforts of Fubhy and others, and we have others as well. And one of the things that I wanted to ask is, there's so many of them out there now, now we have relaxed web services, it seems like there's less and less standardization around a single one. Obviously JSON API is now on core. I would have liked to also see some more adaption of GraphQL in the Drupal community as well. So I'm kind of curious, and let's start with you, Sebastian, how do you feel about GraphQL adoption in Drupal. How do you feel about where Decoupled Drupal is today right now, and the implications for you?

Sebastian: I mean, just by looking at the usage numbers on Drupal.org, you can directly see that JSON API and GraphQL are definitely not the same in usage count, so that means JSON API has more users obviously also because it's in Core. But on the other hand, I think one of the main reasons for that is also the documentation which is excellent for the JSON API module. I have to give them a big shout out for that. In GraphQL, I think if you are coming from the React side, you are likely to be already familiar with GraphQL. So a React developer that comes to Drupal and has Drupal as a back end or a potential back end, they are more likely to look at JSON API and React and GraphQL and then maybe make a decision for GraphQL just because they are more familiar with GraphQL already. But for users that are coming from the Drupal spheres, I think just because it's in Core and also because of the excellent documentation, I think you're more likely to go with JSON API at this point. There's also another hurdle that we have created with the newer version that we are working on currently, the GraphQL module version number Four, where the schema is absolutely 100% in your own hands, so you have to create your own custom schema with your own custom code, which is also my big selling argument for GraphQL because you get to define the schema and you get to decouple Drupal actually on the data access on the API on the contract level, and you're not pushing the data model of Drupal and the data model internals of Drupal onto the consumer applications.

Preston: I personally am very excited for the V4 release of GraphQL, and I know that a lot of people have been requesting those features, Sebastian. Before we jump into more discussion about where we are today, Fabian, how did you get involved in Decoupled Drupal and why is this topic interesting to you? Fabian: So I started my first decoupled site in 2009. Out of necessity, all of the sites I built at the time that was pre my Drupal career made them seem simple and the gist returned at a certain past and answered an HTML snippet, but I still call it decoupled because besides that I just had a static HTML page. And the reason for that was that my now wife, at that time girlfriend was graphics designer. We were building sites together, and she was designing these words and graphical things, and it's really nice and slick with animations and everything, and some of the data could come from there was maybe we were pretty early for web animations, everything else was Flash at that time. So that's why the sites had to be decoupled because they were getting their data, they would basically photoshop JPEGs in the end that were painted, so all of those data needed to come from remote, so that's how my first decoupled site started, basically.

Preston: I love that it was kind of an unintentional fall into Decoupled Drupal for you. I remember those days writing action script and trying to work with how to combine these technologies. It's really amazing how far we've come. How do you feel about the present? We've heard from Sebastian that a lot of the current state of how much these web services and tools have really changed the way that we look at how we handle data in Drupal. Obviously now with GraphQL V4 there will be a lot more features to come. I'm kind of curious, how do you feel about where Decoupled Drupal is today? Do you feel worried at all? Do you feel excited? What are your thoughts on where we are in the Drupal community today?

Fabian: I feel pretty mixed overall. I've also seen, in one side I love it. In the other side I'm skeptical, because it's always like with, also with my own decoupled sites that I've done for huge times and check one, you always lose this administrative functionalities. Fortunately for this particular project, I was able to bring for example contextual links back, which is pretty cool. So you still have the Gatsby like this generator of HTML in the end, but we also generate all the JSON on the fly, in this case custom made because data model was really, really simple. So JSON API, whatever, would have been just overkill. That's also Drupal7. And so we consume all of that, and then we are still trying to export all of this functionality that Drupal is so nice about, the contextual links that have edit links for administrators to be working on the page. And just to integrate that into this decoupled application, that later just static HTML. That was kind of challenge for them, but that's interesting. That's the kind of challenges that's interesting for me. But the common state, I think Drupal is an excellent API for mobile applications and all of that. I'm not sure I agree with the current state of where people are either completely decoupling or completely not decoupling. I think one of the large mistakes we basically made in Quora and where the JavaScript world is on a completely different page is that we are mixing data trees and presentation like within our render arrays and within our structures and within our entities and all of that, which makes it so hard because one of the things working on the kind of project I see more and more is like, there's this huge disconnect when you work with the React community and React developers, and then you work with pure back end Drupal team layer developers, and it's like two different languages, and I think it's very important to bring both of those back together. And for me the huge answer for that and also the challenge and the thing and I'll be talking at DrupalCon about that is spec components.

Really to have everything based on components and interestingly enough Drupal6 has been further along with that than Drupal8 or 7, because it had much more narrow and strict definition of how things would be like a component matching today, and also how we, do we integrate this JavaScript and then I think that would be a really cool thing in that you have your normal site, but then you have a component, and that component only cares about where it gets its data. It doesn't matter if it's on the front end, if it's on the back end, it just gets its data from somewhere. It can be Drupal's data model, it can be GraphQL, it can be JSON API. But we need to do the same, and that's the point where Drupal is not going far enough for me. We need to do the same on the back end as on the front end to have something unified that can be combined in that, with obviously still a nice development experience, so it should not be that you need to learn something completely new or something that you need to combine those technologies with. We need to bring front end and back end further together, especially as I think those web components are so important. So that's my thoughts about that. And I will be talking more about that at DrupalCon.

Preston: Well I'm definitely looking very forward to seeing that session, and a brief plug for that session, Fabian. You're talking about web components at DrupalCon. I'll also be talking about live preview with Gatsby in Drupal. Sebastian, do you have something on the docket for Amsterdam as well?

Sebastian- I don't, I'm not even going. I'm currently personally involved a little bit because I'm moving back to Vienna in January, so I don't really have the time right now for conferences.

Preston: Yes, totally understand that. Life always gets in the way.

Sebastian- I'd like to expand on the thoughts of Fabian that he just shared with us. So I would actually say we have to split the back end and the front end and Drupal on the current level so much further apart from each other. Right now there's so much weight on Drupal and also that's a performance concern not only for Drupal on the admin phase, but also on the API layer. So whatever API solution we build, always also drags along all of the weight of the entire Drupal environment, and always loads and runs through the same logic that is used also for presenting non-HTML pages and rendering them with Twig.

I think it would be really beneficial for Drupal to actually fulfill this dream that we all had a few years ago when we started with the API first initiative where Drupal itself, at its core, is only a very slim kernel that provides all of the low-level functionality like entity API field, API et cetera, but completely isolated from any of the UI layer components. No widgets, nothing. Just the raw data model and the routing layer and so on, but even that without all of the administrative routes and so on directly built into the system. And then on top of that, there would be another component for the administrative UI that uses a slightly bigger kernel with the other components on top of it, and another layer that could be completely replaced with is the front end layer, and that could be entirely replaced with a PO or API layer, so just answering with JSON from API resources that you define, for instance, a single one with GraphQL or multiple ones that are defined in JSON API. This would also add to security because you could then completely split up the routing at a much higher level and even have the HTP server route the requests to different run times based on the path that is sent.

Preston: Yeah, Sebastian, that's one of the things that I think is very important for us to consider, is that Drupal has become this really large monster that is many things to many different people. We talked about how many people use it because they want to edit content, many people use it because they want to consume the APIs, and I think there is a lot of concern about the fact that we've never really Decoupled Drupal itself to a large extent, and you made this very clear earlier when you said that even Decoupled Drupal itself is a misnomer because we're not actually decoupling any of the functionality within Drupal. So I'm kind of curious, Fabian, what are your thoughts on this and where do you see all of this going?

Fabian: So I think for me it's important, okay, let's go a little bit into the ideas that I have on that. First of all we have to take a look at how the JavaScript community does it. How does the right component look, how does a left component look. And if you look, or even a group component that's really simple to understand. And it's basically a CSS HTML JavaScript on the front end of things. But the other part is that for me then there's something else, and that is data. And usually those data and most of those front end technologies I've worked with so far is just a data tree where you get your data from somewhere. And that's not bedrock police internally because you have a render array which references an entity which is an object which is backed by a database table but which has stored its data already. And which has its spheres which already need for all the input and all of that. But it's not what you need. Or you have a recent content block and it's a view and it outputs data and it's HTML and that, but that's not what you need. What you need is you need this graph approach that Fubhy is talking about, but I'm thinking more of it in terms of performance that you have a graph approach where you put your data in, where you put, for example if I have to say, my favorite links block, whatever, then data storage is cheaper, as long as it's fast.

So for example, whenever they do their changes as variants, I change those data tree from this user to update his favorites. And then I just have the data of what this user's favorites are, for example, what he rendered, or whatever. And then I have just data, and this data can be consumed by the back end or the front end. And that's what I mean by you need to decouple the data from the objects itself. We have everything mixed way too much together in that. But what we need to render things is pure data, and that's what we're not having right now, in my opinion.

Preston: Would you say you agree with that, Sebastian? What are your thoughts on that as well? The decoupling of data from objects.

Sebastian: Yes, I agree with that. There's also one more thing that I think is a big problem in Drupal and especially the rendering pipeline in Drupal is currently it's entirely push based, so when Drupal is working on a request and is working to fulfill such a request, it runs a gigantic processing engine to pull together data from various sources and then feed them into templates, and then the template picks out just a small fracture of the produced data to render the output. Instead, I think what we need is to turn that entire rendering pipeline upside-down, where only at the very end you are essentially pulling the data from the graph as the engine and as the template needs it. So I think a great benefit would be to turn the templating engine or the rendering engine from a push based approach to a pull based approach.

Fabian: And that's exactly where I want to go with web components approach because this pull based approach would become naturally like that. You have a navigation bar, you just put in nav bar. Like nav bar for my enterprise. And then wherever I need to use this nav bar I just use this nav bar component. And then it just has the data for this nav tree comes from somewhere, and it can come traditionally within Drupal, like with data, it can come from GraphQL, it can come from anywhere. And that's why I think this web component approach is so powerful both from the back end as well as for the front end, because first of all, by having those components consuming the same data, we make them interchangeable, so we make decoupling way, way, way easier. We make progressively decoupling easier. We make performance simpler. And also with this pull based process is saying, we don't need to do all this stuff, we only need to do a few tiny things. It's also where my whole performance model of Drupal 8 was based on, basically. Then we have all those little things that are like where we have place holders for the truly dynamic things which can later be kind of like pulled from where it is, so there is the whole idea that we don't need to build all these pages, et cetera. Here just was a caching approach instead of a data based approach. But instead we just have to regenerate really what has changed on this page, and obviously with a pull based approach you get this part for free.

Sebastian: It's also interesting to note that this pull based approach is exactly what an API first architecture would look like because that's also what you do when you query data over an API, you pull exactly the data that you want, and that's what GraphQL for example is so powerful at. You specify exactly what fields for the API you're interested in, and then you only get back those in return, and the server only has to work on these. The server doesn't produce any overhead data and only then when sending that information filters out all of the things that you didn't query for. It actually just produces the data that you asked for.

Fabian: Yeah, that's a cool what I think what a web component could have, for example, a web component could have a data connector, and one of the, back end web component could have a data connector, and this data connector could for example be GraphQL so I could be eating my own dog food in the back end as well without all the problems that we're having, but I just defined this backend component once, and then where my data comes from, how it is generated, is basically up to the developer, but I can use all these API first tools and I think that's where we need to go. Not as much as we need to rework all the admin interface in React, that can come later, but instead we need to work on this pull based approach really being API first in ourselves and get away from this traditional page based model.

Sebastian: Absolutely. Philipp Melab, one of my colleagues, actually built a small prototype module that brings GraphQL into Twig, so you can use GraphQL for rendering data in your templates. That's a very interesting approach and should probably be something to look at.

Preston: Absolutely, and I know that there was also a webinar about that recently, by the Amazing Labs team around GraphQL and Twig, as well as several DrupalCon sessions. Just to bring this back to an interesting topic that I know we all are passionate about. One of the things you mentioned just now, Fabian, was really about this tension between static content and dynamic experiences. One of the things that I know with this trend towards people using Gatsby and rendering static sites, that's all well and good, but a lot of people want more dynamic experiences that are computationally much more complex that lead to a lot more struggle from the standpoint of infrastructure. I'm curious, how can we enable not only the vision that you're describing with web components and Sebastian, your vision for a more pull based model with API first, is that gonna enable things like real time Drupal? Or is there still a long ways to go before we can even begin to talk about something like having real time functionality built into Drupal itself?

Fabian: For me it is the road to real time Drupal and that's also why my session is called the Road to Real Time Drupal. Because I think our plan and components everywhere approach would allow exactly this, that we can go there. And what you were talking about first of all is something that I disagree with because I think static HTML pages, they don't need much interactivity. They usually don't have that much interactivity. What you have is you have interactive components on those pages, which is sometimes dynamic like a discuss widget for comments like a feed widget for the news that you want to have actively, a stock ticker, whatever. And then those are the important things that are there. But once we have a component based approach, then the nice thing about it is because they are data based and all react components already react today to changes. All you need to do is you have something like an OJS server, React PHP, whatever is pushing data, web sockets, pull based, haul based, however it gets, it's just data. And as soon as the data is updated, your component gets updated, and that's how you get into the real time field. That's for me the thing in that I'm not thinking of things like this is statically rendered HTML, whatever, but I think of things like this can be rendered on the front end, on the back end, and because it can be rendered on the front end as well, if data changes, I automatically get the real time functionality, and as long as I have a graph based approach where now, when, what in the graph changes.

Preston: And how does, Fabian, the picture look for GraphQL with web components? What does that approach look like?

Fabian: Actually I defer to Fubhy in that. Bisbacked, well, I just combine my component with that. Probably an NodeJS server could tell me something about the data has changed and I do a new request for that, but that would be my naive approach. My approach for that whole thing would be to be more like a database JSON push based approach where an NodeJS server is pushing the changes on my data tree that I'm interested in to me, so I know if something has changed, but how you can combine that request really is a question for Sebastian.

Sebastian: So whenever you are talking about real time data we are talking about a solution on top of Drupal because it has to live in a non-PHP environment, otherwise you cannot support web sockets because Drupal is, or PHP is not demonized, so it doesn't automatically give you the ability to push real time data to the web socket connection, for instance. One option for that, for instance, would be to combine an OJS server and the Drupal PHP environment for instance with Redis or with a push based approach where Drupal, wherever data saving or data mutations occur sends a notification to the OJS environment through an API call, for instance, or by pushing into the pub sub environment like Redis or Kafka. And then an NodeJS can update the data through a web socket on the clients. That means in that case you'd be also communicating between the browser and the NodeJS server and not directly communicate between the browser and the Drupal environment. So that means you'd move the API components, so in this case GraphQL to an NodeJS environment. There is a couple of different ways for solving that without losing the ability to use GraphQL directly from Drupal, which gives a few nice benefits which is for instance the nice kick and the granular caching that you can achieve if you have the GraphQL server very close to the data source. The closer the data source is to the GraphQL API, the more optimization you can do in terms of caching but also in terms of optimizing the database. So you definitely want us to keep that, but there's work being done for instance by the team around the Apollo client that is called Apollo GraphQL Federation, for instance. There's also a schema stitch which is the older approach where you can forward GraphQL queries across multiple edges and combine multiple GraphQL schemas into a single one, for instance. That will come into play here. And then in terms of real time data, yes, web sockets would be the best approach here. Pulling always comes with its own complexities and also performance problems. With web sockets, GraphQL does have web socket support. You can use a special key word in the GraphQL query which is called the subscription, and then you can subscribe to updates that are then handled by an event emitter using the observer pattern in NodeJS, for instance, and that works actually very nicely. There's currently also work being done in the GraphQL spec where you'd be able to send queries and subscriptions in a same request, so you can send a GraphQL query, get the data and the response and automatically also open up a web server connection for a couple of the fields that you want to get future updates for.

Preston: That sounds incredibly exciting. I think that that really, this kind of approach is really kind of the future that I want to see definitely in Drupal. Since we're running out of time here, I want to kind of bring things back to our viewers and our listeners, one of the things that they're really interested in is how can they help with these two ideas. For example, helping out with GraphQL v Four. Fabian, you've obviously got a lot of ideas about web components in Drupal. How can, let's start with you, Fabian. How can people help you in terms of realizing this web components based approach that sounds awfully compelling, but needs to be made a reality?

Fabian: First of all, come to my session, challenge my ideas, point out the problems about it. Point out the drawbacks and tell me it's only feasible. No, really, if you want to come to the session it's on Tuesday . Afterwards there's a press session. You'll find it in the schedules if you're there, but you'll really have to be there we can have a nice question answer session and talk about it and really, I mean, I've been able together with Wim (Leers) and Acquia to really help shape performance and things work with Drupal and that we can have more things like that. Maybe you can make those happen here as well. This is the first time I'm presenting it, so I'm assuming it will take some time.

By the way, Big Piper's presenting at Amsterdam, so it might be good for strengthening originally which make a lot of those changes in the end. But yeah, that's one of the things I'm really passionate about is this real time aspect. This background components aspect and how we can streamline develop and make it easier and still keep all the Drupal what makes Drupal so great, so nice, so cool to use but still have a much, much better experience and be ready to not be overwhelmed by these new front end technologies where we are starting to age more and more. I see it similar to how we made Drupal 8 kind of like on this object oriented approach to really see the new patterns. I'm seeing here a new pattern within the front end world emerging and I think we, as Drupal, need to be ready for it.

Preston: That sounds great, thanks Fabian. I know, I'm looking forward to your session and all the conversations we'll have in Amsterdam. Sebastian, how about on your end? Obviously there's a huge initiative that needs to surface around real time Drupal, but for the smaller steps to get there, how can people help you with your vision around GraphQL and enabling some of these future priorities?

Sebastian: As you know, much of development is always a chicken and egg problems. So you first need a client that needs the module so pushing the idea of using React and GraphQL with Drupal as a backend is already a good help because then the more adoption we have the more contributors we attract. But also if you're interested in contributing to the module directly, there's a load of ideas that I have that would be very beneficial to the module that we currently just don't have the resources to do ourselves. So if you're interested in contributing to the module, feel free to join us on the Drupal Slack. We have a channel there, it's just called #GraphQL, and yeah, reach out to me on Slack.

Preston: And by the way, if you are less knowledgeable about Decoupled Drupal, want to find out more, want to learn about the building blocks and base level components or some of the ideas around Decoupled Drupal, I also have a book that's out called "Decoupled Drupal In Practice," with I believe actually all of us on this call are mentioned somewhere in the book, so we can do a bit of an Easter Egg hunt to look those names up.

Anyways, we are out of time. I just want to say thank you so much to Sebastian and Fabian and Michael, I know you all took a lot of time out of your busy day to be here with us. Our viewers appreciate it, our listeners appreciate it.

We post all of these Tag Team Talks at Tag1.com/tagteamtalks. And all the links that we mentioned today, all of the things that we mentioned, all of the resources that we mentioned will be online with the talk alongside the YouTube video, alongside the blog posts on tag1.com.

By the way if you liked what you heard today, please remember to up vote, subscribe, share it with your colleagues, share it with your children, share it with you grandma, share it with everyone in your neighborhood, and if you have any ideas about things that you would like us to talk about next, please send us an email at tagteamtalks@tag1consulting.com.

Once again, I want to say thank you so much to all of our guests today who are hailing from all around the world. Sebastian in Hamburg, Fabian in Switzerland, Mike in New York, and this is us signing off of Tag1 Team Talks. Thank you from London, and have a great rest of your day.