Talking Drupal #531 - Drupal as an Application Framework

John: This is Talking Drupal, a weekly chat about web design development from a group of people with one thing in common.

We love Drupal. This is episode 5 31, Drupal as an application framework. This episode of Talking Drupal is sponsored by a amazing ai.

On today's show, we're talking about Drupal for applications, types of applications Drupal can build, and how we change how we can change our thinking of Drupal with guests, Alexander Varwijk and Jurgen Haas. We'll also cover Drupal Remote Dashboard as our module of the week. Welcome to Talking Drupal. Our guests today are Alexander Varwijk and Jurgen Haas.

With over 20 years of software development experience and background in business administration, Alexander enjoys working on complex strategic projects. He currently works as the technical architect at Open Social, helping teams push Drupal to its limits in the world's only sovereign community collaboration platform.

He also co maintains various Drupal modules and is contributing to an. To asynchronous Drupal Alexander, welcome back to the show. Thanks for having me. Oh, sure. Jurgen started back in 2007 with Drupal four six founded Lake Drops, a Drupal agency in Germany, and is known as a maintainer of a number of modules like ECA.

He's a co maintainer of the gen admin theme that he helps to, helps to migrate into Drupal core. His passion for privacy and security got him to contribute to Drupal CMS for those topics. Jurgen, welcome back to the show. Hey, thanks for having me. I feel like we probably should have mentioned you're working with the Drees on orchestration too, that like we kind of buried that lead, right?

Yeah, I did actually. That was a busy summer really. I'm, I'm very interested in that. Maybe we'll talk about it a little bit more later. I am John Picozzi, solutions architect at EPM and today my co-hosts are joining us in our guest host, seat

Fei Lauren, delivery Manager, process architect at Renaissance Electronics America. Faye is a digital nomad from the west coast of British Columbia. After a decade as a Drupal developer, they now work with multidisciplinary enterprise engineering teams to streamline processes and architect scalable automation systems.

Having recently finished their tenure on the Drupal Association Board of Directors, thank you for that. They're excited to bring that knowledge back to their work in the community and beyond. Faye, we're excited to have you and welcome to the show. So excited to be here. And last, but certainly not least, in a snowstorm right now.

Nick Laughlin, founder at Enlightened Development.

Nic: Happy to be here. Yep. It just started snowing actually. I think we have, we're, we're supposed to get 11 inches. Thankfully it's reduced a little bit. We're both, we're supposed to get hit with five, but yeah, we got about an inch on the ground. I was

John: hoping you would take us outside to see the, the accumulation, but it doesn't appear that there is any, so nevermind.

Okay, before we turn it over to Martin, I do want to put a shout out in here to James Shields, who is running the Drupal Advent calendar. It's back for 2025. Super excited about this. Unfortunately, James. Got a little bit of, of the cold, sickness, flu thing and couldn't, couldn't go with his original idea for the advent calendar this year, which was focusing on you know, initiative not necessarily initiative leads, but people that are pushing Drupal initiatives forward, kind of behind the scenes.

But instead he came up with a brilliant second idea, which is highlighting great sessions from Drupal events. And he is he is on day two now. So there are two of them up there. So you can go to the advent calendar. We'll put the link in the show notes for you, and you can see two great talks from two Drupal camps.

So he'll by the end of by the end of this, he'll have 20, 24, 25, 25 probably, right, videos and, and writeups about Drupal. Event talks, so check that out. 24, right? So, 'cause you don't actually do Christmas in an advent calendar. It's leading up. Come on, learn how those things work, John. All right.

Now to talk about our module of the week, let's turn it over to Martine Anderson Klutz, a principal solutions engineer at aa and a maintainer of a number of Drupal modules and recipes of his own. Martin, what do you have for us this week?

Martin: Thanks John. Have you ever wanted to manage and monitor a portfolio of Drupal sites from a single interface?

There's a module for that. It's called Drupal Remote Dashboard, and it was created in January of 2010 by one of our guests today, Jurgen Haas of Lake Drops. It has a 4.1 0.7 version available, which works with Drupal 10 and 11. It is actively maintained and has security coverage, and there is also a full documentation guide that we'll get into a little bit more as we go through.

Now, it has 22 open issues, three of which are bugs against the current branch, which is pretty good considering it is officially in use by 126 sites according to drupal.org. Now with the module installed for each monitored site, you'll be able to review information like the version of core modules and themes as well as the status report.

Note that the dashboard and monitored sites do not need to be on the same major version of Drupal Core. You can also collect any block from a remote site to include on your dashboard or access the error logs to review them in the dashboard as well. Mm-hmm. You can execute maintenance tasks like taking sites in or out, maintenance mode, running kron, or update PHP, as well as Flushing cache.

The dashboard will also allow you to rebuild job schedulers. Update translations from drupal.org, change user credentials or execute arbitrary PHP code. So you'll definitely want to be selective about who will have access from the collected status information. You can show a status widget for each domain to display grouped traffic, like status levels for security, health tuning, SEO and others.

You can also create aggregate status widgets, for example, to show the composite health of all sites in a multi-site installation. Internally, DRD is built around a number of entities and the documentation includes an architecture page with an entity relationship diagram. While the glossary page includes a description for each of the entities and what Drupal site information they map to, obviously, security for this kind of setup is paramount.

And there's a documentation page that details the encryption and authentication methods that are supported. Sites that you want to monitor will need to have the DRD agent module installed, which provides a simple wrapper to receive, route handle, and respond to requests from authorized Drupal remote dashboards.

It's worth pointing out that the DRD agent module is in use by 3,152 sites according to drupal.org. So there may be a small number of sites acting as dashboards, but on average each of them is monitoring 25 sites. So let's talk about Drupal remote dashboard.

Nic: So this is actually pretty exciting. I, I have.

Two questions. One is, is the PHP execution a submodule that I can disable and remove? Because from a security standpoint, I, I never want to be able to remotely execute PHP code.

Jurgen: It's currently not a sub module to be honest, but I can see the point and if not already possible, I actually can't remember myself.

If it's driven by a permission, probably, and then you could turn it off. Otherwise, it is just a plugin and we could just remove the plugin or disable it somehow, so that shouldn't be blocked. Okay. Sounds like

John: Nick could create a patch for that if he so wanted to.

Nic: Yeah, I might, I might, I might have to do that.

And then the other question is it sounds like the dashboard is more of a poll. Architecture. So I could run this like locally on my machine and monitor, but not have to have it somewhat hosted somewhere. Does that, does it work like that? Can I monitor my sites from a local like d dev instance?

Jurgen: Yeah, that's exactly it.

The, oh my God. What you need on the remote side is really just an agent that responds with render arrays from the remote side, which are requested from the dashboard, and it doesn't matter where the dashboard is running. So yeah, you can keep that local to yourself.

John: I'm gonna, I'm gonna ask a somewhat cheeky but kind of serious question.

I'm noticing that this module is almost at this point what, 16 years old, right? Mm-hmm. I'm wondering like in a future version, like any plans to like do some AI integration here where like I could ask Drupal ai, like which sites need to be updated and it would just kind of list them out for me.

Like, I feel like that would be kind of cool.

Jurgen: To be honest, I don't have future plans for it other than continuing to maintain it and keep it up and running because yeah, it's 16 years old and back then, well, overnight. And you're

John: also a really busy guy with other things, so understand. Yes.

Jurgen: But technically, actually, if I had to start today, I wouldn't start with DRD again.

I've done it this way 16 years. Before, because there was nothing available that would've done the job for me. But today there are so many monitoring tools around that. Probably doing it in Drupal isn't what I would do today, but every time I mentioned that, I would probably turn down to minimally, minimally maintained.

I get so much pushback from all the people using it, so it obviously still has value. So I keep it up and running for as long as people want to

John: use it. So, I mean, I, I feel like it's got tremendous value, right? Like, just in the instance that Nick just mentioned, to be able to spin up a local d dev and, and be able to monitor your sites in that way and, and kind of do that.

You know, that that kind of remote administration, those small remote administration tasks that Martin highlighted, I mean, I think that's, that's extremely valuable. I mean, I, I know that like, you know, you know, in my head as, as Martin was describing it, I'm like, oh, that kind of reminds me of Acquia site factory.

But like, you know, that's, that's like a paid service, right? So like to be able to do this on a kind of like open source free scale, I think, I think is wildly, wildly valuable. But just my, just my 2 cents.

Jurgen: It looks like a few agencies feel exactly like that and continue using it. The challenge is that a lot of things in Drupal are changing dramatically. Think M knows about those areas a lot and just, yeah, I mean, he is the

John: catalyst for most of those changes. Wouldn't say

Jurgen: there is one API, which is for example, collecting information from Drupal org about available updates to all the modules that you use on all your remote sites.

Now that API has been changing a bit and as we are supporting Drupal 7, 8, 9, 10, and 11, it's kind of a challenge more and more to aggregate all that information into one overview so it becomes a little bit more time consuming There. Maybe I can send an invitation to people listening to the podcast that I would really love to get some people probably helping out with all that.

So what,

John: what, what's the need to support those kind of legacy versions of Drupal? Right. Is it the fact that you just wanna be able to use that kind of agent module to phone, phone back to the, to the dashboard? Or is it like, is it that people are using this to kind of like monitor their, like Drupal six, seven, and eight sites?

Jurgen: Well, it's not six anymore, but it's Drupal seven, I think it's about 25% of all the agent installations are still on seven. Wow. So it would be tough to cut that one off. That's certainly not a number that's growing. So it's, most of it is really in the new era, but in the modern,

Alexander: yeah.

Jurgen: Yeah, keeping up with

John: all the changes is difficult.

This, this just proves that Jurgen is a, a nicer, a nicer person than I, because there would definitely be a notice in the next version that was like, Hey, we're discontinuing, you know, Drupal seven support, like you got, you know, three months, six months, whatever. But you know, that's, that's why you're a better person than I.

Well, Martin, as always, thank you for bringing us a very topical module of the week and a very interesting module. We get that. If folks wanted to suggest a module or just connect about talking Drupal modules of the week, how could they do that?

Martin: We are always happy to discuss potential candidates for module of the week in the talking Drupal channel of Drupal Slack.

Or folks can reach out to me directly as man clue on all of the Drupal and social platforms.

John: Thanks

Martin: Martin.

John: See you next week. Alright, see you then. Thanks.

This episode of Talking Drupal is sponsored by Amazee.ai. Are you worried about sacrificing data privacy for the convenience of using ai? The team at Amazee.ai believes you shouldn't have to. That's why they're, they've built an enterprise grade private Drupal AI provider that doesn't compromise security or data sovereignty am amazing.

AI is a hundred percent privacy focused, letting you choose the region where your data is stored and processed. They don't store your prompts, they don't use your data to train models, and everything is fully open source so you can verify it yourself. You can even run the AI on your own servers or cloud accounts.

With their purpose-built Drupal AI provider, it's simple. To get started, just install the Drupal AI module and pick amaze AI as your provider. With advanced AI tools, you can generate or simplify your site's, content generation, alt text, and supercharge search, all while keeping your data and your user's data completely private.

Amazee.ai even offers a 30 day free trial with no token limits, so you can experience how AI can make your Drupal site smarter and faster without the privacy trade-offs. Visit Amazee.ai today to get started.

So I'm super excited about today's topic because for a long time I've kind of like looked at Drupal as kind of the glue between a lot of like business applications and a lot of, a lot of different you know, ways to connect disparate systems, right?

So like part of that is connecting to your website, but not always, like just for websites, right? And today's show, we're talking about application using Drupal as an application framework. So, really excited to figure out how we can like, you know, lift Drupal up. Not that it needs much more lifting, but to kind of like, you know, that level of like, eh, it's not just for websites anymore, folks.

So Alexander, I'm gonna start with you and just kind of say like, when we say Drupal as an application framework, you know, what exactly does that mean to you?

So, I mean, I, I see Drupal as like a, a glue bringing a bunch of business systems together and, and allowing for data sharing. And part of that is, you know, website content, you know, display, right?

But also sharing data with, with other, other business systems. So not so much, not so much specifically for the website, but more as like a, a traffic cop for those kind of data sources and, and that information that, that I would

Alexander: absolutely agree. I, I think the, the reason I say specifically Drupal as an application framework is that when I go and talk to people, they usually say, when they start describing Drupal, Drupal is a CMS or maybe even a content management framework.

And I think. Ever since I started using Drupal, I've always been very specific about saying it's the content management framework. And more recently, I think it's just a data management framework. And I think last Friday I was actually at Symphony Con describing Drupal to developers who were not as familiar with Drupal.

And if you talk about the things that get other developers excited, then I think Drupal has really great ways of structuring your application, of defining how modules talk to each other, how you describe your data so that any module can can work with it. But then I think at the end of all of that, Drupal is still very focused on working through a request.

Realistically, if I need to solve a problem, then all of those tools of how the database works, how you model your data, how you bring different pieces of functionality together, they're all great and you don't really need a request for it. You could have some kind of background process that just does what you're describing and integrates different data sources, but only really does some data processing or churns through it.

Nic: Yeah. Yeah. And we, we have cer certain hosts have built ways to do this, like that kind of faked it. Right? Upson has workers and it basically sets its own front controller and, and creates kind of fake requests to run it. And it just, it kind of just runs as whenever it's available. So you're still kind of running into that issue where you don't have a lot of control over what's happening when but yeah.

Can, can you describe a, maybe a little bit more what you mean by application though? Like what kinds of, use cases, can an application do that Drupal kind of doesn't, doesn't cover at the moment.

Alexander: So, so it can be very broad. I think for me specifically this idea started maybe four or five years ago when I built the realtime chat for open social.

And as part of chats, you wanna be able to push messages back and forth without the user having to refresh their page. You can do that with web sockets, but then you need a long running process that keeps these connections to the browsers open. And that's something that's very different from a PHP application that hangs behind a web server that needs to be a standalone application that manages those connections.

That's currently. Really difficult, if not impossible to do with Drupal. And I basically faked it by doing something similar, what you mentioned with workers, which is just having a separate application that just made requests continuously to the Drupal site whenever it needed data. I think a, a very topical way would actually be ai, where if you look at more long running AI processes or having AI agents orchestration, that's not triggered by a user doing something in a browser, but maybe being behind an MCP server then those are also these kinds of long running processes where you're really gonna process multiple tasks.

John: Yeah. So. When you're, you're talking about this, I'm gonna, I'm gonna actually shift the, the same question to Jurgen, but I wanna bring in some of the stuff I talked about in your intro, right? So like, when I think about kind of Drupal as an application framework, I think a lot about your, your work with ECA your, the new work you're doing with Dries on orchestration and, and tying that to, you know, a service.

Like, is it active pieces? Is that the one that the one, right? Yeah. Like that all feels very very like, Hey, we're moving to like more of an application framework sort of mentality than a con, just a sole content management mentality. Would you agree with that? Absolutely.

Jurgen: And to me, this is not a new thing.

I have focused on that area ever since I started with Drupal myself and on. In addition to what Alex talked about with technical components that are required for, for example, long running processes I'm looking at it from a point of view. What is the value that the Drupal side actually delivers?

And traditionally, we as a, we as a Drupal community, focus a lot on marketing, right? Marketing of our project and ourselves. But Drupal websites are used for marketing purposes. You know, a website delivers branding product information, other, and even if it's a blog post or a, a blog page, like this is marketing of the person that is behind all that content of it.

Now, in contrast, Drupal as an application is to me. As soon as it delivers more value in terms of, for example, if we build an intranet where a company is organizing their onboarding, offboarding reporting, and lots of other things that is far away from marketing. It delivers value to optimize internal processes.

It helps people to do their job. It even can integrate external stakeholders to the process and so on and so forth. I can give you lots of examples about that, and I think this, in my terms, is an application and we have so many opportunities. Where we can build more tools to make that possible. But even with what we already have, I think the market opportunity is huge, but we are currently missing out on it.

Only think about, you know, Drupal CMS. What is the target audience? It's marketeers, right? If you listen to the activity of the AI initiative, it's all fantastic what they're doing, but all the minutes that you can read about their process is focusing on how can we make the daily life of a marketeer easier than it has been?

Well, marketing probably it's also an editor, somebody who is providing content, helping them to be better in producing marketing material. That's all great, but we have so many other things, and that's not only possibilities, that's also market share. And there are budgets out there where we can probably compensate for all the declining business around traditional websites for different reasons.

John: So I agree with like 90 to 95% of what you just said. Right. I think like anytime I look at a Drupal project and, and this goes back. I, we'll call, we'll call it for the last 10 years maybe it's a little bit further, but for the last 10 years at least, right. They've all been web-based projects. Right.

But you're absolutely right. They've all had some sort of integration with a business system, with an you know, some, some business, business process that needed to happen. Right. For a long part of my career, I worked on an e-commerce site, which was like, Hey, the web front, the website is the front, you know, the front door.

But like behind that, there's, you know, ERP systems and PIM systems and like processing and shipping and all this other stuff happening. Right. And Drupal's integrated and, and moving, moving data and, and processes and, and kicking off processes to, to, to run that. Right? So, like, I think. I definitely agree with what you're saying, but I think we also have to look at the landscape of currently, like in a lot of organizations, the CMO has more of a budget to spend on tech than the CTO does, right?

So, you know, in my, you know, rose colored glasses, like perfect world of Drupal, right? We're explaining to marketers the benefits of using Drupal. But then we're also explaining to the CTOs that like, hey, you can integrate this thing into all of your systems and it can, it can kick off processes and it can do, you know, AI tasks and it can, it can run all of these great things.

Again, that's why like so excited by, you know, ECA and, and orchestration because I think that brings that more to the, to the forefront. So like. I don't know. I don't know if we need to necessarily change the focus. I think we just need to do a better job of communicating that. Like, Hey, we can make things more efficient if we use Drupal in this way.

As opposed to like just your website. Yeah. Stuff

Alexander: before, I think I just wanted to jump in on that. I, I think for me it's also. In a way, making it possible to push the skills of Drupal developers further. Absolutely. 'cause I think in for, for the module of today, Nick mentioned like, Hey, it's cool. I can spin this up locally with, with DE and then I can run my dashboard locally and monitor these things remotely.

But realistically, with, with Drupal and now with what Symphony can do, we're almost so close like, why do you really need DE? Why could you not package that module up as a standalone application where you're not having to install all of Drupal, you just open an application on your computer that has, I don't know, bundled database, little bit of pH HP runtime most a, a lot of.

Very successful applications these days, ship the entire Chrome browser just to get a front end. So there's, there's very little reason at this point why we couldn't ship a small PHP app executable that includes Drupal as an application. So,

Nic: so before I ask my next question, then that, that kind of expand.

So I, I used to always say like, Drupal's great for building some, like you can build an ERP in Drupal. It might be complicated in a lot of work. You could build A-C-A-C-R-M, you can build all that kind of stuff in Drupal. One thing that you really couldn't do in Drupal is you couldn't build easily without orders of magnitude more work.

You couldn't build something like Google Sheets, right? And when you start talking about Drup as an application, that's where my mind goes building projects like that. But it sounds like you're more talking about something like Slack. Where it's almost like an electron app, but it's built in Drupal behind the scenes.

It is that it could be accurate. Yeah. I, I

Alexander: think specifically for something like Google Sheets, you have this very UI intensive and calculation intensive application, but I think there is a large class of applications that doesn't require that much data processing, but mostly just data moving.

John: So I got another, I got another use case that's not as I don't know, cut and dry as the one Nick just, just put out there. Right. So like, I kind of imagine like. And maybe we're like, maybe we're going backwards here. I don't know. But like, I kind of imagine like you could use Drupal as a desktop application for a dashboard tool for your company, right?

So like you come into work in the morning, you double click the, the my company dashboard icon. In your toolbar, it opens up Drupal, right? And Drupal's basically pulling in data from all of these other systems. Drupal's pulling in maybe in you know, in some way that Google Sheets interface so that you can do some sheets work in there and like to the end user, they're like, I don't know, I click the thing, the thing opens up, it shows me all the stuff I need.

But on the back end of that, it's all Drupal sharing data and you know, kicking off processes and doing all of the, doing all the heavy lifting, right? Yeah, exactly.

Jurgen: Yeah. We could also say, look Google Sheet is. A database with a very simple data structure. And they came up with a UI on how to enter a lot of data into it.

Mm-hmm. And also process some of the data. That's exactly what we do as well. But there is no point in trying to repeat the same UI that's already there. Yeah. But the data processing of Google Sheets is what we can do perfectly. We can also do things like SharePoint. We can do things like SAP or parts of SAP.

So in other words, we can replace a lot of use cases where there are millions of license fees spent, where they could be spent in our community.

Fei: I, I have a question. So, you know, I, I started in Dral and then I kind of moved more into, like, towards the marketing side where I'm now trying to pitch these ideas.

I'm like, oh, we can do so many cool things with orchestration and, and, you know, think outside the box, but there's no sort of, people can't connect the dots. And I, and I think that if we had actual use cases where we've already done it, and I could demonstrate to my team, like, Hey, it's actually not gonna take a million hours of engineering because we have, you know, AI and orchestration and the ECA can do these things and then we can apply it over here.

So my question is, do you know where this has actually been done? Have, do you have actual use cases where, you know, like, you know, your

Alexander: left? So, so the closest, the closest I can, the closest I can give you is. The basically our, our realtime chat server, but that doesn't really use Drupal itself. It just sits in front of Drupal.

And I think the main thing is that. If you try to do this with Drupal now, then you run into quite a few limitations where it cannot do it yet. Yes. But I think that, that the main, the main premise of our story of, of why, why we get excited, or at least why I get excited about this, is if I look at PHP itself, then I can see with the introduction of fibers, for example, we're now getting closer than ever.

And even with some of the improvements that we've been making in Drupal with, with introducing more asynchronous stuff into Drupal, already moving in that direction, fixing some of those, of those issues, we're, we're getting closer and closer to making this possible. And I think that's also why, when I'm trying to sketch the, what we could do with Drupal, if we, we solve some of these challenges.

Fei: So what do you think the first really good examples are gonna be that I can take to my team and say, look, look at this. Look what we did with Drupal.

Alexander: I expect that it's gonna be something related to ai. I actually was like, Y Jurgen put, Juergen pulled me actually into a Slack discussion today around AI orchestration and AI agents.

And that is, I think that's the workspace where you have these kinds of long running place long running task with an agent connecting to an LLM to interpret your the text that you input, maybe doing some language processing, sending it off to a search for that. Then actually calling out to some of the tools that you're connecting to, and then going back to that LLM to come back with a, with a response.

That might take a few seconds and you probably wanna have that interactive, so you don't wanna have the state go back to the database. You wanna keep that in memory so that you can iterate quickly.

John: So, Jurgen, did you wanna add something there? 'cause I have, I have thoughts, but I want, I want you guys because you are the guests to offer your thoughts.

Very

Jurgen: kind of you. Thank you. Well, back to phase question. We do have a history of applications that we built and we are terrible about letting others know about it. There is one that gave one has a couple of splash awards, which is a portal for real estate management companies. That's a real big one.

And the value for them is just outstanding. It doesn't look nice and it's very hard to demonstrate because it's behind closed doors. You know, it's nothing public. It's something where you need to authenticate yourself and then you can leverage it. We have done things like a booking and management system fors.

Which is an amazing job, especially when compared to proprietary alternatives. We have even developed a complete payment gateway for a huge German bank group more than 10 years ago. It's no longer in use. It has been a success back then. One of our biggest clients is using it as a lecture management framework to replace SAP clients.

Like, you know, you have to manage I don't know, 26,000 accounts in their booking system globally. And then each local brand branch adds a number of thousand accounts that only apply to their local requirements. Mm-hmm. And that goes through audits and stuff like that. And all happens in Drupal.

There are hundreds of people using that. Everything is approved. They use the export and configure SAP with it fully automatically, and you don't wanna know how much license fees they save out of that solution.

Nic: Wow.

Jurgen: I mean, I wanna know,

John: but, so, I mean, I think, I think the, the, the thing here is this, is this on a smaller scale, like I look at this as like a crawl, walk, run, sort of like, you know, time scale, right?

And we're kind of in that crawl phase where Alex had an example of the chat bot, right? Jurgen just gave you an example of like, you know, moving out of SAP, right? Mm-hmm. I think there are a lot of examples out there, and I know of, you know, free in the, at least in the last, you know. 10 years that I've worked on personally, where, you know, it's always been a website, but there's always been business backend that's, that, that Drupal is, is working through happening and, and sharing data or kicking off processes or doing some of these more application like features, you know, kind of, kind of to help help people.

I, I think there are a couple of things that make it hard to talk about them. NDAs and mm-hmm. Clients not wanting to kind of like tip their hand is definitely, definitely a big piece of that. Well, I, I think

Nic: I was, I was gonna ask, like, I think a good example of this is things like batch runs and things, because like, your, your options right now, if you wanna, if you wanna process something that's too long for normal request, you either with ai, most AI right now in Drupal is tied to an entity.

You can have it process the request immediately when you click save, which if you have a chain of events that need to happen, it's problematic. 'cause each one's gonna take 10 seconds and it's gonna take 45 seconds for it to to run. You can also have it run on chron, but then you don't know how many cron runs are gonna have to run before it finishes because it might be two, might be 10, might be a hundred.

Depends on if you're re-indexing search at the same time. Right. Or you could do a batch, which means that they get a progress bar and that's kind of the only option. Right. It sounds like one of the things that this application based workflow solves is the ability to be like, Hey, kick off this process, run it immediately, but in the background and then just tell me what has done and so I can update the ui.

And maybe you can gate some of those, right? So you don't, if you have a lot of people doing the same thing at once, you're not using all the resources or something, you can queue them, but it sounds like one of the first places that would get improvement would be batching, right? Is that

Alexander: I, I, I think, yeah.

I, I maybe sometimes get carried away a little bit with like, the large applications, but I think like workers would be the very first thing that I would use it for. One example I, I sometimes forget is like at open social, we send tens or even hundreds of thousands of notifications, I would assume per hour, but maybe per day.

And this is emails, push notifications, in-app notifications. And right now that all runs on Chrome. That means that something might happen. And if you have a very big platform, can take about an hour before you finally get your notification. And one of the things we've never implemented for that reason is time-based notifications.

Because if we tell you that an event is gonna start in half an hour, then that notification better arrive half an hour before your event. If it shows up half, half an hour after the event has started, then as a user, you're, you're gonna be quite unhappy. And with that's really. Quite difficult to make sure that you get your timing strict because you have these limitations of how long it can run.

As Nick, as Nick explains, whereas if you can have these longer running processes, okay, cool. Now I just make a worker that is responsible for my notification logic. And I use existing methods like a message broker to throw messages, edits, and every time it gets the message to say, Hey, figure out what notifications you need to send it can process that.

Yeah. And, and for now we're forced to do it in chron. You cannot do that in a user's request because figuring out like which 5,000 users you need to send a notification to might actually take a couple of seconds. And that's not something you wanna do as part of someone's request to the server because then their, their web experience is gonna suffer.

Nic: Yeah. And, and you can fake it with Ajax calls that you plan on being terminated because they navigate away or something. But yeah, it's.

Alexander: It's a problem that, that has the downside of tying up like very valuable web server resources because that, that severely limits the amount of concurrence requests you can handle.

Nic: So let, let's switch gears slightly. Jurgen as John said, he's very, very excited about orchestration. So it's kind of funny that I'm the one asking this question, but I, I'm, to be clear, I'm excited about orchestration as well. And you had pointed out when we first talked about it a couple weeks ago, that orchestration really doesn't have much to do with ai.

I think we conflated that. It's, it's really about just kind of connecting things. Can you give us a quick status update on orchestration and how that fits into this idea of making Drupal more of a, an application-based framework than what it is currently?

Jurgen: Sure. It all happened early summer this year when DRIs approached me and said, look.

ECA is kind of great inside of Drupal to build orchestration things like Innate and s and others are doing outside. It's not really as user friendly yet as external platforms are. So we had quite a, a lot of discussions around what can we do and how could we do that. But while discussing that, we also spoke about the question whether it really made sense to replicate everything inside Drupal where there are so many external platforms like the Naan already capable of doing that, and wouldn't it be more efficient.

When Dral just integrated into those platforms so that we don't have to build all the hundreds, if not a thousand integrations, one by one Drupal. And I would like to add, it's not just building those integrations, it's also about maintaining them for the next 16 or 20 years. So that's how everything got started and we have a complete integration into active pieces and it's technically working really well.

And what's exciting is the feedback since DrupalCon Vienna is really, really nice. People like it. People like the idea and they like the opportunities. We are still not settled yet on, you know, what is the focus of all that and where do we wanna go with it. In other words, what is the real strategy of.

Drupal as a project on where do we wanna play with orchestration. We are currently in the process of working on a strategy document, just like it happened with the AI initiative, where bunch of people come together and consolidate ideas and then come to a conclusion what is it that we are gonna work for.

But in the meantime, there is also some very specific activity happening. Like somebody from Canada is already working on an innate n equivalent to what we've done with active pieces. Somebody else is working on a integration, which is great too. What I was very excited about is I spoke to Randy also from Canada a couple of weeks ago.

He's the maintainer of the maestro module. And don't forget this, start back in 2003. So that's already what, 22 years in that module, and it's absolutely impressive. This is about business process automation and it is far away from what ECA does. You know, ECA is in request automation in the background, more or less smaller tasks that happen when the user is doing something through the browser.

Whereas Maestro, they are really building workflows with state management. So working through a workflow can take two weeks or even longer than that. And for each individual step, they keep track on what is the status, what needs to happen next, why and when. And. He was so excited about the orchestration thing because he needs to integrate lots of workflows into all those external systems.

And I was actually surprised because my impression was that they are doing really well by implementing such integrations on a per customer basis. So a service business kind of thing. And orchestration, as we are thinking of at the moment, would probably make that redundant. And his instinct reaction was, yeah, those revenue disappearing in that area.

But my business could grow massively because if I can go out and tell everybody, look, we are building those workflows on top of Drupal, by the way, you don't need to know what Drupal is. It's just an interface that you can use through the browser. I can tell them that out of the box and for free, we come with all those integrations as well.

That would be a killer app. And that's why he got so excited. And it took him two days to integrate my estro into orchestration. So from now on, he can communicate both ways with active pieces already. And as soon as the n Aden and SAP is available as well, his tool can also talk to them and his client's applications as well.

Alexander: Hmm.

Fei: This is, this is exactly why I'm so excited too. So, having left Drupal, you know, I really kind of separated and I, I started to do the process architecture work and, I don't know what the language is for that, but I basically am like using automation to replace myself as a sort of project manager, technical project manager, scrum master delivery manager kind of person.

So when orchestration came out, I was like, oh my gosh, this is, this is it. I can really, like, I can really do amazing things here, but it's still separated from, from Drupal in some interesting ways. So we've been looking at at bringing in automated testing and using orchestration to really basically take out all of the tedium that we need, our QA analysts your, our QA team to, to do.

But I'm also really interested because as an enterprise. We have a lot of business analysts who just churn through data, and they always want data, and they always want reports. Have you started to have conversations about the business analysts, like the enterprise business analyst, and how do we use orchestration and, and what can we do?

Could we build a portal for them to go through the, you know, where are we at with these conversations?

Jurgen: Only to a limited extent. One of my colleagues here is currently working in a FinTech company in Switzerland for a project. He keeps coming back saying like, look, with the toolbox that we have in Drupal, with that orchestration and everything else, we can build their application in a matter of three months where they currently want to rewrite their current application and they are asking for something like three years for 15 people full time.

So he says, you know, the traditional software industry approaching those problems is still thinking really, really big. Mm-hmm. And, and Drupal and all the connecting dots to the outside world, we can achieve the same in a much shorter period of time.

John: It, it really like. Over the last, again, I'll say five to 10 years, maybe it's longer, maybe it's less, right?

But like, we've really been moving from this. Let's build, and I'm gonna say this word I, this word drives me bananas, but like, no, it's monolith, right? Like, you know, everybody has, has, you know, 10 years ago, may 15 years ago, everybody was like, oh, we have to build it ourself. We have to build our own custom thing to do our own custom job.

Right? Well, when you do that, it comes along with maintenance, upkeep improvement, right? We're moving and have been steadily moving to a, Hey, if a product or service does it better, we're going to let them do it. And we're just going to build through API or through sharing of data connections and send that.

Those, that, that information, that, that data, that stuff in the direction we need to send it in, right? So we're becoming a more, a more connected you know, world if you will, where we're not saying, Hey, we're gonna build it ourselves. We're gonna, we're gonna say, Hey, how do we build a connection between those, those two systems?

And like going back to the beginning of show where I called Drupal Glue, like that's kind of what it's good at. It's good at connecting those systems and in providing those communication channels between those disparate systems. And I think. You talk about active pieces, you talk about Zapier, like that's really what those platforms are great at, right?

They're great at saying, Hey, you're using all of these products and tools, right? You need one way to kind of like, take the data from here and move it over there and take the data from there and move it over here. And, hey, by the way, that's gotta connect into your website and it's gotta connect into your business backends.

And like, it's gotta go to a lot of different places that might not be a, a, a service from Google or a service from Microsoft or, you know, whatever. Right? Like the excitement, hopefully you're getting the excitement that I'm, I'm, I'm pitching here, but like, we're moving in a direction of, and, and I have this conversation with my developers all the time.

We're not building the, the, the like custom monolith thing. We're building new features to enable marketers to enable business to move faster. We're building those communication channels between the services to be able to say like, Hey, all of this stuff goes into Drupal. Drupal then does, its, does its thing in the backend to, to orchestrate this for you.

And at the end of the day, like to your point, Jurgen, like if you had a two week process, at the end of the day, whatever the end goal of that process is, it would be like, boop, here you go. Right? And that's like, I don't know. That's super exciting to me. And I think like. The, to your point, right, like, could it be all displayed on a dashboard to data analysts?

Sure. I think that's one small aspect of it to say like, Hey, we're gonna build a dashboard for this, and maybe it's not even a Drupal dashboard. Maybe it's you know, what's the Google service that takes all the data in and shows it to you? The data studio. Data studio right there. It's like maybe it's a data studio dashboard, right?

And it has data sources from a bunch of different places. But like, that's one small piece of it. But like, imagine there being a button in that dashboard that says, you know, you run a process to, you know, for this year, year end, like year end button boop, and then all of a sudden it starts going and getting all this data and doing all these things for like your year end reporting.

Right? I just.

Nic: I just wanna break in. Oh, yeah. Feel free, feel

John: free to, just to stop my, yeah. Tirade, please.

Nic: I, I, I just wanna break in because you said one thing that I think is, is mostly true, but I, I do see the opposite side of it sometimes, which is the, the monolith thing where I am seeing clients starting to move some stuff back in.

Mostly for like data privacy and ownership concerns, right? Things like GDPR. If you're analytics a great example because you're talking about data studio, right? If you are sending your data to Google, then that's a cookie. That's a permission, that's a consent. Like that's a, all sorts of things that you have to handle.

If you're using something like OMO and storing that locally, it can be a first party cookie, and you can manage some of that data. I mean, you still have stuff you have to handle and privacy stuff you have to handle, but it makes some of that stuff easier. The other thing is the, the, the kicker is. Yes, this application does make it easier to, or to coordinate with orchestration, makes it easier to connect to different things, but the application thing makes it so things like analytics, data gathering, you know, really intensive pieces can be done directly in Drupal without impacting the performance of performance, the front end, right?

So if you wanna start like the statistics module's, great. Unless you wanna be able to load your site in less than 35 seconds. Right, but Well,

John: but I think like, to, to that point, Nick, like, I think you're gonna start to see, well, companies are already doing this, so you're not gonna start to see it, but you're gonna continue to see the proliferation of data links, right?

Like all of all of these companies have their like data warehouse sitting on their networks somewhere, right? And they're pulling in data from Google, they're pulling in data from their ERP, they're pulling data in from their CRM. It's all funneling into this one place, and then it's being strategically pulled out into different systems and platforms to do, to do different activities with it, right?

So, I mean, I think like you're right that like companies are sharing data with Google and sharing data with this, but it's only to, to achieve that whatever the end goal is there with that service, right?

Fei: So I think we're really kind of stuck on the idea of Drupal being for. Website and we're, we're sort of touching on this idea that okay, but maybe it doesn't have to, we don't, doesn't, the Drupal as a CMS does not have to be forced.

There's no forced link. We don't have to do it that way. Right. So can you tell us a little bit about how do we, how do we break that link that we have in our, our, our brains? What does that look like?

Alexander: For, for me, that's actually one of the reasons why I am excited about Drupal CMS not necessarily because it fixes a problem that I have or because I'll be a user of it, but because I think it's very clearly a product built on top of Drupal.

And that allows us to say, okay, well Drupal is now just a framework with which you can build things. And if you have those skills of a module developer, then whatever you wanna build is up to you. And the CMS can be one of those. And I think if, if I look at how, like, how we've recently used Drupal for iata, for example, that you see that it's this great way actually to get data in and to have ownership of this data because it's secure has such flexibility and excess rules now with excess policy.

Very flexible caching system. And if you need that data lake to pull the data out of it, cool. Set up GraphQL, set up JSON API. If you get your questions about authentication. Choose from any number of the Enterprise Ready Authentication modules that we have, whether it's OpenID Connect what I, there's one I'm forgetting.

And that is, I, I find in these kinds of conversations of we wanna solve a, a problem where we need to gather data from many different stakeholders. And we wanna do that securely. It doesn't have to be a CMS, but it definitely should be Drupal.

John: I, I, I both love and, and don't love that response.

'cause I like, I, I love the, i, I love the, the premise of like, well, there's Drupal CMS now, but like, I don't love the idea of the possibility of somebody saying like, oh, I've created Drupal application framework, and now that kind of sits next to CMS and the Drupal, you know, Drupal is underneath, powering both of these things.

I'd rather it just be like, Hey, you can use Drupal. Like

Alexander: here's

John: Drupal, but,

Alexander: but Drupal, sorry, but Drupal application framework is just Drupal.

Fei: I this,

Alexander: oh, go ahead, Faye. Sorry.

Fei: As an explanation, when I bring the sort of technical pitch to a marketing brain, to a marketing team, and I say, here are all the cool things we can do with Drupal, this is actually a really interesting sort of way to frame it as a use case for a marketer to say, Hey, Drupal CMS is actually a thing that we can build with Drupal.

And if we tear that all apart and, and rethink how we could build it as a portal for our business analyst where they can come in and work with the data. I wasn't thinking a dashboard, I was thinking like a, like a whole portal. You can go in and there's interactive data that they can play with that's exciting to them.

Right? And that's totally separate. So I, I think that, I think this is a really interesting way to frame it. I like it. Sorry, John. Oh, you're,

John: you're okay. That's fine. That's why, why we have this show so that people can voice, voice their thoughts. Jurgen in two minutes any any thoughts on, on that?

Jurgen: I find it interesting that the framing of CMS seems to be so fixed.

You know, if in our community we hear about CMS, we think about a web content management system for content on a website. To me, CMS is nothing else than an Elias to a database with a data structure, right? And data modeling is what we're gonna do for every single application. So CMS is not wrong. It's exactly what we leverage for applications as well.

But not in the way that our current Drupal CMS marketing is actually framing that term. So I don't see any, you know, conflict

John: in it at all. That's, that's, that's interesting. And in my head I was like, ah, it needs to be A-D-M-S-A data management system. Just Alexandra's. Like No, too, too. Thank you. Too many all set.

Alexander: It it, I mean, like, for me it, like you say, it has to be, I'm the, the reason I shake my head a little bit is it, it already is and it always has been. Yeah.

John: We should just insert, call it, insert meme. We should just go back to calling it Drupal. I mean, I don't know. Well, Alexander Jurgen, thank you for joining us.

Thank you for suggesting this, this wonderful topic and, and having this conversation with us. As always, it's been, it's been super enlightening.

Nic: Do you have questions or feedback? You can reach out to talking Drupal on socials with the handle Talking Drupal or by email with [email protected].

You can connect with our host and other listeners on Drupal Slack in the Talking Drupal channel.

John: Wanna be guest on talking Drupal or our new show TD Cafe? Click the guest request button in the [email protected].

Nic: You can promote your Drupal community event on Talking Drupal. Learn [email protected] slash td promo.

John: Get the Talking Drupal newsletter to learn more about our guest hosts, show news, upcoming shows, and much more. Sign up for the [email protected] slash newsletter.

Nic: And thank you patrons for supporting talking Drupal. Your support is greatly appreciated. You can learn more about becoming a [email protected] and choosing to become a patron button.

John: All right, Alex. If folks wanted to get ahold of you talk more about Drupal as an application framework or any of the other great things you're doing, how could they go about doing that?

Alexander: So they can find me on Drupal Slack blue sky, under King Dutch or my personal websites. Alexander fark.com.

John: There you go.

Alexander: Juergen, what about you?

Jurgen: My handle is Juergen has pretty much everywhere. Drupal Slack, blue Sky, and Mastodon. J-U-R-G-E-N-H double a s.

Fei: Great.

Jurgen: Fei?

Fei: Oh, I am likewise. I'm Fen everywhere. Community Slack is where I am most active, but I'm also on LinkedIn.

John: Yeah, everywhere. There you go. Nick, what about you?

Nic: You can find me pretty much everywhere at nicxvan, N-I-C-X-V-A-N,

John: and I'm John Zi. You can find me [email protected] or on the social media and Drupal uh.org as at John Zi, and then you can find out about [email protected].

Nic: And if you've enjoyed listening, we've enjoyed talking. See you guys next week.