"Then there is this multi-website, multi-endpoint architecture that a lot of our bigger clients employ. And this works a lot better in a decoupled setup because we're really able to create completely different applications that all connect to the same data source and use this data in wildly different ways."

Intro:
Welcome to the Agile Digital Transformation podcast, where we explore different aspects of digital transformation and digital experience with your host Tim Butara, content and community manager at Agiledrop.

Tim Butara: Hello everyone! Thanks for tuning in. I'm joined today by Philipp Melab, lead software engineer at the Swiss digital agency Amazee Labs. Amazee have had a few really interesting projects recently using the GatsbyJS framework as part of a decoupled CMS solution. And this is what Philipp and I will be talking about in this episode: enterprise-level decoupled CMS with Gatsby.

Welcome Philipp, it's great to have you here. Anything we should add to the introduction?

Philipp Melab: Thanks for having me, and no, I think we're good.

Tim Butara: Okay, then let's just dive right into our topic. And my first question for you is: what is enterprise CMS or Content Management System? And how is it different from standard or traditional CMS?

Philipp Melab: I think that's a pretty interesting question, because if you ask 10 people you will get 12 answers. If you Google the term you find something like “managing unstructured documents across different stakeholders”. Which is not exactly what we would categorize Drupal in. So I think this spot is more covered by the Google Drives and the Atlassians and Confluences out there.

Tim Butara: So, but maybe, how do you at Amazee define enterprise CMS? Maybe that's a more straightforward question.

Philipp Melab: Yeah so, I think for us it comes down to the number of people that operate the CMS and the different levels and how many access restrictions are in place. And I think one thing that specifically distinguishes us, like the standard level, and this enterprise corporate level, is the number of endpoints we are feeding. So our corporate level clients have a tendency of running multiple websites, perhaps for multiple nationalities or multiple sub-branches of their corporation. And this content is managed in one central content management system. So I think that's our definition of it.

Tim Butara: Yeah, that actually makes a lot of sense. It's maybe kind of not a difference in the system itself, but a difference in how the system itself is used, kind of. You know, as you mentioned, now it’s multiple endpoints, multiple like large-scale organizations. Yeah, yeah, that makes a lot of sense. It's good that I rephrase the question in such a way to get a more accurate answer. And okay so I'm suspecting that there's a more clear-cut definition of what decoupled CMS means.

Philipp Melab: For us it means we don't write our templates in Twig, although that's not completely true, because we were like soft progressing out of pure Drupal into the fully decoupled approach with using GraphQL within Twig in Drupal to pull data out. And I think you have a lot of ways to decouple. So you can use different APIs, you can use different front-end layers, but the important part is the inversion of the direction how data flows, because in traditional Drupal in the theming system, we push data up. We prepare data on the data level, and then we push it into the theming layer. And the theming layer has to have the knowledge on what data do I get and how do I use it to display it. And in all, what I think that's, what decoupling fundamentally changed is that with React, for example, with a decoupled front-end with GraphQL, the front end defines which data it needs and pulls it out of Drupal.

Tim Butara: Aha, okay. A good point there about kind of changing the direction of data interaction. And yeah just maybe for those listeners who don't know what Drupal and Twig are; Drupal is practically the most popular and the most used enterprise content management system. And Twig if I’m not mistaken Philip is the templating engine that you use to write themes for Drupal websites, yeah.

Philipp Melab: Yes.

Tim Butara: So decoupled kinder kind of changes the whole relationship between the back end and the front end if I understand it correctly?

Philipp Melab: Yes so, I think that's what's under the surface. So people want to decouple I think initially for other reasons; because they want their front end to have more freedom to not be bound to Drupal's technology choices, which are well, they gathered experience, let's say that way; but they're not cutting edge. So people want to use React, they want to use this whole JavaScript Jamstack technologies, and modern layouting and styling. And with Drupal you're very bound to what Drupal does, and you have to know a lot of Drupal internals to know which template do I have to override to be able to display this differently for example. And it turns out there are a lot more JavaScript and React people out there that can help you to build an amazing website than there are Drupal people. And I think that's, that's a good reason, but under the hood there comes this inversion of control. So it's not Drupal anymore that's controlling how the website is displayed, and you can just adapt it; but you really build a website the way you need and where you need Drupal, you pull in the data, and that's what decoupling ultimately means.

Tim Butara: Okay we're already kind of moving into the next section that I wanted to include. And that is, what are like the benefits of decoupling the front end and back end of your website or application? And in particular, how do enterprises benefit from decoupled CMSs?

Philipp Melab: Yes, we already transitioned there. So we're able to move with this more modern technology on the front end, while keeping our trusted PHP and MySQL stack in the back end, with all the data in there which you don't want to move at the pace of what happens in the front end. And then there is this multi-website, multi-endpoint architecture that a lot of our bigger clients employ. And this works a lot better in a decoupled setup because we're really able to create completely different applications that all connect to the same data source and use this data in wildly different ways. And I think that's, that's the major benefit that our corporate clients have from decoupling or get from decoupling.

Tim Butara: It's like, it's a really good approach in a world where a lot of our digital experiences happen on so many different channels, you know, where the customer journey is not a super linear thing; but kind of one that comprises of multiple touch points, multiple interactions. And I’m guessing that a decoupled architecture lends itself pretty well to these more particular requirements.

Philipp Melab: Yes. And also that's where GraphQL plays an important part for us since the standard solutions for example, in Drupal which is JSON API now for exposing data, are still very Drupal-centric. GraphQL allows us to really model a custom GraphQL schema for our client that reflects the business processes of this client and not just the content management system.

Tim Butara: Nice. Okay yeah, I, I can see how that can be really beneficial especially, especially with more complex organizations. And you mentioned the Jamstack earlier. So for those of you who don't know that that's an acronym that stands for JavaScript, APIs and markup right? The, so the JAM-stack. And here Gatsby also kind of plays into the Jamstack and is part of the Jamstack. So let's talk a little bit more about Gatsby. What is Gatsby? And why has the Amazee team decided on Gatsby as your kind of front-end framework of choice?

Philipp Melab: So what is Gatsby? I think it defines itself as a static web application builder. So what Gatsby essentially does, is gathering information from different sources. This could be your content management system, Drupal, or WordPress, or hosted solution like Contentful, or data from Google Sheets. Basically any source that you could imagine. And then it allows, it aggregates it into one big API, and then you build a React application that reads from this API, and Gatsby will build out static assets that then are your website. So that's hopefully the gist of what Gatsby is.

How did we end up with Gatsby? So when we started our journey into React. This is, I don't even know how many years ago. There was not even Next.js, but we started out on a custom JavaScript stack, with server-side rendering. And we had our share of pain there. And then we transitioned to Next.js as the more or less standard solution. And I remember that, I think four years ago or so, a colleague pointed me to, “Hey look at Gatsby, wouldn't this be something for us?” and I was like “Nah.”

It's, it's kind of the same as Next.js and server-side rendering because you just you pre-render and then you have your static HTML files, and in this other approach of server-side rendering you just traditionally get your request, you process it on the back end; but then it's cached in some reverse proxy. So it's kind of the same thing; in the end you just deliver static HTML that is cached somewhere. 

Yeah and I was very wrong about that. So… because it turns out, there are-- they say there are two hard problems in computer science. It’s cache invalidation and I think the second thing is Drupal paragraphs. Gatsby essentially completely negates the cache invalidation problem by again turning this process around. So instead of having this database and whenever the user accesses a specific path if we have the path cached and it's just returned; but if it's not cached we go down into the database, we have to do all the queries and then we return the response. And this means you always need this operating running system that is accessible by the outside world, like Drupal, to answer the responses of users. 

And with the approach of Gatsby, where you make a change in Drupal, this change in Drupal kicks off the Gatsby process that just regenerates the static parts of the website and pushes them directly into the CDN for example. The content management system ideally does not ever have to be accessible to the outside user and this is just a huge win in stability. And then even bigger win in security; because for some clients we can even shut Drupal completely off the outside world. And it's hidden somewhere in a virtual private network where nobody can access it, just the users that have to maintain content. And then just Drupal pushes to the outside, and so all these but Drupal security updates are not as critical anymore. So you're much at a much lower risk to get compromised on patch day on Wednesday evening where everybody does this collaborative denial of service attack on Drupal servers and refreshing, when is the security update going to come out? And what do I have to patch, is my site going to be broken? And if I’m not done in two hours, I’m going to be compromised. This just all goes away

Tim Butara: Nice so, so you mentioned kind of stability and security benefits. What about-- I’m thinking of the Gatsby’s tagline here, and I really love their tagline. I think it's “blazing fast static site generator” and I never really got that into Gatsby, I never really knew much about Gatsby until I was checking the blog of Preston So. Do you know Preston, Phillipp?

Philipp Melab: Yeah.

Tim Butara: Really great guy. Really great author, great speaker, great writer. I, I really enjoy reading his thoughts and reading his insights on the future of web development. And he has a blog built in Gatsby and once I was checking his blog out and I had to refresh the page for some reason. I refreshed the page and nothing happened, and I was like ‘Wait! What?’ And I refreshed it again and nothing happened again. And then the third time I did it I noticed for like the tiniest fraction of a second, I noticed that the X appeared in place of the, in place of the refresh sign. And I was like, whoa blazing fast static site generator, okay, I’m sold. And it's like since then I've been much more interested in Gatsby so I’m really glad and I have this opportunity to, to speak more about it with you today Philipp. So yeah performance is probably also one, one big advantage of you know using Gatsby for, for presentation.

Philipp Melab: Yes, definitely. Well I would not even credit this only to Gatsby; because we're seeing like a full movement towards static site generators now. So there is already one solution for Vue and also Next.js has incorporated automatic static generation. So the performance benefit is something you will get with Gatsby out of the box, and Gatsby has a lot of built-in optimizations, for example it comes with an image component that can already pre-preprocess images, and do lazy loading, with a blurred image that appears in the beginning. And so these are all things that you get with Gatsby out of the box. That's great; but you could also replicate this in any other system - with a lot more effort. And also things like prefetching of data when the user hovers a link, and at the time where you click it the data is already in the browser, and it appears like it, to the user it seems that the page transition is instant. Which also now leads us into the problem that we are in the uncanny valley of Gatsby refresh times, because the user as you said does not even notice that something changes; because users are used to, like, the browser is going to load, and you see the spinning and then when it stops the user knows okay now I’m able to read my new website or the next page. And now it just, it just happens. And the user does not initially know what happened. So we need to start to, for example, add page transitions between pages to notify the user ‘hey your new content is here’.

Tim Butara: Yeah, yeah. It's good that you added that about, about performance and about these page transitions, because it-- you know, even though it's kind of a boon to the UX, if the user doesn't know about it, or is confused by it, then it can actually turn into a detriment to the user experience, yeah. Good point. And I mentioned in the intro, I mentioned that you've had quite a few interesting Gatsby projects recently. Can you describe one of these projects?  When you kind of used Gatsby within a decoupled architecture and this usage has really paid off? Like, what were some of the main goals and main outcomes of this particular project?

Philipp Melab: Well I have multiple examples. So we are currently migrating a huge decoupled website that was built on, on a traditional React decoupled stack, with server-side rendering, and there we had a lot of issues with server-side rendering, and server-side caching and then React rehydration in the browser. And the client constantly complained about, ‘okay this menu item should not be there, because I disabled it in Drupal’ but in one of the 15 caching layers in between it was still there and it did not disappear properly. So there were, there was a lot of instability in this. And on the other hand, uh this huge Node.js server-side rendering took a lot of resources, and it was not nearly as fast as it could be. And we are currently at 60 or 70 percent of migrating this big project with like 10 thousands of pages. And it works out pretty good, so we're seeing a blazing fast website now, with huge amounts of content. And it works out pretty well. And the benefit for the client is very obvious because they're going down from two second load times for each page, to “I blinked and I missed it” load times.

Tim Butara: Nice! Nice!

Philipp Melab: But the other and even more interesting Gatsby project that we had, and it's not a decoupled project in that sense, because it ultimately did not involve a CMS or did not involve Drupal, but I think it's interesting because it shows how Gatsby transformed how we approach projects. So the goal there was basically that the whole job of the website was to publish scientific data on nautic ecosystems. I don't understand enough of it to explain to you in detail what this data is about, but essentially it was, the source of data was a huge spreadsheet that is maintained by scientists and they approached us, okay we need to publish this and then, in a way that the general public can work with this, read through the data and to also present it in a fashionable way. And the first approach here was, okay we have this Google Sheet, and we have to somehow import it into Drupal. And we have to do regular updates, so we can then read it with Drupal into our website, and the user can access it. And at some point we took a step back and said, “Okay this is not this much data, like, it's not millions of entries”, and what if we, and our clients are already using Google Sheets to maintain the data. And we would just add an artificial layer in between. What if we just take Gatsby, connect it to this Google spreadsheet, read the data in and just pipe it into a static website that updates once a day. And the build process takes-- well, it's a lot of data so it takes like 15 minutes; but this happens once a day and the refresh data is always there. And we don't have a content management system in between anymore and it just drastically reduced the level of complexity; we don't need to maintain a content management system. It has a great performance, and we were able to achieve what our client needs without all of this.

Tim Butara: This is a really great example of how, you know, it's typically not enough to just do exactly what the client wants you to do. You know, you have to kind of optimize, and you have to kind of get to the bottom of what the client's pain really is and then kind of provide a solution to that; because you know sometimes they may not know that a solution that they're proposing can actually be a resolved even more, I mean, the problem that that they're proposing a solution to, can actually be resolved even more easily with a more straightforward, more simple you know less, less complicated solution, so yeah, yeah a very good example here by you, Philipp.

Philipp Melab: Yeah. And I think it also plays into the real or the other big strength of Gatsby also if you compare it to other frameworks that also provide this static site generation. Gatsby has this GraphQL-based data aggregation layer that just allows you to plug in data sources. And we were just able to quickly prototype this, because we did not even have to set up or read the Google Sheets API, because there is already a plugin for Gatsby where you say, “Okay please load Google Sheet here.” And you give it credentials, and then the data appears in your Gatsby GraphQL API, and you can just use it in React and read it, and create your website with it. And this is just; it facilitates a workflow that puts this prototyping and the customer value to the very front. So you don't have to start with architecting your API and how you read this data; but you can start with, okay I’m, I’m starting out with whatever Gatsby gives me, and if we need something more specific, you can dive in and adapt.

Tim Butara: Okay, nice. That does it for my Gatsby and kind of the project-related questions. And I only have one more question for you Philipp before we finish our call. Kind of related to, to all the things we saw going on in 2020. And that is, were there any trends we saw in 2020 that make decoupling an even more compelling choice than previously, than pre-2020?

Philipp Melab: Yes! I think so, and 2020 unfortunately had an impact on our economy. Aand what we saw before is a lot of re-launch projects. We, so the client approaches us with, we have a Drupal 7 website, and we want it to be on Drupal 9, and at the same time we're also doing a full design refresh, so basically rebuilding the whole thing. And this just brings a lot of risk and a huge investment and what we try to propose more, and even more now, is to do risk mitigation. And don't like do this, we're going to migrate a whole website over the fence, and we hope that it's, in six months from now, we should be done and we, we cross our fingers and pray that no blockers appear and that we actually hold this deadline and the budget; but rather going into a much more iterative approach. Where we don't try to do all at once but we just, for example, keep the Drupal 7 side alive, and read data from there into Gatsby and just port the most critical features. So we're creating value upfront and not just when we migrated the whole thing.

Tim Butara: Yeah, yeah. That's a very good, that's a very good point, a very good example. I was also thinking about this transition into more iterative development rather than and kind of doing stuff in increments, rather than kind of taking on these massive, massive upgrade or migration or re-launch processes, yeah.

Okay! That's all from me Philipp. Before we finish if people want to reach out to you or learn more about you or Amazee, where can they do that?

Philipp Melab: Well, Amazee Labs have a website, amazeelabs.com. You can have a look at our team and what we do and our blog. I'm also, I did a couple of webinars on test driven development and you can find this in our Amazee Labs YouTube channel, and I’m always responding on Twitter. My twitter handle is @pmelab, and you should also be able to reach me on the Drupal Slack channel.

Tim Butara: Okay! Thanks for speaking with me today Philipp. It's been a really great, really informative chat. I really enjoyed it and-- 

Philipp Melab: Likewise.

Tim Butara: Yeah, great. It's, it's really, really great to have you. Really, I’m really glad I got the chance to speak with you, you know, we, we have a very good relationship with Amazee and it's, it's always nice to kind of get to know more of your team and speak with you more. So, yeah! Thank you for this.

Well to our listeners that's all for this episode. Have a great day everyone and stay safe!

Outro:
Thanks for tuning in. If you’d like to check out other episodes, you can find all of them at agiledrop.com/podcast, as well as on all the most popular podcasting platforms.

Make sure to subscribe so you don’t miss any new episodes, and don’t forget to share the podcast with your friends and colleagues.