The Drupal API Client

Uh, thank you for coming here. This is the Drupal API client. Um, very excited to be here at MidCamp today. And we'll get moving. We'll get moving. Is the mic working still? Oh, yeah. The microphone. Wow. Usually I don't need a microphone, but that definitely makes it clear to people that I'm speaking. Uh. We're good. Real good start. Real good start to this session so far. And I've been on a wonderful ride with internet here today, so hopefully that keeps working. But, uh, yeah, I am Brian Perry. That's me. I'm a great surfer. Everybody grab a seat. Um, yeah, I live in the suburbs. Uh, I drove out here, but did stay at the hotel last night, so I didn't have to have a 90 minute commute this morning. Um, and, uh, yeah, I love, uh, Drupal. And, uh, front end development. Decoupled. Drupal. Relevant to what we'll be talking about today. And, uh, also love Nintendo. I got this this on today, uh, games I'm playing currently, I am just at the edge of 100%, uh, Super Mario Wonder. I'm on the final level.

Uh, and it's really, really hard. Uh, also non Nintendo. I am playing Baldur's Gate three, which is very fun. And this weird, like poker roguelite game called Lotro. Uh, it's amazing. If you have any interest in weird card games, you'll lose most of your life to it though, so be warned. Uh, I work at a chapter three. I've worked at chapter three for five days. So yeah, not. Wow. Thanks, everyone. Uh, yeah. And, uh, I'm excited to be working there. Continue my, uh, decoupled Drupal journey. I think it aligns, uh, nicely with some of the things we'll be talking about today. And excited to also get more involved with their next for Drupal project. And, uh, also, uh, I previously worked at pantheon and they sponsored, uh, time for a lot of the, the work we'll be talking about today too. So I wanted to thank them. And also, I am aware that those companies are related. I'm aware of that. Um, so another side note before we really dive in, uh, just a fun little side project I've been working on.

There's a Drupal View transitions module, and these slides are actually just a Drupal site. These are all Drupal nodes, and it's using the HTML View Transitions API for animations. It's fun. So what we're going to be talking about is the Drupal API client project, and what the Drupal API client is a set of JavaScript packages to help source data from common Drupal APIs. Um, and the goal, it's definitely not something that is official by any means, but we're going to try to make a pitch for it is. I hope that this can be offered under the Drupal namespace on npm someday, and we'll talk more about what that means and why I think it's important. Uh, it also was one of the projects funded by Pittsburgh at last. Drupal con. Um, so, uh, you shared a video on what we're trying to do and was amazing enough to be, uh, voted on to be funded by the community for $10,000, which then means that this becomes a $10,000 question. Uh, why does Drupal need an API client? So I think there's a handful of reasons why it does.

Uh, but one of them, I think, can be told by searching on npm. So if you search on npm for Drupal, and I would imagine a front end developer who maybe was told, hey, you have to work with Drupal now, might do this. Um, the results you get back are kind of confusing. The first result, at least when I took the screenshot, was an implementation of parts of Drupal's User Access Control API. There are other things that look like, uh, you know, a Drupal SDK for results down very specific things, like an image style generator. And if you know enough to look for an org on npm, there is a Drupal org for Drupal engineering. Uh, but there are currently just four very specific packages, a couple that are used by core, a couple that support the decoupled menus endpoint. Um, but to somebody new to Drupal, it might not be clear what all these things are. And if you instead search for WordPress, uh, you get results that are more in line with kind of what I would expect. The very first thing is a client for working with WordPress.

There's a Gatsby plugin, and then there's also a lot of things under the WordPress namespace. Um, I think a lot of that is driven by the Gutenberg editor and the fact that a lot of that is, um, written in react and published on NPM, but still, you see a lot of WordPress packages that make a little more sense together in context. And then this is not a perfect 1 to 1 comparison because Contentful is a fully headless CMS. Um, but, you know, think of a developer who's working with, uh, Contentful on the back end. Obviously you have a lot of SDKs and very specific packages for interacting with Contentful that are clearly, you know, namespaced associated with Contentful. So the Drupal story on npm is confusing. And I think that if it was a little clearer, um, it would definitely be good for Drupal and make it, you know, clearer that Drupal is serious about JavaScript. Uh, another reason why I think this needs to exist is people keep making it, myself included. I have a previous project called Drupal States that is similar.

Um, there is a Drupal js SDK, a Drupal SDK, the next for Drupal project has its own client. Uh, there's a project that's been, uh, under active development recently called Node Hive, which also created a client around the time we were starting to work on, on this, um, there's another one called Drupal Kit. So for whatever reason, people do keep building, uh, these sorts of APIs and SDKs over and over, and they're all pretty similar. You know, there's a set of base things that they all need to do. So this is an example, little code snippet using Drupal State, the library that I've maintained in the past. And you provide the root of your Drupal instance. You can provide a prefix for your JSON API endpoint, and then you can call, uh, await store Getobject and the type of object that you're looking to get in this case node recipe. Um, and then you get back all of the data from JSON API. Or you can request an individual resource from Drupal if you know the ID, the next for Drupal client looks pretty similar.

You create an instance of the client, you provide the root of your Drupal instance, and then it's get resource collection with the resource type. Uh, but there are definitely some differences. So some of these projects serve different needs and priorities. For example, the next for Drupal client makes some assumptions about react, and it assumes you're going to use it in a react project. Those assumptions about Next JS. Um, so some are frameworks specific, some are not. Uh, they've all got different sets of maintainers with different priorities. Um, and there is no, you know, in the way that you can think about Drupal core projects or Drupal core subsystems. There is no official Drupal answer or official Drupal group of people working on this question. Uh, so we all could be wrong about this being something that needs to exist, but obviously I don't think so. Um, so going back to Pittsburgh. Um, so this is what we committed to as part of that funding. Uh, we wanted to do a what we're calling a vertical slice, proof of concept.

Um, so a very initial release that was actually published on NPM that people could start interacting with and give us feedback on. Um, we also are planning on creating a proposal for the Drupal JavaScript maintainers about why this could make sense under the Drupal namespace. Um, and a 1.0 release of JSON API client that interacts with Drupal's JSON API. And the specifically the way that we're approaching solving this problem. And this was kind of the biggest part of how we were structuring the proof of concept is that we're trying to design it in such a way that even though the first thing we're shipping is to talk to JSON API, it can support multiple clients in the future. So there's a base class which we'll take a look at. And then any instance for a specific API like our JSON API client extends that base class. And the idea is that there's essentially stuff that you need to do to talk to Drupal's APIs like authenticate and, you know, potentially cache data and then things that are going to be specific to the API that you're using, be it JSON API or GraphQL or decoupled router.

But having that base class hopefully knocks out a whole bunch of stuff that all of these different solutions need to do one way or the other. So this we'll just take a quick look at our very earliest demo here. Okay. Internet is still working. Um, and we'll just take just a quick look here at what this looks like in practice. But so there is the, um, can people see okay, do we need to maybe do the lights or something? Everybody seems fine or silent. Cool. Uh, so, yeah, this is the API client base class, and it has a few properties, a base URL and the API prefix. And then the one configurable option that we did in this, this demo is a custom fetch method. So um, then the one thing that is implemented by default here is is fetch. So by default this uses just regular JavaScript fetch. And then if we look at our JSON API client, um, it extends that API client class and provides a different default for the API prefix because JSON API uses JSON API by default. Um, and then it implements a get collection method, which will construct the endpoint that needs to talk to you on the Drupal side and make a fetch request using either the default JavaScript fetch or the fetch method that you provide, and then returns the data.

And then if we then take this same base class and extend it to create a GraphQL client, we still have the fetch method and all the properties that are available by default. So the thing that we implement for a GraphQL client would be this query method. So similar deal. It's just the way it constructs its API endpoint is a little bit different. And then it uses post and provides a body of the request to specify the shape of the object that you want back. So, um, the base class is the same, but there's just those two different methods for those different APIs in this case. So hopefully that gives you a little bit of an idea of what it means to have this extendable base class and why I think it's important. All right. Yeah. And here's some more things that this approach should make possible. So you could extend the class to make a GraphQL client like we saw. Or you could take the JSON API client and extend that to have your own set of opinions. So if you want to use a specific caching mechanism or state management solution, you could do that pretty easily and quickly.

Um, maybe you just want to use the authentication methods that the base class provides, so you don't have to spend time writing custom code to authenticate with Drupal. Um, or, you know, maybe you just want to take, uh, one of these clients and bundle it in a starter kit of some kind. All that should be possible. So for the vertical slice POC, which we completed a while back now we just focused in on getting a collection of resources for a specific resource type. So get get all your pages, get all your articles, get all your recipes. Um, and you know, we were trying to make it, you know, slice that was pretty deep as far as the configuration options. So we, uh, did at least an initial implementation of all of our different configuration options, which we'll go into detail on. Um, but that gave us enough to publish something that does work for a specific use case. Um, hopefully gave us a good base to work on as far as defining all those options. So we were just kind of expanding on them.

Um, but the biggest thing is it gave us a way to get community feedback people could actually get hands on, try it out and let us know, uh, where they thought we were going. And since then, we've just kept working on our 1.0 scope, and we're very, very close. Uh, spoiler alert. I'll mention that will be at the contrib day on Friday. So if you're looking to to help out, there's some last things we're trying to wrap up. But we've had a number of releases. Uh, we're at 0.7.2 so far. Um, but our JSON API client is something that you can install on npm right now. So I'll go into a few more examples. Um, as far as what we've built so far and what's going to be in our 1.0. Um, and I'm going to do it from our docs, which we've been working on recently. Um, and, uh, these are actually I'll zoom in a little bit. Um, these are actually published on GitLab pages. Um, and is a contains interactive examples that actually use the client itself. So all the examples that we see here are actually making calls out to a Drupal instance at build time and actually rendering components in the docs, which is pretty cool.

So, uh, installing it, uh, pretty straightforward. Uh, if you've used a package like this before, uh, a couple different ways you can do it. You can use the package manager of choice to install your package. We also wanted to make sure that we supported using a CDN import. Um, so, uh, JS deliver is compatible with what we built so far. So you can instead just do a script inline and import it as a module if you wanted to. And then for uh, what you need on the back end, um, you know, predominantly focused on Drupal core, uh, specifically the JSON API module, you need to enable that. Um, we also did build in support for Decoupled Router because that's a really common use case. So if you wanted to use the methods that use decoupled router, which we'll talk about, you have to have that installed and enabled as well. So, um, let's actually go through we have a little tutorial here. Um, and that's a good way to show some of the different options that are possible. Um, with the client. That too big.

We're going to go with that. Uh, okay. So this very first example, um, let's, uh, we're going to try to source a list of recipes from Drupal using the umami umami demo data profile. So, um, and the examples in the documentation here, it uses astro components, which is a another JavaScript framework. The reason that we're using those in these examples is that it just ends up being pretty framework agnostic. The code examples. So we have JavaScript that is in between these, uh, three dashes here and then markup below that. In most case most cases is pretty straightforward HTML looking markup. Um, but we create our instance of the JSON API client and pass, uh, our base URL. And then here we say await client dot get collection. And a resource type is node recipe. So then we have that recipes object that we get back and we can iterate over it. And in this case we just spit out all of the titles for the recipes. So you'll see here we have a list of recipe titles. Um, you know, not all that complicated, but just a simple example.

Few lines of code that allows us to get stuff from Drupal. So, um, in this case, uh, let's see. Yeah. All right. So in this example, what we're kind of working towards so much scrolling here is, uh, so just the titles. Pretty boring. Um, but let's say that we instead wanted to get a simple grid of recipe cards that are displaying in our component here. So to do that, I think I skipped over some things in this example, but, um, yeah, here we go. Yeah, I did jump jump past some of it. So we do. We made some changes here just in styling to make this a grid. And then, uh, we wanted to add a couple of different fields to the card. So we added the difficulty field here. And also we made a link just using the path alias. But the thing that we don't have access to is the image. So if we take a look at the actual response that we get back from JSON API, we'll see that there's things under attributes and we don't see our image field, but we do see that the field media image under relationships.

But the data is just an ID. So if you've used JSON API before, you're probably familiar with this in the concept of relationships. But to get the data for these related entities, we need to adjust the add some additional parameters to our request to JSON API to get all of that data back. So based on this first example, we don't have images. But the client can also make it easier to get that data back. So that was missing from the context of the example here. So now if we wanted to get the media image field as well, there is an options object that we can pass to our get collection request. And we can provide a query string, which is just the query string that you would actually add on to your fetch request to JSON API. So the format here is include equals field media image. However, if we look at the data that we get back there, um we do have that. But then the way things are set up with media in the umami demo, um, the media image still references something else. So it has its own set of relationships to either another field media image that is the actual file or a thumbnail in this case.

So what we actually want is the thumbnail for this grid. So we can adjust our query string to be uh field media image dot thumbnail. And then if we do that, we will get in the included section of the object. All of those results, including the actual files for the thumbnail. And then we also support, um, there's a popular package JSON, API params, which is just a little helper to be able to construct those query strings with all of the options that JSON API supports. So you can include filters, sorting, etc., etc. makes it a lot easier. So you can use that library. And then there's a get query string method that you can call that just spits out the query string that you would need to pass in to the client. So we did all that, and now we have the thumbnail paths that we can add to our grid. And we just added, um, some additional spacing so that the images line up here. Um, but you know, as we saw on this object here, there's the results that we get for each of the individual recipes. But then they referenced by IDs, things that are included that are in that separate included section.

So I'm not even going to really fully go through all of the details of this snippet of code. But to basically map through those relationships, you need to kind of do a little gymnastics here. You need to, for your card, figure out the ID of the media entity, and then that's going to reference the file. So you kind of got to map through there to get the file path that you want at the end of the day. And then at that point you can use that, uh, URL that you got in your image source. And now we see images in our grid. Uh, there's a little note here. So this is a pretty intentionally simple example. If you're using like a meta framework like Astro or Next JS or something like that, you most likely want to use their image component, which can do some additional image processing, handle responsive images and things like that. Um, but trying to keep this kind of simple and framework agnostic. So, um, you know, as I mentioned, we still did have to jump through a whole lot of hoops to be able to kind of follow that path of those entity relationships.

Um, the client also does provide some options to simplify that a little bit. So it has an option to provide a serializer. And specifically what we're looking to do here is deserialize the results. So it is a flatter JavaScript object common option among many of these clients. So here's what that actually ends up looking like. So uh, JSON is a popular package for this. There are a handful of other ones. Um, it basically just expects that there is a method serialized and a method deserialize, and it can be compatible with this, but we pass in in the options object under serializer, an instance of this JSON serializer. And then when we do that, when we make the same request, it's automatically going to deserialize the data that we get back. And here's what it ends up looking like. It's a lot flatter. And if we look for example for the field media image, where are you? Right here. Um, it actually has everything that we're looking for, like the thumbnail right on that object. And we don't have to go through and traverse all of those things to get at it.

So, you know, it's kind of a trade off. Um, but the option exists to use it either way. If you want to interact with JSON API in its core manner, kind of following the spec, you can, if it's easier to work with this data by, uh, transforming it, you can do that too, but that lets us just go. Field media image dot thumbnail dot uri URL. So the end result is that we get to throw away that like six lines of code that was jumping through hoops to get all of those relationships. And also, even when we're referencing our recipes, it's a lot simpler. Recipe title recipe dot field difficulty. We don't have to go into attributes and relationships and includes and so on. Uh, so some other things that, uh, we can do that are handled in this example. Uh, Drupal has a lot of, uh, offers a lot of things around, uh, localized and translated content. So that's something that we support as well. And the umami demo is translated. So you can provide a default locale when you create an instance of the client.

So if we provide default locale of ES, it'll add that when making its request to JSON API and based on just that one line, the end result is that we get all of our recipes in Spanish. And then while you can provide a default, it's also there's an options object for any of the individual methods that you call if you're getting a resource or a collection or anything like that. So you can overwrite it. So even though in this case, uh, the client is created to use Spanish by default, you can override it when you make a specific request to get something in English. So obviously that would be handy if you had language switcher or something like that on your site. Um, let's see. And yeah, we're still building out these, uh, docs. But before we jump into some of the other options, just one last thing to show in the docs here. Um, one other thing that we're looking to do is just have a lot of examples with different frameworks, um, you know, really important in my opinion, anyway, that this be framework agnostic so that as things fall in and out of favor in the Drupal community, new JavaScript frameworks come along.

You should still have this base to work in your framework of choice. So we have just an example here of using it with react. And if you're using just plain regular client side react, you have to use react. Use effect when you fetch the data. Nothing really special about our library in that case, but this just does provide a working example actually running using react in the docs that just shows you how you could source some data. Uh, so quickly, uh, some other configuration options that the client offers. We probably won't go into like, super huge detail on any of these, but, uh, authentication, that's obviously a big one. Um, so you can work anonymously or you can use right now we support, uh, basic auth, OAuth, and also a completely custom authorization header you can provide. Uh, another thing that has come up is, uh, cookie authentication in the case of like a progressively decoupled use case. And that's something that we have a little bit more work to do to see if that works with what we have today.

Um, so basically you provide an authentication option and depending on the method that you're using, like here is just a simple example of basic authentication. You would provide your credentials. Or in the case of OAuth you provide a token, um, and it will manage your authentication and add that to requests. And for something like uh, OAuth it also handles uh dealing with the token as well. So it'll get the token initially. Check to make sure that it's valid. And if it expires it will get it for you for future requests. So hopefully that's something that you code that you're just not going to have to write. Um, also we use, uh, kind of core fetch, um, by default, but you can provide a alternative fetch compatible method if you have some other fetch library that you want to use or for example, this, uh, this example right here still uses fetch, but just provides a specific set of headers. When any of the fetch requests are made. Something that I've, I've done similar to that in the past is getting information related to Drupal's cache tags so that you can either pass them along on the front end or invalidate routes when things change.

And then also we provide a option for local caching. So this shows that. So there's a cache option. And your cache method here just needs to have a get method and a set method. So if that's provided and there's a lot of different things that you could use or you know, configure this in a way to be compatible with that. In this example we're just using a library called node cache. Um this meant to run on the server side. But in that case whenever you make any requests it will, uh, you know, the first time hit JSON API, but then it will set that in the cache using a hash of the request that you made. And then if you make that request again, it will check the cache first. And if it exists, it'll just return that from the cache rather than having to talk to Drupal again. Uh, and, you know, it's optional. There's a lot of cases where having things cached might not be what you want. So you could have it use a cache by default, not use a cache. And also on individual requests you can override it to force it to bypass the cache.

Hoops and logging. So this is just a simple logging example. There's a debug method or option that you can provide that just has additional debug logging. You'll see it says that we're fetching this particular endpoint. The other thing that it supports is you can provide your own set of logging methods. So we just use console logging equivalents by default. But if you had an actual logging library you wanted to use, you can provide that as well. You know, really trying to focus on all these options. So this can be a base that people can hopefully build on. And then also we support all Crud operations with JSON API so you can get your data, but you can also delete things, modify things. You obviously need to be authenticated to do that. Um, but here is just a simple example that creates a new resource, um, and just provides an object with the fields that we want to specify when we create our new page. So obviously there's a lot that is possible as a result of that. So, uh, a little more, a little more time here.

So that was an overview of what we've built so far. Um, and we're close to 1.0. We fully expect to have 1.0 out in time for Drupal con, which is exciting because we can show up and say, yeah, we made the thing. Thank you for that money. Um, but just a few other odds and ends as we wrap up here. So one other thing that has kind of come up along the way, um, when we first pitched this and just early feedback that we got is why not use an off the shelf solution for this? Um, for example, there's a lot of things that can talk to JSON API, right? Um, hopefully what we kind of somewhat painstakingly outlined hopefully makes that obvious. But, you know, the idea here is that we really want to be able to easily support some Drupal specific things, whether it's common Drupal authentication methods or as this progresses, like if people do adopt this library and use it, there's I think there's more specific use cases that we can do more to have helpers for things like, um, you know, working with media, for example, or menus, etc., etc.

and obviously if we picked some sort of off the shelf solution, none of that is going to be included within it. Um, and we did look at some of the more fully featured options for this, and it really prevented us from being able to make something that could be extended. So that idea of having like, all of those base Drupal things that you need when you talk to an API, um, we wouldn't really be able to have those if we wanted to support another API type. And then also it allows us to keep our our dependencies pretty low here. Um, we're not, you know, in on a specific library that may or may not be maintained and so on. Um, also, some things that were kind of fun along the way is some of our developer tooling here and figuring out how to do some of this stuff in a Drupal general project on GitLab. So the project is using TypeScript. We do. We did come up with a proposal for what our TypeScript coding standards should be, which actually extends and builds on Drupal's coding standards. I know Drupal itself doesn't use TypeScript, but I wonder if there's a need in the community for kind of defining that.

Um, we use Type Doc for our API documentation. If we jump back to our docs here, um, based on code comments, it generates, uh, full API documentation for all of our classes and types and things like that. Uh. What else? We're using npm as a package manager, mainly because that is really good working within a monorepo. We have right now three packages that we publish on npm and uh, a couple of different examples as well. Um, npm handles that really well. Uh, we're using VI test for testing eslint and prettier. Um, we are. We also have recently fully automated our publishing on GitLab. So we're using a project called Change Set change Sets to manage like our, um, uh, uh, change log and then also publish to npm. But there is a pretty good open source library for that. So we're doing that through GitLab CI. So if there is a change set and we merge to our main branch, it will automatically publish a release to npm, which is nice. Um, for our docs. Uh, we're using Astro and specifically a starter kit called Starlite.

And the cool thing about Astro that we got into a little bit is that Astro works with all kinds of different frameworks, so you can have react components, svelte components, etc. in an Astro project, and that makes it really easy for us to actually show real world examples of how you use this library with all the different frameworks. And those docs are published on GitLab pages, which is nice. Uh, so, uh, going all the way back to Pittsburgh, uh, you might also be wondering about all of the money, um, things we have done with those funds is we established an open collective. We have paid some of our contributors. Um, you know, it's kind of a weird bullet point, but I think it's true. Just the Pittsburgh itself. But also having funds and being sponsored increases visibility and also just forces us to be a little bit more buttoned up and serious about this. Um, but also at this point, it also has provided us a cushion for things like maintenance and hosting going forward, if we need to have, um, you know, like live Drupal examples that people can experiment with, uh, that are online.

Uh, however, as a famous man once said, mo money, mo problems. Uh, it certainly hasn't been, uh, without its challenges having, uh, the funds here, uh, working with Open Collective really personally wasn't quite what I expected. It has made it hard to work with our funds. Um, and open collected it. Open collective itself is kind of going through some changes as far as, um, some of the organizations within Open Collective have closed and exactly how they're managing funds and things like that. Um, and also just the fun thing, uh, for me, that I kind of knew going into this, but there's also the tax liability of this, and there's just a lot of ways that these funds, um, you know, had to be used for working with open collective or taxes that we weren't able to just, uh, use to fund development on the project. So, uh, beyond 1.0, um, so we are going to make the pitch, I'm hoping around Drupal con and hoping I can talk to some people face to face. The pitch about something like this being offered under the Drupal namespace.

Maybe what it's going to take is just people actually adopting this and using this in their projects, and being able to point to npm downloads or something like that, but still trying to make that pitch. I think that having a utility like this as kind of an official Drupal thing would be really good for Drupal. There's tons of things that we can still do with our docs. I think we have a good start, but want to make sure that we have great documentation. Um, the decoupled Drupal documentation on Drupal.org, uh, is very incomplete. And, you know, I can point to myself for that. Um, but I think the better documentation around these use cases for Drupal in general will be just a good thing. Um, there's a lot of demos and showcase instances and starter kits and things that we could build. Um, but probably most importantly, the thing that I would like to do with a 1.0 out in the world is really try to prioritize and focus on community use cases. So what what are you doing with this that we could make easier?

What does the client like this not achieve for you, uh, that we could actually spend time on to again, just knock one other thing off of that checklist that you need to do, um, when dealing with this data outside of Drupal. And then another area that I think is a really interesting area of focus for this project is around types. Um, so we do have a set of types that we ship. And you can use this project in vanilla JavaScript or with TypeScript. Um, but an area that there's a lot of opportunity, I think is working with, um, JSON schema or open API to be able to kind of automatically detect the shape of your data within Drupal, and then strongly type that when you're dealing with it and automating a lot of that stuff. So that can provide, you know, a much easier path to strong typing on these front end projects. Really nice developer experience and autocomplete based on what you do and don't have in Drupal. And then also that, you know, there is the fact that we did establish this open collective and, you know, potentially there's the opportunity for this collective to focus on other, uh, Drupal adjacent JavaScript things in the future.

Um, and yeah, the biggest thing is just that I think if, uh, you know, I think this was important to build and, uh, but if the community adopts it, we all win. Um, hopefully this will be a useful thing, but it will continue to get better and better the more that we can specifically address what people actually need to do and use on these projects. Or, you know, if, uh, you know, over time, something other than JSON APIs, the thing that the community rallies around this hopefully gives us a really good starting point to create a client for that. Um, but, you know, if it isn't adopted, then at least we had some fun along the way. And do you want to thank, uh, folks who have contributed? Uh, we have a couple of other, uh, maintainers, Kobe and Prateek, um, a handful of people who have contributed along the way. And folks that I also did, uh, talk to early on to kind of understand most of these are people who have maintained similar projects. So, you know, what, if there was a kind of Voltron version of this, what would it need to do?

Um, and got some great early feedback from folks as well. And if you are interested in getting involved, we are the API client project on Drupal.org. We have an API client channel on Drupal Slack. We have a pretty simple slack meetings every other week, really just focusing on kind of what what we're working on, what we've done, if we've had any releases. Um, pretty low stress, but feel free to drop in on those. Um, and then also I'll be at uh, contribution Day on Friday. So we do have a couple of last issues that we're trying to take care of for, for 1.0. But the biggest thing is just any, any feedback we can get from anybody, you know, going through the docs or, you know, what would you use this for or questions you have about it? Um, we'd love to talk about it. And, uh, time for Q and A if we have it.

>>:
Yes, yes. So you demonstrated a library for caching caching requests, right? Yep. Uh.

>>:
If something changes. In size, it will. Uh, does. Cash will be a resident back in line. Yeah. The question. The question. Oh, sorry. Yeah. The. Yeah. So the question was, uh, we have, uh, we support cashing and the question was if something changes on the Drupal side, do we invalidate the cache? So we don't right now. But that's definitely a use case that I think would make sense for us to expand on. And, you know, another another place where we can improve in the future. So. Yes. Where can we find the documentation that you. Yep, it's linked on the project page, but the URL also is a project pages. Drupal code. Org slash API client. But the project page? Probably this way. Yes. Um.

>>:
About the Drupal npm namespace. Uh, is there any like, who owns it? Is there any governance like. Or is this just kind of like a squishy thing that, you know? Yes, the question was about the Drupal npm namespace. Who owns it? Um. Yeah, it's pretty squishy. And I think that, um, you know, proposing this will force us to talk through some of those things that are squishy. So even if the end result is no, this isn't under the Drupal namespace, I think that will still be good for the community. Uh, but the core Drupal JavaScript maintainers are the people who I consider to control that. Um, there are four packages that are published under it right now. Two are actually used in core, and the other two were in support of the Decoupled Menus initiative, uh, which I was involved in. And I went through the process of publishing those, and I did work with the the JavaScript maintainers on that. But it is, uh, the process is not clearly defined. And I think it would be really great for Drupal if it was like, is is there a world maybe where things that are successful in the community could be promoted to that namespace?

Does there need to be a separate like Drupal contrib npm namespace? Not sure, but yeah, I do think it, uh, those are all questions that should be solved. Yes. Does any of. Drupal? Maybe. The profiles use this model or this library. But yeah, do do does anything use this library? Right now I'm not aware of any direct dependencies yet, but I'm hoping that that changes. And one thing that I personally am hoping to do with it, um, which we'll use it and also maybe provide some more examples for the community, is I'm hoping to build an Astro starter kit that uses it to. I like Astro. It's fun. Cool. Any other questions?

>>:
Yes. Sorry. Just at. The very beginning, you had. A view underscore something you used to make your presentation, I. Think. Uh. Oh, yeah. So, yeah, the presentation itself, um, this actually uses like a, a theme that I created. Um, I can actually just jump over. So I have considered maybe trying to open source this, but the the view transitions module that I think that's the thing that you're thinking of uh, the view transitions module itself, I'll actually just go to it. The short story with this is It. So the view transitions API is what does those kind of smooth transitions between pages. Um, and it's a module that when you enable it, it allows those transitions on a Drupal site, there's two modes. One is as a single page application. So that actually will convert your Drupal site into a single page application. So maybe that is what you want. Maybe that is not. But that's one way to do these transitions. And there also is a multi page version of these transitions. But it's currently only supported in Chrome.

That's actually what I was using in those examples. My hope is that that will be adopted by more browsers. And that will just be the thing that this module can use. And we can throw away the single page app version, even though that was kind of fun to figure out how to do in a contrib module. Um, yeah. And the actual slides itself is a custom theme that that I built. Cool. Other questions? Yes. I love all these questions. Thank you. Yeah. So, uh. For my understanding, I'm not, uh, for, uh, JavaScript as a whole. jQuery. So is it correct to say that. I can install the library and can be used with react and JS oh, sorry. And JS yes. Yeah. And yeah, that's definitely something that we really focused on with this. It uh, it doesn't care about the framework that you use. So you can, you could actually use it in a Drupal site as well. Yes. Hi. So I know chapter three has put a lot of time into like, uh, Drupal Next JS integration. Yes. I'm going to use all of my five days of experience to answer this question.

Yes. Well, I was just curious whether, like, they're planning on using this, uh, you know, this project in their next Drupal. You know, ecosystem. Yeah. So I mean, obviously, part of what I'm excited about with this role is kind of the potential kind of overlap and synergy there. And the next four Drupal project is, is used a lot within the decoupled Drupal community. So I'm excited to be involved in that. This client definitely could be used in next for Drupal, but their client also works today, so I'm definitely not going to, uh, you know, try to force it to be ripped out if it doesn't need to be. But I would love to, uh, be in a world down the line where it makes more sense for a project like next for Drupal to use this client, because it's kind of the Drupal thing, the thing that is being maintained and built in general for the community. And it would actually be more work for next for Drupal to use their own client so it could happen. I'd love to see it happen, but I'm not going to on my sixth day, force it.

Any other questions. And you guys are are getting an A on questions today. So. Yes. Uh, kind of a throwaway question. Do you have any plans, uh, for transitioning off of Open Collective to a different provider? Uh, the question was, if I have plans to transition off of Open Collective to a different provider, I do not. I would love to talk about that more if you have experience with that. And, um, yeah, in general, uh, yeah. If there was another provider that addressed some of the issues that I experienced with Open Collective, I consider it I wonder if it is just the challenge and weirdness of dealing with money in an open source project. That is the real thing that I'm feeling. But. Cool. Any other questions? I don't want to keep people away from their calf material lunch. So. Awesome. Thanks everybody. Really appreciate it. Are you here for me?