 So let's get started. So this is a presentation called Magnetruel on the Jamstack with Gatsby and Drupal 8. And Ben, why don't you introduce yourself? Yeah, my name is Ben Robertson. I lead the customer success team at Gatsby, but I was formerly at Media Current, so this presentation is going to talk about work. Bob and I worked on together at Media Current. I was the front-end lead on the project. And I'm Bob Kepford. I'm a director of development at Media Current and I've been at Media Current for seven years and led the architecture of this project and really enjoyed working with Ben and the rest of the team, proud of what we were able to build. Just a little bit about Media Current, we are your open source expansion partner and we're Drupal pioneers. We've been doing that for a very long time since the early days of Drupal. We are digital strategy experts, open source advocates, researchers, designers, and innovators who solve technology problems or challenges, both actually. And our mission is to bring together the most talented team members to improve technology for our clients. And like I said, I'm with Gatsby. So we at Gatsby are planning to be the way to build the web for everyone. Our mission is to create a better one for everyone where security, performance, accessibility, and modern tooling are defaults, not afterthought. So we want to make the right thing the easy thing on the web. A great approach for sites that require functionality that's beyond what Drupal normally supports. So when you do a couple, you have an opportunity to choose the best tool for each individual technical requirement. And in this session, we're going to take a look at a decoupled approach for Magnetial.com, how we combined open source frameworks like Gatsby, Drupal 8, and Serverless, as well as third party services for user management, learning management, and private APIs. And we were able to build a very robust custom platform. The session is for you if you are a developer. If you're interested in Drupal, Static Sites, Jamstack, if you're a marketer who is looking for flexibility in user experience and branding, and for IT professionals that are interested in building flexible, resilient systems, we'll cover some of the benefits of this architecture for all three of these personas. And our objective today is to break down, to talk about breaking down a complex set of problems into smaller, more discrete components. We're going to talk about Drupal 8 as your content hub using JSON API and Search API with Elastic Search. And then finally, Gatsby JS with authentication, search, and a mix of static and dynamic content. So let's get started talking about the project. Who were we building for? We were building for the Magnetial Insurance Company. Magnetial is a leading provider of medical professional liability insurance with headquarters in Atlanta, Georgia. And when I first started working with Magnetial, I didn't really know much at all about liability insurance, medical liability insurance that is. And so I've learned a lot working with them over the years as we've been working with them for a few years. And they serve over 30,000 physicians in healthcare organizations. Those folks rely on their learning resources, their products, their services, covering all the aspects of healthcare liability. Magnetial team with them, Magnetial team with Mediacurrent to further their website's core mission serving and protecting its policy holders. And the new website features UX-minded design, transformation, and a complete decoupled technology upgrade with Drupal 8 and Gatsby. And Magnetial, while we said they're a mutual insurance company, it's more than that. What a mutual insurance company is, is actually the policy holders are owners of the company. And so there's a little bit different relationship there. And one of the most interesting things I learned is how much time and money that Magnetial invests in teaching their policy holders how to avoid situations where there might be a liability case against them. And so that in turn will result in fewer accidents in hospitals and fewer mistakes being made. And so they spend a lot of time trying to prepare their customers for doing the things that we need when we go to the hospital or to a doctor visit. And so they really do contribute to all of our healthcare being better than what it is or what it was. And so Sally Graves is the CIO at Magnetial. And this is what she said after we finished our project with them. I would absolutely recommend Mediacurrent to people who are embarking on a Drupal 8 project. They come with a well-rounded team of strategists, UX and UI designers, and developers tapping into an organization like Mediacurrent that can share knowledge and align toward a common goal really creates the story for success. From what we've been able to deliver to what, to the results, we're able to measure to being able to stay on budget and on time. So when we're starting out, we, you know, want to make sure we're building something that's going to be useful for them. So the kind of the core needs that they were looking for at the time was big, they were going under a big corporate rebrand. So the website was going to need to be updated to match that. They were looking for architecture that would be future proof in a sense. So the new kind of had a sense of where there would be changes in the future and wanted to be a little bit more flexible in the future. Wanted to improve the user experience for policy holders as Bob mentioned, they're all, you know, mutual owners in the business. And so we want to make it a really, you know, a great experience for them. And then performance on the front end was a big problem with the old site. And so we wanted to make sure that it was greatly improved and an excellent experience all around. And one of the key problems with the previous Drupal 7 site was that there was a lot of data being synced with Drupal from other sources. And so they really expressed that they wanted to have a single source of truth for their user data instead of trying to synchronize it across different systems. We needed to improve the integration with online learning and track, help them to be able to progressively track what people were learning as they went through the site. And also we needed a maintainable and reliable single sign on solutions. That was another key thing because over time, there's more integrations required on that front. And so they wanted it to be something that was extendable and maintainable. So we had a lot of challenges when we came into the project. We were doing support on their existing Drupal 7 code base that was developed by another agency. And we did a lot of work improving that over the years. But it was a very complex Drupal 7 code base with a lot of technical debt. So some of the challenges were there was extensive business logic that if we were going to move to Drupal 8, we were trying to figure out how do we handle that? Do we just, you know, rewrite all these custom modules? The user interface was primarily Ajax, which is very common with Drupal 7 sites. And so that was very limiting and very difficult to develop against with Drupal 7. So we knew we didn't want to go down that route again. We wanted to find a better way to develop the front end. And we knew that we needed to sync data between Drupal and other systems in the existing system. And we wanted to see if there was a way we could avoid doing that or at least limit it a lot. The code base was very difficult to understand. As I mentioned, there was a lot of technical debt. So it was very brittle and error prone. There was just tons of custom code. And so whenever a developer would come onto the project, they just had difficulty kind of figuring out where everything was. And there was a lot of rewriting code that really shouldn't have been written in the first place because there was already existing implementations you could extend. But that was just difficult to find. And then Drupal was serving as an authentication provider. So that was a single point of failure for them. So anytime we wanted to upgrade Drupal, there was a potential that we could lock out users from other systems. And so that was a major challenge to overcome. So the way we approached solving these problems was taking a very thorough look at their architecture as well as understanding their business and what possible things could be coming in the future. And I took a look at it through the lens of volatility trying to decompose the system into pieces that could isolate that volatility or that change that could come in the system. I basically just looked at the past and what had changed over the past year or two and tried to figure out how can we isolate those changes so that they're not affecting the rest of the system. And so I got into kind of applying the separations of concerns philosophy to this. So trying to separate out parts of the system that were complex so that they can be isolated and controlled a little bit better. So you don't have complexity just kind of sprawling out through the whole system. And one of the other solutions was using the right tools for each component of the system. So we looked at like what is the best front end tool for building a website? What is the best content management system? What is the best search tool? So instead of just assuming we're going to use Drupal for all of those things, we looked at what are the right tools for each component. And so the legacy architecture looked like this. We had a Drupal CMS. The website was managed by Drupal. All the business logic was in Drupal modules. All the integrations were managed in Drupal. All the user data was stored in Drupal even though the source of it might have been another system. We pushed search data out to the Apache solar index. And that was one of the things in the old system that actually worked really well. A lot of most of the other things had problems. And then identity and access management. So we used the Drupal simple SAML module in the Drupal 7 site. And it worked. But it was difficult to maintain and extend. So we broke this out into components. And we could have, I know I could have shown more components, but this is the basic stuff. We have a content management system. We need to be able to manage content. We need to have a website. And they really wanted a website that didn't have any type of limits. They wanted to be able to quickly put out new features and things like that. So it was key that we look at the website as its own thing. Not as just a part of the CMS. Maybe we could do it as the CMS in the website as one system. But we looked at them separately. We had tons of business logic, as I said. So we wanted to look at that. How is the best we handle that? Do we just do a straight up lift and shift from Drupal 7 to Drupal 8? Or do we just look at what the problems are and we try to solve them in the best way going forward? We had a lot of integration. So how should we handle that? User data was very important and we wanted to keep that secure. And we also want to make sure it's up to date. So we looked at that. Search was an important aspect. We have two different parts of search in the site, one for the learning center and one for the global site. And so we wanted to make sure that whatever decisions we make that we don't forget that we want search to work really well. And then again, identity and access management were very key and single sign on. So we looked at those as the components of the system. And we landed on this architecture Drupal as the CMS because it's the best content management system in the world. And we know it very well at media current. We know the ins and outs of it. We decided on Gatsby because the site has a lot of static content that Gatsby is just great at producing. But it also needed to be a dynamic application. So Gatsby does that well as well. And so we settled on Gatsby as a solution. We had a lot of components to the system that were hosted on AWS. And many of those were serverless components. So things like AWS Lambda. And so we settled on the serverless framework as a way for managing all that code and managing all that structure, giving a structure for that and a way to deploy that. And it's worked really well. All of our business logic for the most part is living in server side business logic. That is, is living in AWS Lambda and all the most of the integrations are there as well. And then for the user data aspect of it, we wanted to set up some sort of way to allow the front end to retrieve the data it need in the way that the front end developers could easily understand and use and not be like a big barrier. And so we looked for a long time at different solutions with that. And we landed on Apollo GraphQL server. And it's worked really well. We've got, for Search, we chose Elastic Search instead of Apache. Works really well with JavaScript frameworks. It's been a great tool for us. And then for Identity and Access Management, we landed on Auth0 as a provider for that. So let's talk about, you know, what, you know, functionally what happened? What did the website look like? So you see, you know, a big driver for this that we mentioned was Corporate Rebrand. And then of course, we're going to redesign our website. So here's a shot of the before and after. Just kind of a modern update. You can see, go to the next slide, a bigger version of that home page. So a big piece of this was, this is one of the static pages, right? So that Gatsby does really well at. So they, we gave them a reconfigural, kind of mix and match component based page builder that they could use for the home page like this. And for a lot of their landing pages, so each of these pages is a mix and match of, you know, different UI components using paragraphs on the Drupal side. We also launched, as Bob kind of alluded to, a powerful search experience for finding articles, courses, other resources. So policy owners and other prospects, they can, you know, take, they can take courses, they can get resources here. You can see, you know, they have a COVID-19 resource center with a bunch of resources for people, for doctors and practices to stay up to date. So this was a really core feature. And here you can see it, like some of these, some of these are free to everybody and some are gated content depending on whether or not you're logged into the site using, you know, referencing some of the account information coming dynamically into Drive signups. And this is how you sign up. So here's the signup flow that's happening. It's a form that's hosted in Gatsby, but then, you know, making API calls to some of the Lambda functions we had set up. And then once you're in, you get an account view. So you can keep track of content that you're enrolled in, courses you completed, you can get, you know, certificates for courses. And you can see, so like a lot of this content in here is dynamic, but then there's also some static resources in here as well. That's a good library on the left-hand side. That's like an overview of kind of the core functionality of the website. As far as why Gatsby, Bob kind of alluded to this a little bit, but we, speed and performance was a big concern on the old site and, you know, Gatsby had to do in making things fast. Security wasn't another consideration here. And so just kind of being able to break out the pieces of the website that, you know, people didn't need to know about. Like people didn't need to know about, you know, any users didn't need to know about Drupal. They didn't need to know about, you know, these APIs that we're accessing. And so being able to just, you know, output static files and not expose some of these pieces as much, it's really powerful. We wanted to take advantage of the open-source advantage, leverage the open-source advantage. So, you know, just as with Drupal, Gatsby has a huge community. It's always pushing fixes, always pushing things better at the framework level, either accessibility and performance, and we wanted to be able to take advantage of that. The developer efficiency was a huge boost for us. So, honestly, a lot of the devs that were ended up working on this project were new to Gatsby or new to some piece of this, and they were able to get up and running really fast just based on the developer experience in Gatsby. And then the content mesh is a big selling point of Gatsby of being able to combine lots of different data sources from lots of different locations. And I think we made a really great effective use of that in this project. Gatsby really helped us with that. And for the CMS, I kind of jokingly say it's a boring Drupal 8 site, and this is really me praising Drupal 8 as a platform because it's so full-featured that you really out of the box get most of what you're going to need for most of your projects. When we started the project, JSON API was not in core, however it is now. And so it was a key aspect. We used the Gatsby source Drupal plugin on the Gatsby side to work with the JSON API module. And then as far as contrib modules, we don't have a ton on the side. This is not an exhaustive list, but these are the key ones. We use the JSON API extras module to tweak and change the JSON API endpoints to what we need. Not a ton of changes there. A lot of it is disabling things that are set up by default that Gatsby doesn't need. And since we are hosting on Netlify, or if we've been hosting on another provider, we do need a way to trigger builds on that platform because Gatsby is a static site generator, and it's going to need to know when you need to rebuild the site with new content. And so we use the build hooks module, which works with Netlify. It also works with some other providers, and that allows us to use the web hooks on the hosting side and just trigger a rebuild, and then all that content gets pulled from the CMS. Search API module was a key thing, and we use, like I said, elastic search, and there's elastic search connector. And if you're hosting elastic search on AWS, there's elastic search connector AWS. And so those three modules were key to allowing us to work pretty seamlessly with elastic search. And it was pretty straightforward to set up search on this site. So I mean, the Drupal 8 site was really simple as far as like the implementation. And finally, paragraphs is a key thing because we used a component-based approach. We launched this project back in the fall of last year. And so there's been a lot of changes since then in Drupal. But at the time, paragraphs, and I still think is a very viable solution, especially for decouple projects. So paragraphs allowed us to do what we needed to do on the Drupal side to support Gatsby. And we also added post launch, but we actually added the Rain Admin theme, which is a part of the Rain install profile that Media Current maintains. And it gave us some wins. They approved the user experience for editors. Out of the box, we got paragraph previews, and it just cleaned up the overall look of the editorial experience. And the editors really appreciated that. So let's talk a little bit about authentication because that's one of the big questions. A lot of times when I first saw Gatsby, I was early on like messing around with it, trying it out. And I just never thought of it as being useful for authenticated users. Then as I got to know it better, I realized that that wasn't true. And it kind of opened my eyes to maybe Drupal doesn't have to manage users. And as I said before, like single sign on was key, we didn't want Drupal to be the single source of failure for logging into all these different systems. So we looked at a lot of different providers. We ended up settling on off zero because they have great single sign on functionality. Their universal login is a great way to have a single login UI for all of your systems. Adding integrations is pretty straightforward. They have a lot of built in ones. And we've seen through support that adding new integrations and new service providers and things like that has been very much, much easier process than we had previously experienced doing that all in-house in Drupal. They support a ton of protocols and it's a very extensible service. So I highly recommend you check that out. There are other providers, but off zero has really been great for us. So on the server side logic side, like I said, we went with Lambda. And we, you know, there are other providers that do the same thing that AWS Lambda does. Magical is an AWS place, like they are very invested in that platform. And so that was the first question for us was what platform, cloud platform do we have to work with? And so when we started working with them, one of the things we're looking back at the Drupal site was there's a ton of business logic. How do we handle this? Where does this happen? Like what do we actually need to do? And so the significant amount of that business logic was around user sign up. And so Ben showed you like what the form looks like. But behind that form, there's API calls. So when somebody puts in their policy number or their position license number, their needs, their APIs that magnitude have their private, and they use that to actually look those users up. And so we need to make API lookups in a way that was secure. But at the same time, we wanted that all to happen. We didn't want like Drupal to have to manage all that. Because we were able to keep our Drupal site pretty private and small and secure. So we didn't want to just, because it's easy for us to write Drupal modules, we didn't want to just go to that as like, well, that's the easy way we know how to do it. We went with Lambda because it gave us a lot more control over how we did it. So it allowed us to move our business logic outside of Drupal, outside of Gatsby, but while keeping it secure. And one of the beautiful things about Lambda is that we don't have to manage a server to keep that updated and secure. AWS takes care of that for you. So we use it for form handlers, creating users in Auth0, API access callbacks, launching third party service and stuff like that. A lot of different things. Another important piece of the project was a Apollo GraphQL server. So Bob kind of, this is earlier in the project, but we were referencing data from several different APIs in the old site and kind of consolidated them in Drupal, which got a little clunky in places and ended up, we ended up with data duplication issues. And that accounted for actually like most of the custom code that was in the old Drupal site. There's a lot of business logic there. And the issues ended up being around like missing data or duplicated data. And what we did is we have set up this Apollo GraphQL server to separate the data sources from the schema data normalization. So this kind of collected a bunch of the data sources from, you know, maybe Salesforce or the branch learning management system and some of the private APIs. And then it let the front end team write GraphQL queries to fetch data. And one of them, one of the really nice pieces of this is, you know, Gatsby uses GraphQL on the back end for writing the static queries. And it made some really nice, it's kind of like a streamlined the workflow for the front ender. So they weren't writing queries in different ways. Really, there was a lot of overlap. It was pretty self documenting. So the screenshot is a little bit small, but you can kind of get a sense just from looking at here, like, okay, what's the structure of the request? What data is available? One of the nice things. So this was another way that we used, you know, AWS lambda to host the server. But we only had a paper we used. So if usage went up, like this scale with that, if it went down, that wasn't used. Then it also has like a really nice local development environment. So we could we could run this locally and work with it pretty easily. Next piece is search. So I know there's been some questions about elastic search here. So elastic search powers both the global site search. So just being able to search any content on the site. And then also that learning center search that we kind of looked at before. This piece is also hosted on AWS as far as the elastic search portion of it. And then when content is created in Drupal, we use the elastic search AWS connector module to update that index in AWS. The search API Drupal module allows us to configure how we want the content to be configured. So what pieces of the content come through in the search, you know, do we want to we want to push through the title and the content type and, you know, different taxonomy terms audit and those that were able to configure that search API. And then there's a custom AWS Lambda function that provides access control for Gatsby. So we only, you know, we only permit Gatsby to access that service. And then there's also some rate limiting in the place there. And then from my perspective, what was really, really nice about this was we were able to leverage search kit, which is open source library built around elastic search. And it was really simple. I think, you know, on the old site, this was probably one of the most complicated UIs to implement. And, and it was one of the, frankly, intimidating things coming to this project is like, okay, we know we want a very complex feature rich search experience. And those things tend to be expensive and hard to build. And this was really a matter of installing that project and are starting installing that library and theming some of the features and turning on some of the features. And it was ready to end up being way, this piece ended up being way under budget, which was very nice on a project this size. And so we've talked about elastic search Lambda, Apollo GraphQL, and all of these have been hosted on AWS and all of them have been deployed with the serverless framework. So serverless framework is not actually doing anything really on the live code, but it does allow us to like work together and have like a standard way of doing things just like how Drupal and Gatsby have well documented APIs and project structure, they give you a little bit of structure so you're not out there just inventing everything yourself, figuring out how to deploy everything. So service framework has been great because it helped us with deployment and helped us with mocking data, helped us with testing out things locally, as well as logging. So once things are live on AWS, serverless framework CLI, which is basically what it is, it's a CLI, made it much easier for us to check in and see what's going on and do live debugging on AWS. And one of the big things I've been alluded to is local development. So like with Apollo, for example, we could spin up the actual Apollo server locally on our machine and just test with it and see if we could figure out where problems might be and test our local environments and things like that. And it just gave us kind of a structure just to build everything and a way to deploy the code and a way to just standardize that across the team. And it made it I think it made it much easier for folks that were a little bit newer to AWS and Lambda, because they didn't have to spend a bunch of time in AWS console, which is very intimidating and confusing. So just a few of us had experience with AWS console. And so that was enough. And most of the rest of the team that worked on this stuff, you know, they didn't have any experience with that. And they were able to just kind of work on their local machines in the command line and in their editors. So the site's been up since, I believe, September. I'm forgetting the exact launch date. But we've been living with it for a while. We've been supporting it going forward. And so now we have some context. A lot of times when you hear people talk about decouple projects, it's mostly like up to the launch point. And then everybody just assumes that like things are all, you know, rainbows and butterflies. And that's not always the case. We all know that if we've built projects and launched them before, if you actually support them, you know that there are bugs, there are problems, there are mistakes that you think you wish you would have done differently. So living with it for a while, some of the cons and some of the pros are here. One of the big cons I would say is there are more things to support. So like you've got, previously you have a Drupal 8 site and that's it. And maybe you have to worry about hosting and maybe a patchy solar or elastic search or something like that. And for the most part, that's, you know, you download one code base and you're done. So there are more things to support that affects like your team, it affects your project management team, it affects the client, affects like all the conversations. So it's a trade-off. You're having more thing, more individual things to think about. There's just more to know about when you come into the project. So one of the things about that as well is that it can be harder to debug integration points. So if you do integrations with third parties and things like that, sometimes debugging those is more difficult than if it's just in one monolith app. Because you can just spin it up locally and run things. So some of the integration points are a little more difficult to debug. Things like off zero can be challenging. So you just got to keep that in mind that that's a trade-off. Maybe the trade-off's worth it. Maybe it's not. And then onboarding, which I would say is actually a pro anicon. Onboarding, if you want to be able to onboard someone, there's going to be more things to tell them about. There's going to be more things for them to know about. The pro of that is because of the way the decoupled architecture is set up, you can have team members come onto the support project and they're only working on Gatsby and they don't really need to know about Drupal other than just setting up their environment file. They don't have to know about off zero maybe. Or maybe you need somebody to come in and just work on the Lambda functions. Well, they don't really have to know as much about Drupal. They can just go into the Node.js code and what thing do I need to add and they can test it locally. So that separation of concerns is kind of a double-edged sword. It can make more things to know about, but the individual things to know about are a lot simpler to understand by themselves. Some of the pros that we've seen from this approach is less bugs. A big part of that is moving to all Apollo GraphQL and all of our user data being kind of managed in that schema there in Apollo. And I highly recommend everybody check out GraphQL and the schema aspect of it and just kind of setting that up. It really does force you to make those decisions and think about how your data is structured and how you want people to be able to work with it, but it gives you flexibility on like how they query it and what they can request. So that's been a big win and we've seen less bugs with this launch than we have in the past with the Drupal 8 sites. Because of those less bugs, it's allowed us to focus on new features more and we've been able to push out new functionality to the site at a rapid pace. We've been able to do single sign-on integrations that I would have estimated to be maybe months, only taking weeks. We've been able to push out new landing page functionality and things like that very quickly and the client just loves that. Because we're using Gatsby, the front-end team can just go wild. They can just go full steam ahead and while the Drupal team is supporting what components they need developed on the CMS side. So they can work in parallel. We saw that during the project and we've seen that now during the support phase. And Drupal is much simpler to maintain when it's only the content management system. Like security releases, there's much less of them because we have less contrib modules and because the site is secured away from the public view. And as I said, GraphQL has been a huge win for us. And then improved performance like Gatsby is so fast, it's fast out of the box. You have to do something to make it not fast. So that's one of the big reasons I picked it early on over something like Next.js. Next is a great project that saw somebody ask about that. And it was really, I was initially going to go with Next. And then when I started to learn about Gatsby and how it wasn't as limited as I thought, decided to go that way mostly because of performance and just the documentation is so stellar over there. So their team deserves a big tip of the hat. Yeah, and I mentioned there's already less time to market for new features. We were able to add authentication providers with little effort. And that's a hat tip to Auth0 and their support. And then adding new design assets is just faster and easier. So it's been a win on the whole. It's not a bed of roses. Everything's not perfect and wonderful. But it has been a huge improvement. The client is very satisfied with the site. So I think we might have a little bit of time for questions. I think, so I've been entering some in the chat. Paul McKibbin had a good question about how do you handle it if a particular piece goes down? So Pantheon goes down for Drupal or ApollographQL, et cetera, which I thought would be a good one to cover. Yeah. Yeah. So one of the beautiful things about this static site is like if your Drupal site goes down, you know, which doesn't really happen, but it can. Something can happen. Like maybe maybe we make a mistake or something on a deploy or maybe the hosting provider has an outage. The website continues to work because there's no, and this was really key for me because there's a lot of ways you could integrate Drupal and Gatsby. You could have live real-time requirements on the CMS. And I just didn't see a need for that if we could avoid it. So Drupal, we could just completely delete the site, the Drupal site, and the Gatsby site would still exist. So it's really, what's the word? Resilient in that way. Now with Apollo, a little bit different. If the Apollo server goes down, which hasn't happened yet, and I don't expect it to, the site would still work as well. But if somebody logs in and they go to their user profile, some of that data that comes from GraphQL wouldn't be there. So failing gracefully is always a challenge. But for the most part, these systems, like if something breaks, it doesn't break the whole system. I would say one of the big points of failure could be is the authentication provider. So Office Arrow has an outage or we have a bug there that does affect people's ability to lock into the website. So hopefully that answers the question. Yeah, a few people are asking about editor previews for the site. So I can take this Bob. I think one of the interesting pieces about this was when Cloud wasn't really a thing, it was launching the preview beta right before the same launch week that we had on this project. So it didn't, it was kind of too late for us to use that. So what we ended up doing was, as kind of a workaround for not having a live preview, was we had a living style guide that the editor, the content editors could access so they could see what any kind of components would look like. But then what really made the difference ended up being that screenshot that Bob showed of the RAINN paragraphs preview where basically what we did was we just took a snapshot of each component so they could see what does this component look like before I added it to the page. So it wasn't ideal in the sense that they didn't get a real-time live preview, but there was maybe two or three people editing content on the site. So the people that were familiar with it or that were editing content got pretty familiar with kind of how things would work. And so that ended up being a thing. I think there's some work in progress to get this set up on Gatsby Cloud, but I don't think it's quite set up. Yeah, I think we're pretty close. We were talking about last week. So we've been using Gatsby Preview on some newer projects and been very, very happy with it. Somebody asked about Okta. If you looked at Okta, Bob, and I think we did evaluate Okta. We did. And, you know, Okta is great. We've used it with some other clients. There's a lot of overlap between the features and stuff. And I think it would be a solid choice for most projects. I really was a toss-up between Okta and Haas Zero. And I actually forget that there was just like a couple little things that Haas Zero provided that were, I thought, superior. And then I think it may have also come down to pricing. But I will, you know, if you go with, if you go with like the free plans on some of these things, they're very affordable, obviously, because they're free. But, you know, these authentication providers are not inexpensive. They're very, very costly. And Riley said like it's a major, the support authentication is very difficult. So it's been a huge load off of our team and the client just having a reliable partner with that. Let's see. I think we talked about how the Apollo piece fits in. Tim Woods asked about AWS bill. We don't really handle the billing. And we weren't using AWS for the website before. So I have asked the client about that as far as the AWS bill. And it has been extremely minimal, like so much that they didn't even really notice or care. And that lines up with the cost estimates I made before the project on Lambda specifically. You know, you get like a million invocations for free to start off with. If you're thinking about investing that and just experimenting, you can probably do stuff for free for a long time. But yeah, it's a good question. I think the serverless approach for most cases is going to save you money, not all. Yeah. A couple of people have asked about where the user data lives. So I think we addressed that a couple of different slides, but maybe just like a top, like a top line overview of that would be helpful. Yeah, great question actually. So the authentication, all that stuff is in Auth0. So like the user ID and Auth0 stores kind of the keys to the kingdom, because user data is stored in multiple places. So MAG uses Salesforce. And then they have a API layer in front of Salesforce that exposes what they want to expose to their APIs. And so there's an ID there for each contact in Salesforce. And that ID is stored in Auth0. And then IDs for other systems, like their learning management system is bridge. And so bridge users have IDs. And so each user in Auth0 will have basically adjacent object with a key value store of those IDs. So when they log in to Gatsby, they're authenticated with Auth0. And now Gatsby knows what those keys are. So the front end team wrote queries to the GraphQL Apollo server. And they're able to use those keys, like the user IDs to make right queries to pull the data in real time from the actual source. So it's pulled directly from the user API that MAG Mutual supports. And it's pulled directly from bridge. And if we want to add a new third party or another API in the future, we can add that. So there's just not enough time to talk about all these things, but it's pretty flexible. But things with caching, we had some concerns about that. So we were able to add a caching layer to Apollo server. So we have a static cache that is very short lived, but it does help avoid just thrashing the lambda function on the GraphQL. Anyway, I think we're about out of time, but I did want to mention that there is a survey. It's pinned at the top of the chat. If you could do us a favor and find some time to give us a feedback, Ben and I very much about continually improving. And we want to know what you liked, what you didn't like, what you learned, any questions, anything like that. You throw those in the survey. And another thing, you can stop by our booth, the media current booth. I'll be there for the next hour answering any questions I didn't get to in this. So please do stop by. And if I don't answer your question, feel free to ask it multiple times. I won't get angry. But thank you so much for your time. Ben, did you want to say anything to everybody before we drop off here? Gatsby team has a booth also. If you all want to stop by and ask any kind of Gatsby specific questions, I think Shane Thomas, who's our kind of lead Drupal developer on our side will be there today. And he's got a couple other Drupal Gatsby focus sessions at Drupal.com as well. So yeah, and I might try to stop by again later today too. So we'd love to, we'd love to catch up with you. Yeah. And I don't know if I said it is enough, but we've been working with the Gatsby team for over a year, very closely on stuff. And I'm so impressed with their ability to push out new features. And we really enjoy working with them. We're a partner with them. And so if you're looking to, you know, if you're curious about this and you ever want to talk to either one of us, you can always reach out. Media Current would love to talk to you about a couple of projects, Drupal A projects, Gatsby projects, all that kind of stuff. So be sure and stop by our site and stop by the booth and we'll talk to you then. All right. So I guess we just leave now. Yeah. All right. Well, this was fun. I'm just going to press the leave button. So bye everybody. All right. Bye everybody. Enjoy the rest of the conference.