 My name is Russ Danner, and I'm VP of Products at CrafterCMS. Today we're going to talk about GraphQL and CrafterCMS. And we're going to start, we're all things start at the beginning. Just what is GraphQL? Is it a query language? Is it an alternative to REST? Is it an API gateway? These are the kinds of questions that we hear from folks that are new to GraphQL. And it can be used in all of those ways. But it's not what GraphQL is. What GraphQL is, is a specification for data retrieval and data mutation that was started by a company called Meta and that they later contributed to the open source community. GraphQL is now maintained and managed by the Linux Foundation. In this specification, there are two parts. The first part is a schema in which we have a strongly typed data dictionary of objects, the objects properties, and the relationships between those objects. And the second component along with that schema is a query language definition. So with a strongly typed schema and a query language, we can now interrogate systems by asking them to return their structure to us as well as the data in those structures. Well, isn't that just what SQL and NoSQL provide? That's kind of an obvious question. Well, the difference here is that GraphQL is implementation diagnostic. So any kind of server can implement the GraphQL specification and present itself as a GraphQL server and then map onto that backend technology. Whereas SQL and NoSQL databases tend to be very implementation specific. By contrast with GraphQL, it's not about the store. Instead, it's about the GraphQL implementation which is required to expose both the schema and map the query language onto the backend system. And it's the fact that GraphQL requires both of these that is key. To illustrate this further, let's take a look at this example. We've got a client making a single GraphQL request to the GraphQL server. The GraphQL server then interprets that single GraphQL query into backend system queries. And in this case, three backend system queries. So it's the fact that GraphQL is by its design both client and back and agnostic. And at the same time, still a standard that is the key difference between it and standards like SQL. This positions the GraphQL query language to be one query language to rule them all. And on top of its query capabilities, GraphQL comes with some special powers. And of these, one of the most powerful is its ability to support what we would call API gateways, federations or subgraphs. Because of its graph oriented nature and discoverability support, you can layer one graph upon another graph and then combine those subgraphs into a single graph. This is a potent capability because then you can have many GraphQL implementations that are all exposed as one integrated API. Look at our example here. We can see that there's an individual GraphQL graph for products, content, users and inventory. Each of these is a facade of the implementation technology for the specific system. More importantly, we can see that we have several clients at the top, web apps, mobile apps and so on. And each of these are able to access all of this data through a single API endpoint in order to retrieve and operate on the integrated whole. How awesome is that? Another kind of superpower is that you don't have the problem of overfetching that you have with REST based systems. This is why people often talk about GraphQL as an alternative to REST APIs. In GraphQL, you use a single HTTP request to send a query across potentially many resources and ask for only specific data elements of each resource that you want back. By contrast, in REST, you send a request for each resource and get back a standard or fixed response with a superset of data than the data that you need. This is a very inefficient and arguably less secure way to request data than GraphQL provides. You make more calls and transport more data than you are likely to need. And we know when it comes to performance and security, less is more. And this is what you see in the example here. On the left, we have an example of a client making multiple REST API requests and getting back fixed responses. And on the right, we have a single GraphQL request being sent and it's getting back just the data it asked for and no more. With GraphQL, we also have some control over the shape of the response. And now when I say the word shape, that's a technical term. Shape means the structure of the response, including the names of the data elements. This can be very important because it provides the consumer with the flexibility it needs to handle changes over time. Renames and removal of fields are easier to deal with and it's even possible in some cases to mimic responses of legacy systems that you might be replacing. Anyone that has been around API development for any amount of time knows that you have to version APIs because consumers become dependent on the calling and response interfaces. If we change those interfaces, then our consumers are broken. And as a result, we must make a new version of each API when we change it. These can be kind of a pain to manage and their technical debt. GraphQL doesn't have this issue. Since GraphQL's calling and response interface is a query language, consumers describe what they want and how they want the response to look when it returns. This means there's no change to this calling convention as the backend system mutates. Thus, there's no need to version APIs. This is a big deal because it simplifies what we need to manage and it lowers technical debt. GraphQL also has an awesome ecosystem. Everything from developer tools like IDEs to framework plugins and language bindings are included in this ecosystem. Because it's a spec, it's easy to integrate with and create tools for it. And because GraphQL is so widely applicable, there's a tremendous incentive to do so. This leads to a lot of adoption and a virtuous cycle with respect to the community, the ecosystem, and adoption. Just to make sure all of this is concrete, let's take a look at an example of a GraphQL query and a response. So on the left-hand side of the query, we can see that we're asking for a social post. Specifically, we're asking for the title and the comments of the post, along with the comments author. There's a couple more things to note here. The first is that we're asking for what we need in order to satisfy our use case, and only that. We don't need every data element of the post, so we don't ask about it. The second point of interest is that we can see for each comment that the kind of author we can receive back for each comment can be different. And we can see that the query itself has a mechanism for dealing with those different kinds of objects and returning them in a similar fashion to the calling client. On the right-hand side here, we can see that we're getting back the structure that we've asked for in a JSON format. So looking at this closely, we can see just how powerful this approach is. The last thing to note here is kind of hard to see without explaining it. You have to specify what you want back. And if you follow this idea to its logical conclusion, you realize that you can't write a query that will result in an arbitrary response. And you can't write a query that has an arbitrary level of nesting. And as we'll see later, there are some use cases where these two types of queries are relevant. And then you'll need to decide whether GraphQL is the right interface or not. Or instead, how you're gonna model your query and the response and the consumption of that response in order to work around those rules. GraphQL, like any technology, has some gotchas and areas to watch. But generally speaking, it's very compelling. At CrafterCMS, we're very excited about GraphQL. And I want to talk a little bit about why we think GraphQL is so important for headless CMS platforms like CrafterCMS. And here's the big one. GraphQL is technology agnostic on both the front and back end. And it already has a large amount of adoption, tool support, and integration across a wide range of programming languages, development frameworks, and platforms. GraphQL is really the first opportunity in the content management space to have a widely adopted, widely understood, widely applicable common API. So-called standard APIs in the content management space like IECM, JCR, and CMIS have generally failed. And I think it's for two main reasons. The first is that they were too often technology specific. And the second and more important reason is that in a way, they were too content management specific and niche, all which leads to adoption issues. GraphQL solves both of these issues, and that's huge. As we talked about, GraphQL also gives you a degree of control over the shape of your API responses. This is the flexibility that we don't get from REST APIs and that we don't get from the many headless CMSs that only support REST APIs. Remember, this kind of flexibility helps us avoid vendor lock-in and it helps us deal with use cases that would otherwise require API versioning, which as we discussed is technical debt. And the last thing that I'll point out here is the support for API gateways, federations, and subgraphs is a really big deal in the content management space. Marrying content to business objects is a major and very common use case in the content management space. Products live in product information management systems. Marketing content lives in content management systems, but the object that our applications want back, what they want to present to users is a combination of the product data and the marketing content. GraphQL makes marrying these types of objects together very seamless, efficient, and easy-for-end user applications, and that's a major, major win. Now let's talk specifically about GraphQL with Crafter CMS. And for those of you who don't know Crafter, let me give you a quick overview. Crafter CMS is an open-source, headless CMS. Unlike the other thousands of CMS platforms out there, Crafter is built on top of Git. Git gives Crafter CMS its own set of superpowers. Our Git-based versioning is like a time machine. We can reproduce any moment at any time to support advanced editorial use cases like rollbacks or audits, and we can support working in teams based on branches for use cases like redesigns or the segregation of sensitive content and the team that's working around that sensitive content from the larger team. And these are very difficult problems to solve otherwise. Also, leveraging Git-based workflow mechanics, Crafter CMS fits directly into your DevOps process, making it easy to move content and code between environments. This tight integration of DevOps with the content process is called DevContentOps. And unlike a handful of other Git-based CMSs out there which are generally intended for static sites, Crafter CMS is designed to manage dynamic and personalized content for any channel. To support this, content authors need great authoring tools and Crafter CMS has a very robust and easy to use set of in-context editing and drag and drop content authoring tools for content authors. And of course, Crafter CMS supports a variety of API endpoints, one of which is GraphQL. We benefit from GraphQL in all of the ways that we've discussed. In addition to those, there are a few Crafter CMS specific things about our GraphQL implementation that I'd like to point out. And the first is that our GraphQL implementation is completely native and very fast. GraphQL is an afterthought for many CMS platforms and it has been bolted on to their existing APIs. With the bolt-on approach, one GraphQL query may turn into a large number of actual CMS queries. Crafter CMS takes the opposite approach to this. We see GraphQL as strategic, so we've made GraphQL native to our system. And to the extent possible, one GraphQL query is one CMS query within Crafter CMS. Another thing that we do is automatically generate your GraphQL schema for you so you don't have to. When you define content objects in Crafter CMS, we automatically configure your GraphQL schema for you saving you time and effort. And lastly, we provide programmatic extension points for you within our GraphQL server so that you can define your own schema elements and fetches. From our last point, you know that we're all about low code support. We don't want you to have to program or do more work than you need to, but we know that we can't think of everything. So we've given you the extension points that you need so that you'll always have the flexibility to handle any kind of integration scenario that you face. Okay, let me sum this up by saying while no technology is a silver bullet, GraphQL is a powerful and important technology that has a large and growing base of adoption. We feel that it's a fundamental technology for the CMS space. At Crafter CMS, we're committed not only to having and supporting a GraphQL server, we're committed to having one of the best, if not the best implementations for headless CMS out there in the open source space. And with that, I'd like to thank you very much for your time. I hope you learned something about GraphQL and about Crafter CMS. If you're interested in learning more about Crafter CMS, please visit us online at craftercms.com and craftercms.org. Thanks and have a great day.