GraphQL at Gatsby feat. Jason Lengstorf

GraphQL Patterns

00:12 Hello and welcome to GraphQL patterns. I'm your host Nader Dabit. Today on our panel we have Jimmy Jia.
00:18 Hey, I'm Jimmy [inaudible]. I'm a principal scientist at butterfly network working on democratizing medical imaging and GraphQL is actually pretty useful to stress stressor that
00:29 and our special guest today is Jason Lengstorf. Uh, welcome to the show, Jason.
00:34 Hey, thanks for having me.
00:35 I've been seeing quite a lot of you lately. Have an asked.
00:39 Uh, I have been noisy.
00:40 Yes. Yeah. You, you, uh, you had guts fear. Oh, definitely. All over the place. You all are doing a fantastic job, but for people like us that don't know you are, can you give us an intro?
00:52 Sure. Um, I am the head of developer relations at Gatsby. Gatsby is a framework for rapidly building out websites and apps with react and GraphQL. Um, we use GraphQL and I'm kind of an interesting way where we use it during the build time to access, um, file servers and stuff, which allows us to do some really interesting things with data, which I imagine we can talk about a little bit later.
01:17 Hmm. Cool.
01:19 Very cool. Yeah. So, um, for people that like haven't used Gatsby even, can you kind of give us like an elevator pitch for Gatsby and then I would like to get into like why Gatsby uses GraphQL, like a little bit deeper conversation there.
01:34 Yeah. So the elevator pitch is that um, building websites has a whole bunch of different things that are challenging to do and if you want to build a great front end with a lot of frameworks, you not only have to build a great front end, but you have to get really good at Dev ops. You have to get really good at performance management, you have to get really good at all these other like basically things that are complicated enough to be their own careers. Um, what Gatsby is trying to do is take all of that boiler plate and a yak shaving out of the way so that you end up with all of the right settings for high performance, easy to deploy apps. Um, you get to build just the front end and build the front end that you want using data from any data source. So we can, both from the file system, from Api Apis, from, uh, any headless CMS that you've got and that all gets pulled together in a normalized GraphQL layer. And then once you build, we compile down to static assets that can be deployed to any CDN so that you don't have to deal with standing up a bunch of, you know, horizontally scaled node servers or sharding databases or any of the things that get really challenging and scale with, uh, with big websites.
02:41 Yeah. So, um, when I started looking at Gatsby and using Gadsby, I never really understood the, you know, the need for all of this. I was like, why can't we just query data dynamically like we've been doing, but, but, you know, I don't know. But, uh, I haven't really been, um, you know, working with these types of applications and scaling myself. I'm usually on a team and we have back end people and people that deal with all this stuff. But after I started playing with it, I started understanding, you know, that um, the main difference I guess like trying to put it even more simply than you put it as, um, typically when you have data coming from a database, the data loads when the page loads or when you, when you actually ask for it. But with Gatsby you can actually set up these static, um, we'll GraphQL queries are static, a http requests. So when the, when you build the application, all of that data gets pulled from the database and it's available to you right there. And only the only, the only way to actually retrieve that data again is to rebuild the application, right. To rebuild the site
03:40 for anything. That's anything that we pull in at build time. Yeah.
03:44 So in this lends itself well to certain types of applications, right? Like what, what are the types of applications people are building with this?
03:51 Um, I mean the things that we see most often because I think they're the most common type of website anyways. Our blogs and portfolios. Um, we've started seeing a lot of people building ecommerce sites because Gatsby lends itself well to kind of a hybrid approach where you pull things like your products, uh, statically at build time. And then you pull things like inventory dynamically at load time because it got to be site. Once it hits the Browser is going to rehydrate into a react APP, which means that you don't lose the ability to do that asynchronous requests. You can kind of do whatever you want. Um, but uh, yeah, so we've seen it, go ahead. We actually do exactly. We actually do exactly that. Like our current ecommerce site are you commerce is built on Kathy for the front end. It's pretty awesome. That's very cool.
04:35 Yeah. Um, we, we use this pattern for our swag store too and I am really fond of it because it just makes things so much easier than having to, like, I don't, I, when I used to work at IBM, um, I, I was part of the push to bring GraphQL two IBM. And before this we had all of these like, oh, we need to do a simple thing. Well, let's proxy like 15 microservices in the back of our little node micro service so that we can stand up like this static front end and just the level of complexity to do simple things. When it was all API based, took it from something where like a front end developer would be able to just build like a front end. All of a sudden they're so deep in the stack that they're like writing proxy servers.
05:17 And I was like, okay, this is not like, this isn't a good way to work as a developer. You shouldn't have to go that deep in the stack to solve a simple problem. And um, one of the reasons that I ended up over a Gatsby is because they feel like they've solved that problem in a really elegant way. And that's, um, that's kind of, I like the fact that you can build really ambitious apps and just be a front end developer. You don't have to learn how like the deeper parts of the node API is work. Right?
05:43 The sweet spot is that that hybrid approach, because when you're, when you're, uh, when you're an ecommerce site, like you mentioned for example, you want people to have a very good user experience. When they land there, everything needs to be snappy, feel really good and can do that really easily with, with, you know, with this fetching of data at Bill Tom. And then like you said, like when you actually land on a page where you're, you know, getting some information about inventory, you can still load all of that stuff. Then you only have like bits and pieces that you end up dynamically getting. Right.
06:14 [inaudible]
06:16 so do you have like a diff, like when someone sets up something like that, except for instance you have inventory, would you set like some default stuff there are or would you like load the page and have like a spinner? Like how would that work? Just out of curiosity.
06:28 Okay.
06:28 You can do it however you'd like. I would say if it's something like inventory, you wouldn't want to show default information, you would want to show like the skeleton pattern, um, or a loader or something. Um, because if you showed that there was one available and then it like snapped to zero, that can be kind of a bummer. Um, but for other things, you know, you go ahead, you serve,
06:48 but like both Gatsby query in GraphQL on the build time, and then maybe you be saying like a polo or something to actually deal with graphical at run time. Right. Sort of cool. Exactly.
07:00 Um, yeah.
07:02 Yeah. I mean that's basically, we basically, we basically need to do just that actually. Do you know Jason Cleanse? Yeah. He's one of your contributors. Yeah, he's actually, he actually works in the, I was trying to get them to like draw me, draw me for this call, but you build everything out for us. It's like, Hey, look, it's got to be, it's great. It's easy. It looks fantastic.
07:17 Yeah. It's, uh, Jason's great. Um, I think we would've worked a whole lot harder to, to poach him if he hadn't had the same name as me because I put the Kibosh right on that, like, that can help me.
07:27 Oh No, that's [inaudible] I don't want to talk about that. I was very attached. I was like, ah, oh Jason. Anyway, um, hello. So maybe let's put, how did, so what's actually the story behind like, um, what's the story behind gets me making use of GraphQL. Cause I remember I recalled that like, I guess cow was pretty active in GraphQL circles. Like really like back when you first started. Um, how did, how did this whole like, gasp, you put scrap gold thing get started.
08:13 So I don't have, um, I, I don't have the deep story. You'd have to talk to Kyle to get exactly that. But from, from the way that I've heard this story told, um, Kyle was looking for ways to kind of make it easier to solve data problems like data management problems. And so when he wanted to build a, like a static site using the file system, accessing the file systems, kind of a pain, and then your file system needed to do, like if you're using markdown and you've got front matter and you want to pull out these different variables, um, finding ways to access that easily. It was kind of a pain. And then when you expand that further and you want to start pulling in data from Yammel Jason or go further and get something from arrest Api or, or something like that, you start to see that the data really quickly gets out of control.
09:09 And so I think Kyle saw that GraphQL could act as basically like a middle tier, like a normalization layer for data. And that would make it so that if you're building a site you get to use react and then the data layer is always consistent. Whether your cup pulling from, you know, a database like well, you know, you've got to a source and Gatsby for postgres. Um, we've got, whether you're pulling from your Api, um, you know, we've got like 850 something plugins at this point. And so you, you're able to pull data from all these different places and when you actually interact with that data, you don't have to think about sending off the, the request dealing with Heteros, things like that. You just get to say, I need like this data from Shopify in this data from the file system in this data from wordpress.
09:54 And then all of those things come back in a normalized query. And so I think that that, um, that idea that you could make your data more approachable for front end developers cause that's the promise of GraphQL, right? Like GraphQL and ratings data approachable to front end engineers. Um, and I think that Kyle saw that very early, I mean, great Gatsby has been around. Um, he was basically like an early adopter of both react and relay. Um, and he, you know, kind of experimented with that. So I think he was very fortunate that like Gatsby was right place right time. Um, it started earlier than people were ready for it and matured right at the point where people were ready for it, which is why I think we're seeing the, the popularity of Gatsby now. Um, but yeah, it's a, it, it, as far as I can tell it was because we wanted, we wanted a really like consistent way of interacting with data regardless of where it came from. That makes sense. Yeah. I mean it's, it's a really cool application. It's one of the things where it's like Sarah coming to the outside, you don't necessarily like, it's not something you necessarily expect, but like it makes it a big obviously makes ton of sense. Super useful.
11:02 Yeah. And it didn't make any sense to me when I first heard about it until actually use it. And then after using it, it just made so much sense. It was just, you know, like a light bulb moment for me and it just felt right. And it's kind of one of those, I think that's one of the reasons that, uh, the Gatsby success really, I mean there's other things I do similar, you know, things like Mex js with the static, um, the rendering and things like that. But, um, you know, having the first class graph, QL support in the smart way that it was implemented, definitely set it apart. And it was a very innovative thing. And I'm assuming you'll see like other people adopting this stuff, it's kind of like the trailblazer blazer type of a deal. So what kind of companies are using Gatsby right now? Just out of curiosity? Uh, like I know we talked about the type of companies, but are there any like companies that people have heard of?
11:52 Yeah, definitely. Um,
11:54 Ideo, the, that big design agency, they, uh, just launched a Gatsby site. Um, AWS it sounds like we're using it. Yeah. Ada, AWS. Uh, I know IBM is using it for the carbon design a system and they're also, the last I talked to them, they were trying to like make that into a pattern that all teams could use. Um, paypal is doing experiments with, with Gaspe. Right now they're, uh, they're split testing. paypal.me with a [inaudible]. Um, we've seen, uh, websites for Nike, like the Colin Kaepernick just do it. A campaign was a Gatsby website. Um, shop Flamingo, which is the Harry's Shave Club, a women's line of razors, that's a Gatsby ecommerce site, um, in a couple of like more ambitious things like hopper, which is, uh, a booking site is also a Gatsby APP, which is, which is pretty fun. Um, but yeah, I think there, I mean it's, it's been really interesting because we're seeing a lot of people using it.
12:52 Um, and especially a lot of people like the react js docs are a Gatsby site. Um, so it's, it's very cool to see that. Like we're getting adoption in the commercial and the like the techie sphere. Um, yeah. And just, it's, it's kind of like nerd street cried, you know, we've got like Kenzie Dodds and Danny Habermas and you like, they're all using Gatsby now for their personal blogs, which makes me like infinitely happy and nervous because every time they have a problem, they're like, here's what went wrong with Gatsby on Twitter. And we're like, oh shit, everybody has to like panic and go, go. Like figuring out how to solve those problems before they spiral out of control. But the gift and the curse of being extremely popular. Yeah, exactly.
13:35 So when people, when things go ride, people tweet about it but also things go wrong.
13:41 Yeah, we've been very, we've been very fortunate that like, you know, I always joke that be in Dev Rela Gatsby is the easiest job in the world cause I just get to retweet all the nice things people say about us. Um,
13:53 developers love Gatsby. It's great. Um,
13:57 yeah,
13:57 so I guess for these, for, for Lisa to use cases I didn't like,
14:05 it seems like there's a split between like the more classic static page like doing like a blog or something where we're, it's like essentially it's purely a static site generator versus the set of pages like ecommerce applications where they're really, at this point you're, you're using Gatsy almost in some ways. Like a, you know, a more customizable now or something where this is a framework for delivering a page that gets you a lot of really nice separate server side rendering around beans. Like, you know, managing, writing those scenes out of the box and it's just like not setting up a bunch of junk that you would need to for, for a full fledged, um, for a normal web app. Um, is there like any sort of tension between supporting those two use cases well or is it just sort of fall out naturally?
14:47 Yeah,
14:47 the, the nice thing about trying to just leverage react as the application layer means that dynamic apps just go straight into react line. So if, if somebody exceeds one of the common use cases of like Gatsby for a statically rendered page, then they fall directly into the react docs and the react ecosystem for whatever they wanted to do. And so there's, there are very few things that caused like real issues. And the, the main issue is like if you've got a, a Gatsby site that are a react library that you want to use and I guess be site and it depends heavily on the window. You got to do some, some special stuff to make sure that that doesn't, you know, you have to make sure that code doesn't execute during the build phase. But that's all pretty easy. You sticking to any use of any user factor component did mount or you can stub it out in, um, we have a, uh, a way to set up a no loader so that during the server side rendering phase, it doesn't try to load that library at all. There are lots of ways to solve that problem. Um, but that's like the only real Gotcha is getting your head around. Okay. I can't use the window except in like life cycle methods because they won't be available during server side rendering. It makes sense.
16:02 All right. So it's like, it's almost like any sort of like, it's almost like any sort of, um, like server basically any sort of surrender, anything. So just don't use lifecycle approach it, you don't don't like access the dom except in whatever like yeah. In place a great example. It's done no different than doing anything else. SSR.
16:20 Okay. Yeah, exactly. It's the same, the same SSR Gotchas that you would see pretty much everywhere. I, I'm not sure if anybody else has a more elegant work around that like catches it for you. But in, in our case, we just document how to work around it.
16:33 And so I know Gatsy works in a mode where you generate a bunch of lights, static html and that's your page I guess. Is there also the note for dynamic rendering? Like you've got service, I'd rang me with node processes that then do stuff like it's something like be conversation data fetching where that data gets fed on the service side.
16:49 Well we, so we don't support that. Like Gatsby doesn't ruin any, there is no long running process with Gatsby. So when you deploy a Gatsby site, you're deploying static assets to like an s three bucket. However, if you do deploy another server, um, for example, the, um, the Gatsby swag store, we have another APP running behind it. That's uh, it's our API and that is a serverless app using, it's like a GraphQL API that we deployed to AWS lambda. And so that allows us to kind of just like fire off any, any server side needs to these lambda functions that kind of act as a long running server for us. Um, but that introduces problems, right? Because now we have to have, like, we have to introduce jobs, we have to introduce all the security stuff. The nice thing about using build time assets is that like once you built it, there is no more access to the server or the database.
17:44 Like they're, they're not part of the compiled static assets that Gatsby puts out, which is good for security because there's nothing to hack. Like you can deface the static assets, but you can't get to the server, the database because there's no limit, there's no link there. Um, with a, a long running service, like obviously an ecommerce site needs a long running service, but it limits that surface area with limits the number of things that you can actually get to. Right. But I guess with it also means that, for example, like in the image free pitching approach, the Introit vetch then needs to be done on the client side. So you're gonna you cancer say that API call, but at least you get all of the like main page like layout rendered statically. Exactly. Yeah. And that we are working on, um, we have a solution that we're calling incremental builds that's going to allow for really, really fast rebuilds.
18:34 Like we're, we're aiming like our pie in the sky goal here is like sub second because we're doing something similar to the the reac virtual dom where we can, we can determine what in the tree actually changed, right? And that way when we get new data, cause you know, the nice thing about Gatsby because we control the whole experience from the initial bootstrap all the way through to deployment, um, we're able to really, we can treat websites as a pure function of the code and the data that goes into them. And because of that we can then very easily diff like, hey, this is the only page that changed when this inventory item changed. And so then we can go through and rebuild that very quickly. Um, that's a, a service that we're going to be offering here hopefully soon ish that um, will allow for like something like an ecommerce site to say, yeah, do incremental build.
19:23 So when the inventory changes rebuild just the page that needs to change, which means that your inventory is only ever, you know, two, three seconds out of, out of date with whatever your actual backing databases, but you're still only serving static assets. So that's the, our solution to this isn't to find a way to have a long running service. It's to find a way to build those static assets faster so that you get the experience of using a long running server but never actually have to have it. That's interesting. How does that work if you're just, you're interest just like a CD endo, like doesn't it take a while for the changes? Like you might be able to rebuild it in a few seconds, but we didn't take longer for things to actually make it to the user. Well, the thing that's really interesting about this is like CDNs have figured out ways to do extremely fast and validations like the, it seems like the La, the last few times that I've used s three invalidates within like 10 seconds.
20:15 Um, [inaudible] is also really good at this, their CDN and validates like near instantly and so, um, it's really like maybe it goes from two, three seconds to five, 10 seconds, but it's still going to be in almost all cases fast enough. And in cases where it's not fast enough, you can still do that asynchronous like show a loading component until you get the freshest data. Yeah. I guess my answer is more like most recently I tried to do this again, validation on cloudfront is took like that was like I hit an audience sitting there waiting for the spinner for like 10 minutes. Like, Huh, yeah. That might just be proud for him being weird. Yeah. I, you know, I remember it felt like for a long time that whenever I would invalidate something on cloud front or another CDN, that it was like 15, 20 minutes for it to hit the edge. Um, but that, that time has steadily been going down and I'm not, or you might be able to speak to this, but like the, the cloud front and validation times, they seem like they've gone significantly down from, from where they were like a year ago.
21:16 Yeah. I mean, are you talking about the defaults? Are you talking about kind of what you're manually setting?
21:22 Like if I send a manual and validation, it's like, Hey, I want you to like dump the dump the CDN and pull a fresh copy.
21:28 Yeah. Yeah. The, the, I mean that stuff has always been improved. Um, they're working on a lot of stuff around that. I know that's a big topic is, uh, as well as the cold start tops for lambda functions. I know that's kind of like a different discussion altogether, but, um, it's one of the things that people are always, I'm requesting, you know, improvements on. So,
21:50 yeah.
21:51 So this isn't going to be a around GraphQL in particular, but I think it's pretty interesting that, uh, you're working as the head of developer relations that Gatsby and you all have done such a phenomenal job I think in that space of Dev rel and I'm indev rel is as well. And so I'm kind of curious, you know, how you got into that with Gatsby. Is that something you were doing before Gatsby and uh, what's your approach been a so people can kind of learn from your success I guess?
22:20 Um, I, I don't know if I can, I feel like my, my path into Devereaux was so weird that it's hard to duplicate because the way that I got into Dev rel in general is actually through music. When I was younger I thought I was going to be a rock star. And so I was in this band, we toured heavily, we played, we were on the road like 200 days a year playing tons and tons of shows. And while we were doing that, we had to find ways to get teenagers to hang up posters and tell their friends to come to our show. And that is a really, really difficult group to reach because if they smell sellout, if they smell corporate, they're like instantly out on any of it. So you have to find a way to like create these high quality connections with somebody that you do not know through like my space or something along those lines.
23:12 And so we, you know, that was kind of where I cut my teeth on on community building, was trying to find ways to get a teenager to let me ship them an envelope full of posters so they'd go hang them up around town. Um, once I got through that, you know, I, I got into web development because my band was terrible, but I was building all of the websites. I turns out that I was way better at building websites for bands and I wasn't being in a band. Um, so then I got into web development as a, as a career. But I've always held on to that idea of like, well, no, you should write, you should get involved in the, so I started going to local meetups and speaking from there and uh, it writing articles for different like community publications and along those lines.
23:54 So I was never like officially a Devereaux, but it was always something that I enjoyed doing. Yeah. And when I went to IBM, um, IBM W I wasn't a Dev role at IBM, I was actually a front end architect, but like the um, the work that I was doing was like, do something good and then use that thing that we built to kind of go out and talk about it as both a like image rehab. Like, you know, IBM is big blue, it's slow and it's out of date. So we wanted to change that, that perception because we were also trying to recruit, we wanted people to get excited about working at IBM. And so I was sort of doing Dev rel. And then when the Gatsby opportunity came along, it was kind of a natural progression for me to go fully into the community building part.
24:39 Yeah. And I'm, I'm sure moving from, you know, you working independently, you know, in that, in that sense at first and then doing the, um, them doing the corporate thing and now you're working at kind of like a startup you've had experience in all these different areas. And I'm assuming that it's just a different approach for each, each place, right? Like, I'm, I'm assuming that you're working with different challenges at IBM versus at Gatsby versus your previous, um, you know, place.
25:06 Yeah, it's, it's different and it's exactly the same. Like the thing that's really interesting about it is that you have problems at IBM. Like IBM has image issues, people have a perception of what IBM is, and it's usually not positive because if you've worked at a big company that's been able to hire IBM for consulting or whatever, it's like people don't have a lot of Nice things to say about that. It's the same as, you know, if you've worked with Accenture, any of these big consulting agencies. Um, so we're trying to overcome that perception. We're trying to overcome the perception that IBM has legacy. Um, we're trying to overcome the presumption of, you know, all these other things that they kind of get attached to the name when you're working for an agency. Like I owned my own agency, which is where I was doing before IBM and I, at that point, I'm trying to overcome the thing that nobody knows who you are.
25:52 Um, and then when you get to Gatsby, you're trying to overcome the problem that like people have a very specific idea of what gets we can do. And so you're trying to, without throwing away all of the value that is attached to Gatsby shaped the perception to drive it towards something new. Like this idea that Gatsby can build dynamic apps. That's something that we, we really want people to know, but we don't want to get away from this idea that you're building like super high performance static apps. Um, but those three differences are kind of small compared to the fact that ultimately what you're doing in Devereaux is you're trying to be like a genuinely welcoming person. You want people to feel like they have a, they have a chance to belong in a community of people who are interested in the things that are interested in.
26:37 So that I think really that's the part that's made the biggest difference for me is recognizing that like, I don't care about Gatsby as uh, like my, my personal self worth is not staked on Gatsby success as a company. My, my personal sense of self worth is staked on while I have the opportunity that I have against B, can I be a like voice that moves the industry forward a little bit and makes it a little more welcoming that acts as a springboard for other people's careers as opposed to being a, a gatekeeper or an elitist or something that that holds people back. Um, you know, I feel like the measure of my success isn't that Gatsby goes public. Obviously that would be nice and it's something that I'm going to like work for her. But like my primary objective here is to make sure that I leave the industry feeling like I'd made it better than it was when I showed up in it.
27:33 Yeah, yeah. Yeah. Totally. And I guess that's very apparent when, when you kind of see the work that you're doing, it's, it's definitely, you know, it shows that that's your approach. I mean that's just who you are I would say versus like an approach.
27:46 Yeah. And that's what they were in a Dev rel role. You have a lot more levers than you would in many other places in the industry too because you're so like, you know, you're so community facing you, you are exactly part of that. Um, maybe going back into a GraphQL tech, so obviously you all invest heavily in the [inaudible] ecosystem, like with Mikhail, with the others. Um, do you want to speak to like what are the, some of the things like Gatsby's done with crack, y'all like what, like why has got to be like, what did, like what are the things that you needed to invest in? One of the things you've benefited or from like how are the ways that you sort of, I think needed, needed to shape GraphQL to make your work better for you?
28:27 Um, so a lot of the things that we've been doing, like we brought in the Kyle because we needed help with, like we, we wanted to ship scheme of customization. And so one of the things that that Gatsby's done is by default we infer the Schema from the data that comes in. So we take an object and we just kind of look at the object that comes in and automatically define a Schema for it, which is great for convenience, but it's a huge pain when you have, let's say like you have a blog post and some of those blog posts are going to have like an author field and some of them won't or, or whatever. Um, if the first one that we look at doesn't have an author field, we don't infer that field and it might break in your, your app in like weird and confusing ways.
29:14 Um, so we needed, we needed a way to come in and allow you to both infer the Schema and also customize it. So has been doing a lot of work on that where you can selectively define things that are important to be done in a certain way. Um, but you can also leave them alone. And we needed a way to extend like override resolvers create customers resolvers. Um, that's really important for some of the work that we want to do. Like the way that we're normalizing data now we want to take that even a step further and allow you to do like data abstractions. One of the big dreams that I have is that you'll be able to write a theme for, for Gatsby, like Gaspe themes are something that we're, we're working on that kind of let you bundle up a lot of functionality.
29:59 And we want a theme for let's say a blog where that blog uses a generic post type and that post type can source data from one or more backends seamlessly because we'll just have the adapters that, you know, customize the Schema to pull in like wordpress data. And make it a generic post type. So you could have some mark down from maybe the developers who are writing for the blog, wordpress posts from the marketers who are writing from the blog, something from salesforce. If you're your sales team wanted to get in on it. Um, and all of those go into a generic type that would then be used by the components in the site. So now you're going even further where you're not writing the front end developers or literally just expecting, I know I will get posts, I don't care where those posts came from.
30:41 It doesn't matter where those posts came from. I just know that I need to display them in a, in a way that looks great. Um, and so having Mikayla's work on that as has been really, really fascinating. He's working with someone from the community, a guy named Stefan [inaudible], who's done just absolutely outstanding work on, on making this happen. And then presumably you can, you can also share like abstract post types across different websites too. Yeah. Yeah. I mean, the ultimate goal is like if we, if we get this done right, uh, if we get the abstractions done properly, the promise that this holds is that if you, like let's say that you start with a wordpress blog and you, you start with a theme that's like a, a magazine theme. Um, because the data types are generic. As you grow, let's say you switch out from, from wordpress to some custom CMS Contentful, you need something more, more high powered.
31:39 Um, you drop Contentful in and nobody notices because the, the front end doesn't need to change. It just, it just swap out your adapter from the wordpress adapter, that Contentful adapter. But then later you want to switch to a more high powered theme. We swap out your theme and the theme doesn't need to be changed because it also expects a generic type. And so you can, you'll, we want to get to the point where the, the themes and the data are kind of loosely coupled by these data contracts. They, you know, the generic types become the contract and then it doesn't matter where they're coming from. You can mix and match them. So as a, as a user you can swap between themes. So like somebody who comes from wordpress can use themes that were maybe designed for sanity.io or, or some other headless CMS because they're all sharing the same generic data types, which means, you know, from a headless CMS creator's standpoint, we want to create the opportunity for you to build a new headless CMS from scratch. And as long as you work with these generic types, you can opt into a network of hopefully thousands of themes that we'll be ready to roll with your, your a given solution.
32:45 Nice.
32:47 Okay. So it's okay. So right, so essentially largely if I started like, you know, draw a big circle around like around declines, like taking manage of improving GraphQL tooling such that you can better take advantage of polymorphisms, encapsulation within the GraphQL type system. I imagine. So suddenly I'm like where you have some sort of like a post interface but then you have different than types for like CMS po like blog posts versus for like salesforce post versus for whatever.
33:20 Yeah. And so some of the stuff that they're working on that's been really challenging is, uh, like we need to come up with a way to either add like decorators or directives or something that will say, if, you know, if I've got a post image type, I need to be able to like run Gatsby's image optimization against that image regardless of the back end that it came from. So how do we say like, all right, so this field is mapped to this field and also we need to run this like backend image optimization. If that image optimizer plugin is installed. And like, do we do that through like the way that we define the Schema or are we saying like, you know, is it a, is it a field directive? Um, we don't know yet. That's the, that's the kind of work that, uh, that Mikhail and Stefan or are working on is how do we allow for this?
34:08 Like, not like in line is, but like definition based data manipulation and file manipulation. That's, that's kind of driven by what you need and not necessarily, you know, we want it to be really declared that we want. We want you to just say, I would like my data and I want it to be the way that I wanted and I don't have to care where it comes from. So how do we create those right. And middleware tools that can be the interface that does all of that work without adding a ton of, you know, Brittleness or, or fragility, um, to the, the abstracting abstractions that we're putting in place. So yeah,
34:43 it's still like difficult for you to get, I guess maybe not at this point, but was it ever for you at some point to like get plugin authors on board? Cause one thing we noticed with, to me that's just like, oh my gosh, there's such a great plugin ecosystem. [inaudible] got speed.
34:57 Um, I don't, I mean I feel like maybe at first I think that part of the problem too is that we haven't done a great job of documenting the plugin lifecycle. I'm sorry, the eyes, I mean it's like, it's hard for us because Gatsby has put so much effort into its documentation. And so to, to have like such a big blind spot is a little, it's, it's hard for us. Um, it's something that's, we're going to correct it within the quarter. Like it's, it's very high priority for us to make this better. But our plugin, um, our plugin life cycles are documented in a very utilitarian way. Like is the method, and this is the argument, but there's not like a y we don't explain why you would use it. And so that can make it a little tricky and you end up having to like write plugins by looking at the source code of other plugins.
35:49 Um, we've got a really, really engaged developer community who doesn't mind doing that, which is great because it means that they're all sharing ideas and, and um, you kind of see the, the best practices evolve as a community effort. Um, but I do think that it puts a, a fairly high bar out there for somebody who wants to try. Um, so for, you know, from generally people just get really excited because they want to use Gatsby. They see that we don't have a plugin for whatever source they want to use. And so they go out and they find a way to do that, uh, because they needed for their job and they'd rather not have to write all the other things that to be does, you know, it's faster for them to be right, a source plugin than it is to rebuild all the proof tuning and stuff.
36:29 When you say that source plugin, are you talking about a way to pull in data like a bill, Tom?
36:34 Yeah. So we, we have like a few general buckets of, of plugins. A source plugins are ones that will pull in data. We have transformers that'll like convert data from one to one format to another. And then there's like kind of a, a generic plugin which can do anything. Like, you know, we have some that add the Twitter bed script to the head or um, that, you know, whatever. Like there's so many miscellaneous things you can do to manipulate the dom and all that stuff.
37:01 So there's got to be sourced GraphQL not work for pretty much most of use cases though for GraphQL or are there more than one GraphQL source plugin?
37:08 It depends on what your needs are. So like if you have data that's already set up in a GraphQL Api, 100% got to be sourced. GraphQL is, is perfect for that. If you want to do things like pull down files from a remote API and then um, like optimize them. Uh, that's the, the use case I was just talking about. Um, with the scheme of customization Gaspe sorts GraphQL doesn't currently have a way to do that. So what you have to do instead is like set up your own source plugin to make that query and then find anything that looks like a file path downloaded, run the optimization and then stick it back into the Schema, which it's not hard. We've got the patterns for it, but it's cumbersome and we want to take all of that extra work out of the way so that it can become something that's just like, oh, this is the field that needs to be an image. Like add this, this directive there and it will be done for you. Um, at the, at which point we'll be able to just use Gaspe source GraphQL for, for pretty much everything. But you know, like I said, that's a, it's a hard problem to solve without introducing a whole host of other problems.
38:09 So, uh, we're getting cotton clothes on. Tom and I have one more question that's around this and then we'll probably get to our pigs. Um, but is there a way to pull in data from like a lambda function or a serverless function that's not using GraphQL and then like transplanting or in some way or something?
38:24 Yeah, pretty much. Anything that you can, anything you could think to do in a UN, like a client side App, you can do at run time. So effectively you would just be making a request, like you can, you know, you can use axios or fetch or whatever, send it off to your lambda and then the response that comes back you can put into a node. Okay.
38:43 Um, and then more like a dynamic approach versus a bill time approach.
38:47 Well, it would still be done at build time. Um, so yeah, so our, our build time is basically just a script that runs. And so when you, when you run it where like, Hey, make a request to this API and pull down data and then put that data into our GraphQL layer and then, hey, make a request to this lambda and then put that Rick, that data into the, the GraphQL later.
39:03 So the data will be available as a GraphQL query at that point, even if it works. Oh, sweet. Okay.
39:09 Yes, you would, uh, you would look at the source nodes Api, uh, on the, the Gatsby docs. Um, so yeah, source nodes basically any, like, you can start by just running a create node call in source nodes and put in a generic object. And it'll create a new type for you. And we infer all the, like the select many or select one kind of types and filtering and all that stuff. Um, then you're able to add whatever data you want. There are a couple of required fields. We document those so you can see what they are. Um, but I out the other end of it. Yeah. Anything, anything that you want to put in there, as long as you can grab that data. So you'll have to add whatever API keys or, or authentication headers or whatever it is that you need to make that call at build time. Um, but once we have that data, you can put literally anything into a, into a node.
40:03 Okay. I know what I'm going to be playing around with a later today, so thank you for that. Before we get to our picks, is there anything that you, Jimmy, are you, Jason want to talk about, uh, in the next couple of minutes?
40:16 Um, I don't have anything in particular.
40:19 Okay. So let's get to the picks. Jimmy, do you have any picks today?
40:23 Um, I was at this amazing concert at Carnegie Hall last night. Uh, yes, in Davies countertenor and Thomas tempered [inaudible]. Oh my gosh. They were amazing. I'm like basically just bingeing on a dumper, lute music, lute music now. It is so good. Um, that's I think completely unrelated. Anything technical? Sorry. Nice. Not even a citation. Citations. What's the same?
40:47 So my kids are, one of them is BMX bike racing. My kids have been getting into this lately and I've been doing a lot of like research and checking out this whole like culture and they are like some really amazing BMX tracks these days. Like indoor, outdoor, all around the United States. People travel, they get into this stuff. My kid just got a new bike yesterday and they're getting like really awesome.
41:07 I saw the video of your kid riding BMX. It was awesome.
41:10 Yeah. That's like my four year old is in it now. And he just moved up from a stratta rider, which is the bikes with no pedals to actually a bike with fetals. And he's like, he's not even old enough yet to like race or nothing, but he's out there and he's killing it and it's so much fun. It's like, um, you're out there. It's beautiful outside, especially right now. And the kids are having a good time and they're, they're racing, but then they'll stop and go hang out. It's just a really fun thing to do if you're, if you're looking for a sport that's not like basketball or baseball or whatever, and you want to try something new, I look for BMX. Uh, it's, it's been amazing. Like we're, we're, we're, we're loving it and I'm going to start writing too. I got a bike too, so I'm looking forward to that. Um, so Jason, do you have any kids?
41:51 Uh, I'll, I'll keep with the musical picks. I've been, um, I've been in a deep NPR tiny desk whole lately and, uh, I'll shout out two of my favorite NPR tiny desk concerts. One is Lianne La Havas. Um, she has one of the best voices I've heard in music, you know, in a long time. And then a Anderson pock, his tiny desk concert. I think is one of the most, like I, I've, I've never seen just like bottled joy, uh, and watching that band, like watching him specifically play and how much fun he's having, but just the band in general and how the, the energy that they create in this tiny little space playing with like everything muffled is, it's really, really good. Um, so I would, I would highly recommend both of those tiny desk concerts.
42:35 Awesome. Well, thank you for coming on today. That's been a really nice show. Uh, learned a lot and appreciate your time.
42:43 Yeah, thanks so much for having me. This is a lot of fun.
42:45 All right. Thanks for listening. This wraps up this episode of Grab chromatids. See