[Weekend Drop] Abhi Aiyer & Ward Peeters: Gatsby 4 and the Jamstack Endgame

Abhi Aiyer and Ward Peeters are two lead engineers behind Gatsby Cloud and the recently announced Gatsby v4, which is at the forefront of what I think is the most significant change in the Jamstack landscape in the past 2 years.

The following is my conversation with Abhi Aiyer and Ward Peeters, two lead engineers behind Gatsby Cloud and the recently announced Gatsby v4, which is at the forefront of what I think is the most significant change in the Jamstack landscape in the past 2 years.

Watch the video version here.

Links:

Timestamps: 
  • [00:00:00] Cold Open 
  • [00:00:28] Swyx Intro 
  • [00:01:59] Call Start 
  • [00:03:07] Gatsby v4 
  • [00:06:23] Incremental Builds 
  • [00:07:16] Cache Invalidation 
  • [00:09:03] Gatsby DSG vs Netlify DPR 
  • [00:09:35] Abandoning Redux for LMDB 
  • [00:11:50] Parallel Queries (PQR) 
  • [00:13:32] Gatsby DSG 
  • [00:15:24] Netlify DPR vs Gatsby DSG 
  • [00:19:19] The End of Jamstack 
  • [00:22:12] Tradeoffs and Performance 
  • [00:24:34] Image Processing 
  • [00:27:25] Automatic DSG 
  • [00:29:33] Gatsby Cloud vs Netlify 
  • [00:33:34] Gatsby vs Next.js 
  • [00:35:41] Gatsby and the Content Mesh 
  • [00:37:19] React 18 and Gatsby 
  • [00:39:45] Custom rendering page fragments with React 18 
  • [00:42:10] Server Components in Limbo 
  • [00:43:33] Smart Servers vs Smart Clients 
  • [00:45:21] Apollo and Open Source Startup Strategy 
  • [00:47:06] TMA: Too Many Acronyms 
  • [00:49:16] Gatsby for Docs 

Transcript
 
[00:00:00] Cold Open 
 
[00:00:00] Abhi Aiyer: And so with LMDB in place, right? We have workers that can read and write to LMDB, which allows us to run parallel queries. So PQR was a huge advancement for us. I think we saw up to like 40% reduction in query running time. And build times went down. We had a goal, I think it was like, we'd try to look for at least 20% reduction in build times and I think we hit 26%, so all cool wins, you know? 

[00:00:28] Swyx Intro 
 
[00:00:28] swyx: The following is my conversation with Abhi Aiyer, and Ward Peeters, two lead engineers behind Gatsby Cloud, and the recently announced Gatsby V4, which is at the forefront of what I think is the most significant change in the JAMstack landscape in the past two years. We discussed how parallel query writing PQR and deferred static generation DSG are achieving 40% faster queries and 300% faster overall builds. 

[00:00:53] And they did a wonderful job handling the most impolite questions I could think of, including whether it Gatsby Cloud is a Netlify clone or the Gatsby should just be a data layer on top of Next.js and how they're dealing with TMA too many acronyms in web development. This conversation should be viewed together with my past discussions, with Sunil Pai and Misko Hevery in considering the cutting-edge of web development today. Online discussions often present a binary split in that your technical choices either have to optimize for developer experience or user experience. 

[00:01:25] But I find that it is builders like Abhi and Ward and Misko and Sunil who are constantly trying to improve the experience of developers in building great user experiences by default. I hope you enjoy these long form conversations I'm trying to produce with amazing developers. I still don't have a name for it. 

[00:01:41] And I still don't know what the plan is. I just know that I really enjoy it. And the feedback from you guys have been really great. So if you like this, share with a friend, if you have other requests for guests, tag them on social media, I basically like to make this a space where passionate builders and doers can talk about their craft and where things are going. 

[00:01:58] So here's the interview.  

[00:01:59] Call Start 
 
[00:01:59] Abhi Aiyer: I'm Abhi Aiyer. I'm a principal engineer at Gatsby. Thanks for having us.  

[00:02:05] Ward Peeters: My name is Ward Peeters. I'm a staff software engineer at Gatsby and I'm from Belgium. And I've been working mostly on the open source side.  

[00:02:15] Abhi Aiyer: I forgot to say where I'm from. I'm from Los Angeles, you know, Hollywood,  

[00:02:21] swyx: I'm actually heading down to LA,  

[00:02:22] Abhi Aiyer: in a couple of weeks, there's,  

[00:02:24] swyx: I'm going to Kubecon, which is like a very interesting thing for a front end engineer to end up at. But that's where my career has taken me.  

[00:02:34] So this conversation started because I had a chat with Sunil, on this podcast that I accidentally launched. I don't think we did Gatsby much, a good favor. 

[00:02:45] Like we both saw the new updates and I didn't get to say the nice things that I thought about Gatsby. I should also say that I used to have my blog on Gatsby and I no longer do. I used to work at Netlify and I no longer do. There's a lot of history here for me with Gatsby. It's been a while since I caught up, and I'm curious to see or get the latest. 

[00:03:07] Gatsby v4 
 
[00:03:07] swyx: Maybe we should start off with like a quick summary of what's new with Gatsby with Gatsby V4, right?  

[00:03:13] Abhi Aiyer: Is that a good place to start? Yeah, I think so. 

[00:03:17] swyx: So first of all, I think the marketing was really nice. Gatsby camp, it seems like a really big push and qualitatively very different from Gatsby 3. Tell me about what the behind the scenes was like. 

[00:03:30] Abhi Aiyer: Yeah, it was, we're getting better at the marketing side of what we're doing these days and Gatsby 4 was a big push. It really changed how we approach the framework as a whole.  

[00:03:43] For those who don't know, traditionally Gatsby was a static site generator, purely static. We hold ourselves high on our connections to a content management system. 

[00:03:55] And we provide a really good data layer there, that takes all those requests that you would normally make to a content manager system, turns them into a, like a store of data that you can then use and query from graph QL. And the big thing that we were hitting before gas before was. Company was growing. 

[00:04:17] And as more customers were using Gatsby cloud, we started realizing that we couldn't scale to really large sites and large sites is like a misnomer. Like you could be, you could be a 50,000 page site and be considered large given the data that you may have. But we're talking like hundreds of thousands of pages. 

[00:04:38] And the thing that we kind of realized is not all pages are created equal on your site. Especially the ones from like 20, 15, 20 14, where, you know, no one's looking at that people, those pieces of content, if you're a site with a huge archive of content yeah, you should probably go check Google analytics to see how, you know, how, how many people are actually viewing your pages. 

[00:05:02] And the way gets me. And we'll get into this a little bit later, but today Gatsby isn't as smart as it should be in what pages should be rebuilt. For example, we're looking at the gatsbyjs.com page right here, but there are other data dependencies. This pure content. Like if you look at the nav bar, there's a whole bunch of items there. 

[00:05:22] And we have this navbar bar on all of our pages, cause that's what a website has, but the problem with Gatsby today and will be changed in the future is. If I change anything about this nav bar, any page, that depends on the nav bar now has a dependency that needs to be invalidated. 

[00:05:39] And so now I have a hundred thousand pages with this navbar I have 200,000 pages of this nav bar and I spelled Gastby instead of Gatsby or something, the navbar I made a typo and now I'm paying for. A hundred thousand pages of reload to rebuild. And so we just saw that and that this happens a lot, right? 

[00:05:57] This is a very small example, but this happens a lot to our customers and building a hundred thousand pages is not necessarily easy thing to do. There's memory requirements that come in. There is, what kind of machine are you doing this thing on? And so we had to figure out a way to scale Gatsby and do things differently. 

[00:06:15] We were traditionally static and now we're trying to be somewhere in between, you can go dynamic or you could go static and it's up to you.  

[00:06:23] Incremental Builds 
 
[00:06:23] swyx: So the new rendering options are SSG, DSG and SSR. Is ISR gone?  

[00:06:32] Ward Peeters: Well, that's what Next.js has is doing. And I'm like, wait,  

[00:06:36] swyx: we never have guessed. 

[00:06:38] We had an incremental mode.  

[00:06:41] Abhi Aiyer: What do you  

[00:06:41] Ward Peeters: call it? Yes. And that's still all statically. So when we do it, we have it in open source where we in V3 we enabled it where we only build HTML what's necessary on cloud. We have a more pumped up version of it where When you get the data change, we only update that page more rapidly than in open source, but still when you change your navbar with what Abhi said, you still have to rebuild everything because all the pages get invalidated. 

[00:07:09] So incremental builds works for data updates, but not so much for code changes.  

[00:07:16] Cache Invalidation 
 
[00:07:16] swyx: Right. Okay. Well, I guess, how do you solve cache invalidation? 

[00:07:26] Ward Peeters: Well, the thing is that because Gatsby owns the data, like the heads of data layer and a source plugins like WordPress, when we source data and to give us a webhook or, we just go to Wordpress and say like, Hey, what has changed? 

[00:07:40] Data. I was like, okay, these nodes have changed. Or these pieces, like a poster page has been changed. It gets me knows which node is used where, like, for example, this post is used on this section page. It's used in this article and that's all happening already behind the scenes because graph QL shenanigans. 

[00:07:59] And that's how we can build incremental builds. So we know, okay. Only these spaces need to be built. And that's also where DSG comes in because as a user, you don't have to care about cache invalidation anymore. Cause it's using the same engine as you were used to with like incremental builds. 

[00:08:15] When you use SSG and I think that's a major benefit of it, where you as a user, don't really have to care about cache control, because it is difficult to manage on a large scale. Like a lot of corporations just say like every 10 minutes we'll remove the cache because it is difficult to get through when change. 

[00:08:37] Yeah.  
 
[00:08:39] swyx: That's pretty funny. At Netlify, one of the reasons that we constantly talk about for CDN level caching, like people say like, you know, why don't you just enable CDN level caching and then just have a regular server render. One of Matt Billman points that he always makes is that people always turn it off the moment there's a bug, it's like, oh, schedule, call, and turn it off. 

[00:09:02] And then don't turn it back on again. 

[00:09:03] Gatsby DSG vs Netlify DPR 
 
[00:09:03] swyx: Okay. So let's, let's talk about like, DSG. That's the fancy new one and DPR, right? So maybe we should, is there. Yeah, there's a graphic. Okay. All right. This is new. So first of all, like what was the inspiration? What's the backstory I'm always interested in how these things come about. 

[00:09:21] Abhi Aiyer: I think we were inspired by DPR a lot, you know? But where we saw the benefit of our approach is our data layer, you know, and it took those many steps even before getting to DSG.  

[00:09:35] Abandoning Redux for LMDB 
 
[00:09:35] Abhi Aiyer: So it started actually in like Gatsby 3.10. We had to redo Gatsby's node store. 

[00:09:42] So traditionally we were using Redux to persist all these the data that we get from content management systems. And we had a particular customer who could not even persist the cache, like a Gatsby cache between builds, because they had so much data that it would OOM when they try to persist the cache. Right. 

[00:10:03] So for them, they were running cold builds for every build. Even if you had like a warm cache or you had your pods, you know, we use Kubernetes. So like, if you have your pods up, you're doing like an hour and a half cold build for everything. You could like change the typo and it'd be an hour and a half. 

[00:10:19] And so from there we were like, We need to reduce peak memory utilization and Redux is not going to help us there. And so we started looking into alternatives. We looked at SQL Lite, we looked at Reddis and we landed on LMDB, which is, Lightning memory, mapped database manager. 

[00:10:39] It's like a file system DB, which is really cool for us because one, it's pretty fast. It allows you to, to have like a query interface, which is good. You can store more data than available RAM. So for a site like this customer who pretty much is blowing up this pod on every warm build. To try to even have a warm build, we could actually store their data now, which then unlocked warm builds for them. 

[00:11:05] So an hour and a half, that went to 25 minutes, which is pretty good for them. now we have this thing, now we call it Gatsby DB internally. And so now Gatsby is node store is in LMDB. And the cool thing about LMDB is it's just comprised of a bunch of files. You have a lock file and database files. 

[00:11:26] And if you have files, that means you can move files around. They don't have to be in one place, right. They could be in storage, they can be in a serverless function. They could be anywhere you, you really want. Right. And so that was step one was we needed to redo the node store. And we did that and memory utilization from a lot of customers went down. Enough to unlock a simple thing as a warm build.  

[00:11:50] Parallel Queries (PQR) 
 
[00:11:50] Abhi Aiyer: So then the second thing that this, these other customers were having was like, wow, it takes so long to query, to run queries. Right. And people have like 25,000, 50,000 queries. And I don't know if they should have those that much, but they do. 

[00:12:05] Right. They do have that much. And it's a huge part of the build time. Right. A lot of people complained that. You know, Gatsby builds are sometimes slow for large sites and we agree. That's totally true. And so our next foray into like improvement was this thing called parallel queries. Which would allow Gatsby to run chunks of queries at a given time and what PQR in his pool, a diagram of it, you know, query running does take a huge percentage of your builds. 

[00:12:39] But now we can parallelize that across workers in the Gatsby process. But if you were to do this naively with Redux, like a child process can't write to a JavaScript object in the main process. Right. It's hard to maintain state. There's no easy way to communicate between workers to write state and read it. 

[00:12:59] And so with LMDB in place, we have workers that can read and write to LMDB, which allows us to run parallel queries. Right. We don't need to do things serially, anymore. So PQR was a huge advancement for us. I think we saw up to like 40% reduction in query running time. And build times went down or we had like a goal, like I think it was like, we'd try to look for at least 20% reduction in build times. 

[00:13:27] And I think we hit 26%, so all cool wins, you know?  

[00:13:32] Gatsby DSG 
 
[00:13:32] Abhi Aiyer: And so then Ward and I, and the team were all just like thinking like, okay, we have LMDB. We've got PQR. Alright, well really we have a Gatsby data layer that can be accessed from anywhere, right? Cause if you can access it from a worker, you can access it in a serverless function cloud run, you know, on your somewhere, anywhere you spin up your own machine and your own office, if you want it well  

[00:13:56] swyx: steady coast. 

[00:13:57] How about that? Like an S3  

[00:14:00] Abhi Aiyer: bucket, you put it in an S3 bucket, for sure. You know, like you could put those files there and then retrieve them from wherever you want. And so that's when we started thinking like, okay, we have this information now, what can we do to improve the, the life of our users even more. 

[00:14:19] And then we started thinking about DPR and like, we saw the approach and we were like, wow, this is exactly what we need, but we have Gatsby's data layer that kind of complicates things, but it's not complicated anymore because we can essentially use the data layer wherever we wants. So I'll let ward kind of go from there on like how DSG came about after these like fundamental pieces. 

[00:14:42] Ward Peeters: Yeah. So then we looked at like ISR DPR and like what's the difference in both of them. And then we saw like ISR that's where you have a refresh timeout and an hour with, in the latest next, you can also being an endpoint to they're getting validated cache, but it's all manual work. And there were many complaints about it's an index. 

[00:15:02] It's nothing in Gatsby and they complained about stale data, because what Next.js does is you visit the page and then the next time it will update. So I think it's a refresh or something. Yeah. 

[00:15:15] swyx: Alright. Alright. We don't have to dig through issues on, on the, on our call, but I just wanted to illustrate the problem.  

[00:15:24] Ward Peeters: Yeah.  
 
[00:15:24] Netlify DPR vs Gatsby DSG 
 
[00:15:24] Ward Peeters: And then that's where we took it away and then say, okay, DPR. And then I looked at the spec of DPR, like, okay. Can we use the same name or not? And the problem with DPR was they had Atomic deploys. So every change means blow the whole cache away and do everything new and we were like, what do we have incremental builds from there? We don't want to like invalidate the whole cache. We just want to invalidate the pages that got removed. And there's like a GitHub discussion about it, where I commented as well. 

[00:15:55] And it felt like they didn't want to change the name. Yep. There you go.  

[00:16:04] swyx: So you said to me, DPR, doesn't need to be opinionated about if the file is part of the atomic deploy. Can you reiterate why?  

[00:16:13] Ward Peeters: Yeah, the thing is basically because they mentioned like everyday glory needs to blow the cache away and needs to be fresh. 

[00:16:20] And for me, like it shouldn't be in a spec like DPR should just say you built pieces at build-time and you build those pieces at runtime. That's basically what I was trying to say. And then because we have incremental builds, we only want to invalidate like five pages, even if you use SSG or DSG, we still want to say if you only changed five pages for evil dates to cache for five pages, I couldn't get that from the spec. 

[00:16:46] I think that's also because Netlify does it their way, which is totally fine, but then that's why we created a new acronym called DPR. And I think it's also probably explains. What we offer as well, a little bit better too, because it's Deferred Static Generation. It's like lazy SSG, something like that, because that's what we do. 

[00:17:08] Like you can mark a page as defer and that just means we don't do it at build time, but the first time you hit a request. We rebuild it in like a Lambda, I could use Cloud Run, we build it and then we give the response to a user and then also we save it to disk. So from there on, the second request, it's technically an SSG page. 

[00:17:29] We store it like you have the CDN cache, but we also have it inside our bucket. Like, your S3 buckets or whatever you want to call it.  

[00:17:37] Abhi Aiyer: Yeah. We're caching responses, but we're also making that file exist as if it existed at build time. And that's a big distinction for us because what that allows us to do in the future would be like, if nothing changed about the data for the given page, then you don't need to DSG again. 

[00:17:56] Right. Like if nothing changes for, let's say like there's five builds and build a. Something changed in your data dependencies. So now you have a DSG page and then nothing changed for the next five builds, but a user comes and actually visits that page generates the files. It gets cacheed in our data layer or our files storage layer and on build five because nothing changed. 

[00:18:24] You're not DSGing. Right. You're not going to go through this process again. And so that's we think is the big thing about DSG.  

[00:18:31] Yeah. And then I think the extra piece of it is because the date, like you can say it it's a benefit or or a negative point of Gatsby, like we source all the data at the build time. 

[00:18:41] So even if your APIs go down, even with DSG, you still go to our local database. So debts will never go down. Cause if like your site is down, your database will be down as well, but you, you're not dependent of other API. So let's say GitHub goes down or X go down and you need to get that data. We have it locally in our database, so you're still good to go through, still keep that resilience. 

[00:19:06] And the security even that you, you used to have with Gatsby, and I think that's a main benefit of the whole datalayer piece of Gatsby and DSG.  

[00:19:17] Yeah.  
 
[00:19:18] swyx: Yeah. Perfect.  

[00:19:19] The End of Jamstack 
 
[00:19:19] swyx: So something I always wonder about like, is this basically the last stage of JAMstack like, I feel like we have explored all possible varieties of rendering. 

[00:19:30] And this is like the end. This is like, this is it right? Like we have all the options.  

[00:19:34] Ward Peeters: And now it's mixing them together. It's the next step having been static and on bits of your thesis, SSR. Uh,  

[00:19:43] swyx: okay. I'll put it this way. Do you think that JAMstack at the end of the day after this, maybe like five-year journey of like, Hey, like a WordPress sucks. 

[00:19:53] That's everyone moves to static. Right. And then, and then we found like, oh yeah, static. Doesn't scale, big surprise. We were telling you that from the beginning. And now okay. Right. Hybrid. Is that it, like, it was that the Jamstack movement in like a five year period? 

[00:20:10] Abhi Aiyer: I think it's a yes or no. Like evolution is like, I think we're, you know, we're all coming full circle and I think in engineering, particularly we do the same thing all the time, every 10 years or something. Right. But where DSG came into play is for use cases that we saw, you know, and our customers still prefer static. 

[00:20:31] So I know we're talking about DSG. Like it's like a great thing and it is, but a lot of our customers prefer static and it's really up to their use case. If you're a small site out of a bunch of top of funnel page, any lag in anything, right? Cause DST is not like instant, right? Like you're doing a runtime build essentially. 

[00:20:51] Right? So in some cases it could be, you know, it could, it could be a longer response time than what the standards should be. And we have customers that won't DSG anything because they have essentially, most pages are top of funnel or high traffic that they would rather just wait.They don't mind waiting for the performance that they would want. 

[00:21:11] But we also have customers that have hundreds of thousands of pages, like there's one customer that has like a company handbook or something where like, you can see every employee. And like, if they like dogs and like, you know what I'm saying? Like, Bio's and stuff. And they have a lot of employees worldwide, and there, they can only like before DSG, they can only build their site once a week. 

[00:21:33] Cause it takes like 24 hours to build. What, and now with DSG, they don't really care about someone who no, one's going to view their profile. No offense to that person, but no one's viewing the non CEO's profile. So then how they can, like, you know, and there are other people that are important too. I'm sure, but like now they can actually, you know, make changes to their site. 

[00:21:55] You know, we actually had to work with them to make sure that, you know, they can build. I mean, previous to DSG, they can build like, at some cadence that we don't necessarily support, but we help support that. So, so just looking static is still king when it makes sense. For sure.  

[00:22:12] Tradeoffs and Performance 
 
[00:22:12] swyx: I feel like it's a bit scary when you tell people like, okay, you're deferring the build. 

[00:22:16] And then on the first request, someone's going to build that. It's not going to take that long. Yeah. Right. It's not like it's that bad. I think bottom line is, I think people are very scared whenever you say, like, okay, there's a trade off, but you don't quantify the trade-offs. And then they're like, oh, it's bigger in their mind than it really is. 

[00:22:37] Ward Peeters: Yeah, I think a big problem with the plugin ecosystem is that it's difficult to, to quantify like what's slow and what's not slow. For example, generating an MDX page is more time-consuming because it has to like get some dependencies make sure that they have bundled together, then use react to render and then render again because it's how the Gatsby plugin, is built right now that takes more time than a simple React renderToString with something. 

[00:23:07] And I think that's the difficult thing to say like, okay, it's some pages will be instant. Some pages might take a second to build or we'll half a second.  

[00:23:18] swyx: Yeah. The important thing is that there are not data dependencies that you're waiting on. Right. That's usually the slowest part fetch all the data upfront and then you store it in a LMDB cache. 

[00:23:28] And that's written to a serverless function or written to I guess your build process or whatever. And then people can render that whenever which I think is great. Like, it should be fairly fast, like we're talking tens of milliseconds difference between like for first render, right? 

[00:23:44] Like something like that. Like I think, I think when you quantify, like, okay, we're talking tens of milliseconds, not hundreds of milliseconds and not thousands of seconds that really helps me with. Put these things in perspective.  

[00:23:56] Abhi Aiyer: Yeah. But then, you know, people always find a way to screw it up. So say that like, of  

[00:24:01] swyx: course. 

[00:24:01] Yeah. But, but you give a realistic benchmark and then you go like, yeah, for these benchmarks, we tested it like a hundred times or something. The median was this, the P 95 was that. That's it like, I mean, people can't really fault you for not accounting for every use case because no one, no one can, but at least you can give a reasonable basis and say like,  

[00:24:22] Abhi Aiyer: there's,  

[00:24:23] swyx: there's an up, there's an upper bound to you know, how bad, how the, the, the trade-off like, you know, when, whenever you miss channels, I like to quantify it basically. 

[00:24:32] Um, that's a good, that's a good idea.  

[00:24:34] Image Processing 
 
[00:24:34] Abhi Aiyer: And like, one thing to know for DSG is like, your data may be like available and that's cool that that may not be the long pole, but let's say you have a portfolio site that generates 20 different types of images for every image. Now you're getting into image processing at runtime, you know? 

[00:24:54] And so there, there are ways to kind of not do this properly. Right. And or like, for example, let's say your homepage, I love this example. Your homepage has links like to every other page on your site,and it's all DSG, right? So you load the homepage and because Gatsby does prefetch for link tags are doing Gatsby link to other pages. 

[00:25:17] We go and prefetch every page on your site. And essentially you're doing your build at runtime. So we're going to try to prevent these cases from happening, but just natively going through DSG everything is not my recommendation. That's for sure. 

[00:25:32] Not today. At least not today.  

[00:25:35] swyx: so a couple of things on that. So, this Gatsby image point is very interesting. So how does Gatsby image work with DSG? 

[00:25:42] Abhi Aiyer: So yeah it works how it does it in Gatsby build. currently today Gatsby uses Gatsby-plugin-sharp and the sharp transformers to take one image, turn it into another. 

[00:25:54] And even in Gatsby cloud, before we implemented parallel image processing, images were like the slowest part of the Gatsby build because a lot of time, a lot of memory, et cetera. And so we solved that problem. And so in the DSG runtime, we do image processing there for a particular page. 

[00:26:15] So you will have to wait for image processing. If you're image heavy on a DSG page.  

[00:26:21] swyx: Which I mean, does that mean that you cannot do a DSG in a serverless function?  

[00:26:26] Abhi Aiyer: In a total? We do. We actually do DSG in serverless. And that's totally fine. Like you can do image processing, you know? But like, I would say your mileage may vary given what kind of transformations you have going on, how many images you have, right. 

[00:26:42] But like you said, there's, trade-offs right. If the page makes sense for it, you know, we have a bunch of examples that do have images and they work great, you know? But I don't know if I go full on portfolio with like a, you know, like a masonry thing where like, there's like tons of images and they have sub images and you have to go, like, I'll be like a carousel of images and stuff that may not be good for your. 

[00:27:06] I don't know, but the choices, the users, that's, what we're trying to get at is like, we're trying to give as many options. We're going to give guidance and like we're having our own opinions, but you, you can choose to listen or not, or, you know, do your own thing and we should try to support you as much as we can. 

[00:27:25] Automatic DSG 
 
[00:27:25] swyx: Yeah, you give me some thought about like, having sort of like a browsers list type of API where you can say like, okay, top 100 most visited pages. No, this is not it. You know what I mean? Like, as a handholding for what should be DSG and what should be statically generated you know, plug into my Google analytics, tell me like top hundred pages statically render those, everything else, DSG. 

[00:27:48] I'm sure you've thought about it. And I think like maybe four years ago, Gatsby and Guess.js had someone in collaboration, which I assume went nowhere. But let me know if there's.  

[00:27:59] Ward Peeters: Uh, okay.  

[00:28:02] For now. Yeah, because there is a new way to do it because now greet guests, it stored everything in one file. So we have to like sometimes download a five megabyte Jason file to make guess.js work. Mondays switching around that you could make, get smarter to say like a guess for this route. You only need the bit of the JSON file. But we never implemented it. So,  

[00:28:26] Abhi Aiyer: yeah. And we have this, so I'm speaking from the Gatsby cloud perspective, but like you're right, Shawn. Like, if you can hook into Google analytics, you'll get the same thing. 

[00:28:36] But if you host with Gatsby cloud, we know what, what routes coming through our hosting layer. We know what routes for your site. Are the most hit, you know, we know the requests per route. I mean, how much bandwidth you're using, like per route. And so we could be smarter and tell people exactly how. How to DSG, right? How should you DSG and get it done that way, for sure.  

[00:29:04] swyx: Okay. So like a, to be, to be complete, uh, typical to be  

[00:29:08] Abhi Aiyer: complete, you know, we're still in beta forgets before, so I would say like, maybe like after we launched for, for sure, we'll start adding some sugar on.  

[00:29:17] swyx: Got it. So first of all I did, so this was my first time trying out Gatsby Cloud. I, I think it was behind like a signup wall, like a private beta in the past. And I never really gave it a spin, but again, you know, the V4 announcement really got me going and And yeah. I mean, I'm pretty impressed.  

[00:29:33] Gatsby Cloud vs Netlify 
 
[00:29:33] swyx: So how much of this, you know, the hard question, right? How much of this is a Netlify clone, what are you doing differently? 

[00:29:40] Abhi Aiyer: Let's talking about that. How much does like DSG is  

[00:29:45] swyx: how much of Gatsby Cloud? Isn't it  

[00:29:48] Abhi Aiyer: like? 0%. Ooh, okay. Yeah. Probably 0% of it is a Netlify clone. 

[00:29:56] swyx: I do like when you provision it, it gives me like a really good set of options. Uh, let's see, uh, you know, connect CMS guests. Netlify does not have that. 

[00:30:07] Abhi Aiyer: Yeah. I mean, I would, yeah. We're far from an elephant clone Mo multiple weeks. We've built our whole system based on the needs of Gatsby. The way our cloud front end and our back ends talk to our customers, Gatsby Sites is a novel way of doing it. We've exposed that in open source and I think Netlify actually did implement something for external jobs or something with Google pub sub I, I saw that, but everything we do in Gatsby cloud is for Gatsby. We have no other framework that we need to maintain nor care about, sorry. Luke's or whatever. Like we don't care about that. On Gatsby cloud, we've optimized our hosting layer with Fastly to be part of the data. And so if Gatsby changes, Gatsby cloud changes, and if we need to get to be framework to change, it will for Gatsby cloud. So, and we use Google cloud, so we're not on AWS.  

[00:31:09] I would say we have the similar features though, and that's a valid point to bring out. 

[00:31:13] We have, we have functions, right. 

[00:31:15] We have domains and we don't have a purchasing domains or anything yet, but you know, we have the whole hosting product and everything like that. Yeah.  

[00:31:27] swyx: Is that, is that what you would need for Gatsby Cloud to come out of beta? Like. Domains or like what, what, what are you waiting  

[00:31:35] Abhi Aiyer: for essentially? Well, Gatsby cloud isn't in beta. 

[00:31:38] It's like a  

[00:31:38] Oh Gatsby v4  

[00:31:40] swyx: is in beta 

[00:31:41] Abhi Aiyer: yeah. V4 it's in beta. Yeah. Sorry. Yeah. Yeah, domain like domain registry and all that stuff is more sugar on top that we'll be probably releasing mid next year. But we're just trying to be I mean, Gatsby cloud, from that perspective, we just want to be at the table with all the other JAMstack providers. 

[00:31:59] But our edge is if you want to build a Gatsby site the best way, you know, you have our support team, that'll help you. Right. As a customer of ours, you're like our family. The Gatsby family, you know, we're, we'll help. We help our customers. We have great support and everything we do on the platform is for Gatsby and making Gatsby better. 

[00:32:18] So there's like so many things in the framework that we've improved by having Gatsby cloud. Cause we didn't know all the sites that could exist and not do things nicely or have problems or, you know, because of Gatsby cloud that the framework is getting so much better because we have real users feedback and they have a lot of demands and we like to, you know, fulfill them. Yeah.  

[00:32:41] swyx: Okay. Actually I should probably clarify this earlier. How much of what we just talked about is Gatsby Cloud-only? 

[00:32:48] Abhi Aiyer: Pretty much all of it, DSG, SSR, they're all capable, you know, you can run it locally and stuff. And I know Netlify has a Gatsby plugin as well that will allow you to run DSG and SSR as well. 

[00:33:03] For those who are not using those platforms, it's like maybe you're using Amplify or whatever. You're going to have to implement this yourself. I don't recommend it though, because it was a pain in the ass to put it together. But yeah, it should work the best on Gatsby cloud.  

[00:33:19] Ward Peeters: So technically all of that we building with v4 is in open source. 

[00:33:22] So you could wire it up all yourself, but why bother if you can use, like Gatsby Cloud. Yeah, you don't have to care about it.  

[00:33:34] Gatsby vs Next.js 
 
[00:33:34] swyx: That's true. Okay. So, just on the rendering side of things, right? I made this observation that, Gatsby now has SSR, now has serverless rendering. All the different rendering modes, like this looks very similar to next JS. 

[00:33:48] Is it possible to basically say like, okay, Gatsby is the data layer and is this the best data layer and most advanced or whatever, because this is basically what Next.js does, right? Like it's a very, very constrained rendering layer. Why can't you, I mean, you know, sunk costs aside. Why can't you be a next JS layer? 

[00:34:08] Ward Peeters: Well, technically we could now, because they like implemented everything too, like they have SSG, they have ISR, they have SSR and we could technically move the data layer out of, and use it with next. That could be a possibility, but. We've been, we've come so far and I think do already have built this. 

[00:34:31] And then now they're also parity. I think having two separate ones and having different dev experience, and maybe Next.js is winning now and Gatsby will a win in, in two months or vice versa. I think it's just a healthy balance. Like it's and I think it's the same thing as a browser wars, like everyone is going to Chrome or chromium and then there is still like, Firefox and iOS, but how long will they survive? 

[00:34:58] And I think just the competition is what you need. And I think that's why a good reason why we keep separate. And also, I don't think that Next.js is for like, merging with Gatsby or like having the like the same.  

[00:35:13] swyx: Oh, I think I know Next.js, it be super happy about it, because then they, when they, when the server for reacts you know, role, and then you focus on the data role, right? 

[00:35:22] Like, uh, Makes sense to me, obviously I'm brushing over a lot of the plugins actually have a rendering portion as well. So how much can you separate those things  

[00:35:33] Abhi Aiyer: if in the next. No, this is possible. I don't, I mean, we're not going to like say that it's happening or anything.  

[00:35:41] Gatsby and the Content Mesh 
 
[00:35:41] Abhi Aiyer: Like if we look at Gatsby's like, this is how it's set up. 

[00:35:45] It's, it's what we call the content mesh. You have all these different data warehouses that exist. WordPress Drupal, et cetera, can even be a freaking Google Sheets. You know, like whatever, and we assemble this data layer at build time. And in doing DSG and SSR, we build something called the query engine that allows you to query this LMD B store that has like the manifested data in there. 

[00:36:13] So. It really opens up the gate for yeah. If you want to use our data layer in a Next.js app, like, I mean, go ahead. Like once we expose this API to our customers then you can essentially have Gatsby data in an iOS app or an Android app react native. Like, it's just an API call at that point. And you know, Gatsby cloud hosts, like a graphical API for you that you can just query your data. 

[00:36:38] I don't know if any data scientists would care for that. They could add that into Looker or something. You know, like I remember they want to do it like that stuff would be available and it's almost like a content data lake versus, you know, traditional data lake I guess. It's purely for content and you would have the benefits of Gatsby because we normalize and we create structures and you like, the user can customize a schema, however you want. 

[00:37:05] And then now you can use it on multiple platforms, right? It's not an immediate goal for us to do so. It's a logical next step. Yeah. Yeah.  

[00:37:15] swyx: Awesome. Awesome. Cool. Yeah, I, I feel like that's a really good and in depth coverage. 

[00:37:19] React 18 and Gatsby 
 
[00:37:19] swyx: Maybe let's end off with talking about the future of React 18 and your plans there. First of all, what's happening in react 18. Is it out? Like the plan for the react 18 and published in June? Okay. All right. Let's talk about it. What's what's going on? 

[00:37:35] Ward Peeters: So, yeah, so we are working closely with the React team and we also in the working group to figure out like, okay, how can we help the team, make it more stable and give it in user hands. 

[00:37:46] So I think from may or something, we have introduced React 18 as part of Gatsby. So you can now install React 18 alpha. And we just moved to the new rendering mode. So the async mode suspense and all those things were. Like what, what we're planning on, at least when you use Gatsby, like we have page queries and we have static queries and there's a big pain point is static queries, cause it's a graph QL query, but you cannot have any variables, which means you're kind of limited to the unit. And then you have to move everything to page queries going to have to know all the content up front and wait the new async rendering bits of React to get into like a useQuery, because you can yield the rendering of React at any time. 

[00:38:34] Cause async doesn't mean you have to go like, uh, use Apollo Server to get server data tree or something or other pieces, or you kind of have two have React async mode or React Suspense in SSR and we can all move it to the page components or the components of your reactor. So basically look that you're just recreating an react application and then every async bit like using react-fetch or a useQuery, it all just works. 

[00:39:02] I think that's where, where we activate in benefits a lot where it's. It just removes a lot of cruft or that you have to do now. It gets you where you have to be in the Gatsby mindset when you're developing and, and you basically go to a, creating a react app and you have a data layer, but I think React 18 opens so many doors with the new cache APIs. It just becomes way smarter and when you look at it from a performance perspective with the whole concurrent mode where inputs gets priority over rendering, it's just going to be way smoother than what they had so far. 

[00:39:39] Abhi Aiyer: And hopefully people stop complaining about lighthouse scores and stuff. That'll be great.  

[00:39:45] Custom rendering page fragments with React 18 
 
[00:39:45] Abhi Aiyer: Another cool thing that React 18 kind of unlocked for Gatsby in particular is a concept of fragments. And so we were talking about that nav bar example earlier with the a hundred thousand pages. And we want to leverage react 18 with like custom renderers so that we can essentially create fragments of a page that had beta dependent. 

[00:40:07] Because there's no page query or static query anymore. That's just a query. Your navbar component has a query and essentially Gatsby can make that nap bar a navbar fragment and your body has a fragment, or maybe your footer has a fragment. Your sidebar has a fragment. And as data changes incrementally, we only rebuild fragments and our hosting layer, stitches, fragments together. This is an old concept called ESI includes like if everyone did PHP back in the day, like, you know, very familiar with this stuff, like I said, every 10 years, things has come back around and we're going to try to do that. We're going to try to build fragments of pages, stitch them together. So a navbar change doesn't break the bank, you know? But we can only do that once react 18. It's like, you know, fully there. I mean, we could do it now, but like why, when we should just like work off the, the, the work of others.  

[00:41:02] swyx: So when you say fragments, are you referring to GraphQL Fragments or, or like  

[00:41:06] Abhi Aiyer: Asian fragment might be a, maybe we call it like, you know, today, like an HTML page that has specific. 

[00:41:13] You know, I like to call him like the rectangles that we all draw around are our websites. Right. They all have independent data isolation. Right. And so these are like what maybe a Gatsby slice of a page or a fragment or some type of include, you know, like in the templating days. Right. And that's what I kind of mean there. 

[00:41:31] So these includes or templates or whatever you want to call them would be independently built. And then independently stitched at the cache layer. And then, you know, the data dependencies don't cross, and now I'm not building a hundred thousand pages because I misspelled Gasby and it should've been, you know,  

[00:41:51] swyx: sounds like it happens a lot,  

[00:41:54] Abhi Aiyer: but definitely those,  

[00:41:56] Ward Peeters: and it looks a lot like donut caching. 

[00:41:58] If you're more familiar with that piece, like you have a page where I said parks has a different. Limit and another one. So that's more or less the technical piece out of  

[00:42:10] Server Components in Limbo 
 
[00:42:10] swyx: a server components. Anything on any implications on that forgets me?  

[00:42:15] Ward Peeters: Not yet. I would say because they're not going to ship it with react 18. 

[00:42:19] We've been talking about it, but it's still very fresh or very new, like even the React team hasn't, hasn't worked more on it, so they did their demo, but then it's got like a little bit  

[00:42:31] swyx: stagnated. Oh my God. 

[00:42:37] Ward Peeters: All the pieces. Like they need to build all the pieces underneath it to make it work. 

[00:42:45] swyx: They jumped, they jumped the gun, maybe in announcing I got so excited. I was like, wow. Okay. I can cut my Javascript bundle by 40% and run backend functions in my react component. And then nothing, nothing for 10 months,  

[00:43:01] Ward Peeters: because we are super excited about it too. Because when you look at especially marketing sites, like marketing pages or blogs, there's only a small piece of JavaScript that you actually need. 

[00:43:13] Like maybe you need a bit for your newsletter button or you like something like that. And why. 200 kilobytes of JavaScript could bring technically only need maybe 10, 20 kilobytes. So I think it's static or with like marketing pages. Uh, 

[00:43:33] Smart Servers vs Smart Clients 
 
[00:43:33] Abhi Aiyer: yeah, so the world was server rendered. Then we went client side rendered. Then we went static rendered. Now we're DSG rendered, and then we're going to go back to server run. So, you know, time just keeps spinning. Partially server.  

[00:43:47] swyx: I called it smart server versus smart clients is my term for it. So this is the, I think maybe my, my most recent posts, because I have been trying to write more, but then I keep have having real life get in the way. 

[00:44:01] But why is traditional, which is server rendered, different from the new server rendered. We have essentially is essentially exactly the same, but there's a thin runtime, which I'll ship the stuff that we send over the wires changes. And we actually doing rendering in the browser, but like partial rendering, maybe I should say. 

[00:44:20] And yeah. I dunno. I think, I think this is a very interesting exploration. Phoenix live view is also the other one that, that gets a lot of love for this. And then rails is also adopting Hotwire. So, I don't know where this goes. I mean, I, I it's, it seems like we fully explored the smart client space and the smart server revolution is just kind of get, getting going. 

[00:44:41] Ward Peeters: We're going back to Meteor.  

[00:44:44] swyx: Back to meteor, but not so opinionated, I think, you know, I was very excited about meteor. Like when I, when I first started as a web dev, I was like, oh yeah. Okay. Everything is in there. I actually mentioned Meteor here because it had the mini Mongo data store, which was I thought it was just such a great experience. 

[00:44:59] Did you use.  

[00:45:02] Abhi Aiyer: Oh, both my last company, we used meteor for our backend, and then we had to kind of migrate slowly off of it. Cause they were just ahead of their time. You know, now all those concepts. Those are like, those are the concepts of today. Right. And that's the beautiful thing they were  

[00:45:19] swyx: just ahead of their time. 

[00:45:21] Apollo and Open Source Startup Strategy 
 
[00:45:21] swyx: I mean, you know, what they did was they became Apollo. They were just like, oh no, one's no, one's handling all the hard parts of GraphQL. Well,  

[00:45:29] Abhi Aiyer: okay. We'll do it. Yeah, good job of that too,  

[00:45:33] swyx: which is by the way, like in terms of just honestly, I'm interested in startups, entrepreneurship, uh, you know, we worked so hard in web dev stuff. 

[00:45:41] A lot of this, we never charge a cent for and something I would like to make money on the smart things that we do in tech.  

[00:45:47] Taking an under specified spec, which most of the times is intentionally under specified, and then building all the hard parts around it, is a very interesting formula for success. 

[00:45:58] So essentially React and under specified framework and Next.js came in and went like, oh, okay, well, we'll build the get initial props that you guys forgot. And great, very successful Gatsby, same thing. And then Apollo and Relay by the way, but, but relay was not a serious company, a company effort. 

[00:46:19] I mean, Relay is a serious effort. It's not a startup that was like existentially relying on like, uh unsuccess. Whereas was Apollo was like, okay, GraphQL was under specified. There's a reference JS implementation, but no one's building the production quality standard. We'll do it. And then, and yeah, like it's really interesting. Cause as the spec grows or as adoption of the thing grows, you're you grow with it and, you serve the audience and you also capture a lot of the value and you essentially have Facebook working for you in the sense of like, oh, there's the spec maintainers, you know, whatever, whatever the spec is, they're working for you because every time they contribute to the spec, you. 

[00:47:06] TMA: Too Many Acronyms 
 
[00:47:06] Abhi Aiyer: Yeah, maybe that's what the what's going to happen with DPR. Right?  

[00:47:10] swyx: The naming socks, too many, three letter acronyms. I'm sure. Like, look like you and I, and everyone in like the WebDev, like Twitter sphere or whatever, we don't mind new things and like understanding the differences in nuances, but anyone who is like just a regular web dev or just like not web dev, but talking to web devs, they think we're crazy. 

[00:47:36] This is actually bad. Like it, we look like the nerds, uh, who. Talking about all these minor differences and inventing new acronyms for them. I don't know how to fix it. Jargon is important for specialists to understand in a very short amount of time, the differences between what we referring to. Jargon is important, but we don't do ourselves, our industry a favor when we have all these acronyms and then people just throw them on onto a page or a blogpost or a slide deck. 

[00:48:05] And then. People would just go like, okay. Yeah, the JS ecosystem  

[00:48:09] Abhi Aiyer: is crazy. And you ended up explaining the same thing all the time. Right? Cause you use some acronym. It was funny, like on the way to Gatsby camp, like we had, like all of our release had all of the releases and gas before had the acronym. Yeah, like PQR parallel query, running DSE, SSR, SSG, man. 

[00:48:26] We were like trying to figure it out. How many more acronyms can we fit to, to get like the, the acronym count up, but it's a serious problem for us too, because our, some of our customers have never used Gatsby before they're coming from a WordPress full on WordPress background and our sales team marketing, we all need to be able to convey like, yeah, this is what it really is. 

[00:48:45] And this is what it means. And maybe. The acronym sticks after they understand it, but that's a really uphill battle to explain right on the way. So I would love if a community we all got together and like, kind of just understood it. You know, it's kind of like the GraphQL spec have a formal definition for what this is. 

[00:49:02] Don't be too heavy handed on approach, let people implement however they want to. And then there's just a concept that has different flavors. Yeah. Oh, it's different  

[00:49:14] swyx: flavors. Okay. That'd be interesting.  

[00:49:16] Gatsby for Docs 
 
[00:49:16] swyx: Is there anything else that we haven't covered that you wanted to shout out?  

[00:49:21] Abhi Aiyer: This is fun. I really enjoyed talking to you too.  

[00:49:24] swyx: Yeah, I love, uh, I love catching up. Um, uh, Fun fact, we're actually at my workplace. We use Docusaurus right now for our docs. We're actually considering moving to Gatsby. 

[00:49:35] Nice. Not something I thought I would do this year, but we're, we're running into enough limitations to Docusaurus that we're essentially customizing so much that we don't get much benefit anymore. So maybe a good standard docs implementation. It would be interesting for you guys actually, because a lot of the reason that people pick Docusaurus is basically it has docs in the name and it's got a lot of good defaults for docs, right? 

[00:50:04] And Gatsby, maybe it doesn't have such a developed theme for docs.  

[00:50:07] Ward Peeters: We've mostly pushed people to the Apollo team. Like they have a great, like the whole Apolo site is, or docs site is built with Gatsby and a open source. The building blocks up there. So, or you could start from there and then, oh  

[00:50:20] Abhi Aiyer: yeah. 
 
[00:50:23] New Relic is with Gatsby and they're working on something similar too.  

[00:50:30] swyx: Awesome. Awesome. Yeah. All right. Cool. Well thanks for those pointers. I'm actually going to go explore them. 

[00:50:38] Abhi Aiyer: Yeah. If you need any help. Yeah, we'll do.  

[00:50:41] swyx: And there's no reason why we shouldn't move to Gatsby cloud, if that makes sense for us as well. Okay. Okay.  

[00:50:47] Ward and Abhi,thanks so much, and this is really great chatting, thanks for reaching out. And, yeah, I hope  

[00:50:52] Abhi Aiyer: people would try out Gatsby. 

[00:50:54] Thanks for having us.
2021 Swyx