 Hi, this is Jake Halicott from Media Current. Today, I'm going to explain why decoupling Drupal is actually easier than you might think. Our team here at Media Current has been championing Drupal Drupal for a number of years now. We love to pair Gatsby.js with Drupal 8 or 9 for that matter to create an incredibly performant, secure, and stable solution for enterprise organizations. The main thing we want you to know is that if you're thinking about decoupled, one of the biggest pieces you need is already there. It's already part of your Drupal 8 application. That, of course, is the JSON API module. The JSON API module is part of Drupal Core and is a key ingredient to transforming your application into a decoupled solution. So what are the ingredients to migrating your existing site to a headless architecture? Let's go through each ingredient one by one. The first ingredient, as mentioned, is the JSON API module. This module was added to Drupal 8 Core and is also present in Drupal 9. The JSON API module simply exposes all of your content in the JSON API format so that it can then be consumed by other applications, including Gatsby.js. The next thing you need to do in order to integrate with Gatsby.js is to add a source plugin that will connect the Gatsby application to the content being served by Drupal. Gatsby has a host of source plugins that connect any number of data sources, including Drupal, WordPress, and many other platforms. Of course, you'll need to host your static application somewhere. For the Drupal side of things, you don't really have to change anything. You can continue to host on your existing hosting platform. For Gatsby, we like Netlify because it has many features and very reasonable pricing. It's also easy to set up. Currently, most of our implementations are using Netlify as a host for our Gatsby.js applications like mediocrant.com. The next ingredient is optional but helpful, and that is the build hooks module for Drupal. The build hooks module has a connector with Netlify that allows you to easily trigger new builds in Gatsby from Drupal. If you are familiar with how Gatsby works, it essentially rebuilds a site every time you tell it to rebuild. This module makes it easy to configure so that every time you save a piece of content, you can trigger a new rebuild automatically. Gatsby Cloud is also optional but has a host of great features that you're likely going to want if you're using Gatsby. The team that created Gatsby.js has been busy working on a number of features, including live preview, incremental builds, and more. We recommend you integrate with the service to get the most out of your Gatsby application. Finally, the last piece to add to the mix is the Gatsby.js module, available on Drupal.org. If you're using Gatsby Cloud, you're going to want to configure this module so that you can leverage live preview for a seamless editing experience. There are many ways to make the transition to decouple, and it doesn't always involve a full rebuild. Let's discuss some of the ways you could transform your existing Drupal architecture to a headless application with Gatsby.js. First, we discussed the quickest route to make your site ready for integration with Gatsby is simply to install the JSON API module provided by core. Next, you'll need to look at the site's overall content architecture to see how far you are away from having a content model that makes sense for a decoupled application. It's possible that you don't need to do a lot because Drupal is already great at defining a well-structured content model. That being said, if you're using layout builder or panels extensively, moving to decoupled is going to be more of a paradigm shift, which means you're probably going to be making more changes to your content architecture. If you are going to keep your content model mostly intact without major changes, you're literally halfway through a transition to a fully decoupled application. In some cases, it might make sense to go ahead and create a new installed profile. We actually took this approach on a recent client build. They were already running a multi-site and we were tasked with creating a new microsite that would be decoupled. Rather than starting fresh with a completely new code base, we were able to add a new installed profile onto their existing code base. One of the tangible benefits of this approach is that we could add the new site onto their existing hosting plan. Okay, let's wrap things up. Today, I wanted to share the idea that moving to a decoupled architecture is actually easier than you might think. When you're planning your next redesign, you should consider that the bulk of the effort will be on the front end, which you're probably going to have to completely redo anyway. So why not create that new front end in React? The last thing to consider is your team. If you have a team that's great with Drupal development, but not as up to speed on React and GraphQL technology, then that learning curve is probably going to add time and risk to the project. In that situation, maybe you're good with the standard Drupal theming approach. However, if you don't already have a team in place, you're probably going to find that it's easier to acquire developers that know React than it is to find developers well-versed in Drupal theming. And that's really one of the compelling reasons to choose this type of architecture in the first place. On the one hand, you've simplified the backend side of things, where you can get a lot done with Drupal site building skills. Then on the front end side of things, you can take advantage of a large pool of talent that knows how to build React applications. I call that a win-win. At Meteor Current, we have a great team of developers, strategists, designers, and problem solvers that can help you navigate these type of decisions. Contact us today to learn more about your options and we'll get to work. This is Jay Calicoff from Meteor Current. Thanks for watching.