Supper Club × Why Netlify bought Gatsby, GraphQL Data Layer, and Headless CMS with Dustin Schau

Welcome to Syntax podcast with the tastiest web development treats out there. We've Got a good one for you today. We have Dustin Shao on today, to talk about he's, obviously, the Gatsby cofounder. You probably know that, but, We're here to talk to him about Gatsby, maybe rack server components.

They're new. Like we've there's this kind of Theme that's been popping up on the show over the last year or so, which is like GraphQL as a like an intermediary data layer, Especially for big companies. We're hopefully gonna talk about quite a bit about that and whatever else pops up. Welcome, Dustin. Thanks so much for coming on. Yeah.

Glad to be here. I think people say longtime listener, first time caller. Right? So, glad to be here and talk about all of those things. Wicked.

So why don't you give a Quick rundown of, who you are, what you've done, and sort of your come up to where you're where you're at right now.

Yeah. I'll keep it quick.

So I would say by trade, I'm a front end engineer. So I joined Gatsby, like, 5 years ago, not as the cofounder title. That was kind of like an honorary thing near the end, But, I built other teams at Gatsby, so helped build the product team, customer success team, the engineering team.

And then, eventually, they got acquired by Netlify.

So So now I'm a senior director of engineering at Netlify, helping lead the team that is bringing, Valhalla to market, which is how some of you may have heard of, basically, Gatsby's data layer has, like, a new product, separate, kind of plucked out, and then made available to West, just like you said, like, Large teams, you know, sourcing data from 1 or more content management systems, and then exposing that GraphQL API for all users. So, yeah, that's a little bit about me, and I live in San Francisco Bay Area. I have a newborn.

He's been 4 months old. He's cute. Oh, congrats.

So, yeah, things are good. Yeah. You sleeping? How's the sleep going?

Yeah. You know, enough.

Enough.

Yeah. You know, that was delirious for, like, the whole 1st 2 years. Just like a completely, a shell of my myself.

Yeah. I'd say I have good days and bad days and, More good days, I think, is a pretty easy baby for the most part, which is good. Nice. So is is Valhalla

we'll get into, like, details and stuff like that, but I I I just wanted to to Clear about it is Valhalla, it comes completely out of Gatsby. That's like, it didn't come from Netlify. It just comes from Gatsby itself. Yeah. So,

Basically, if anyone used Gatsby, which I hope is many of you, you know, one of the things that I loved the most about Gatsby and honestly why I joined the Gatsby team 5 years ago was that plug in ecosystem. You know? So, particularly, there was source plug ins. So, you know, you can source data from, like, markdown, which is what I I built. You know? My first ever Gatsby site was a blog Using markdown, I'm like, oh my god. This thing is freaking magic. Right? But, so, yeah, what Behala is and was, it's actually kinda funny. About a year ago, me and an engineer, Avi Iyer, got together. We had a vision on, like, hey. You know, we think the best part of Gatsby is actually this, you know, unified GraphQL data layer And this source plug in ecosystem, let's pluck it out, and let's make it so that you can use this, unified GraphQL API, and then the source plug in ecosystem, outside of Gatsby. You know? Because we recognize that, you know, there's lots of different tools and front end frameworks and, Other competing solutions, you know, that maybe are more popular now, so I can just say Next. Js, it's a great framework. Right? But We still think that there's a huge problem in, like, building a composable or a jamstack site with content sources is actually really kinda hard, And so we wanted to make that layer available to any developer, to any user,

without necessarily that strict tie to the Gatsby framework. Zeg. Yeah. That that's really cool because we have talked to we've probably had 3 people on the show, and they all work for Rather large companies, one of them was a major TV station in the UK.

Another one of them was A pretty big corporation here in the States.

And they all say, yeah, like GraphQL is is awesome.

But we've got 600 engineers banging on our keyboard every single day.

And in order to, like, make some sort of standardized API, it's Possible for all these devs just to decode against this. Is is that what you see as well? Yeah. Definitely. And, like, you know, I mentioned that it's kinda fun. I'm a little nostalgic about it. A year ago when we got together in a room, Avi, myself, and then a few others just to, like, kinda hack it out. And first thing we started is we built, like, a Svelte app. You know? And, like, we were like, hey. Let's build a Svelte app with Contentful. And I'm like, this actually really sucks.

It's actually really freaking hard even just sourcing at once. And to be clear, it's not it's not the spelt sucks, but it's not that Contentful sucks. So it's actually hard, you know, to build a composable application from those data sources. So, Yeah. That's Wes, you kinda hit the nail on the head there. It's, it's surprisingly hard, to build a decoupled, perform an application from 1 or more content sources, and we find that it's, you know, it's hard for 1 content source, but it gets, like, doubly, triply, quadruply hard, You know, each new content source, that you add. So, yeah, that's precisely the problem that we're trying to solve with what used to be called Valhalla. I'm sure we've got product naming and the Shameless plug at the end and stuff. But Oh, you well, give it give us the name of it now so we're not calling it the wrong thing the whole time. Alright. So Valhalla is call it a Gatsby.

And then as part of the acquisition, it's now called Notify Connect, which makes a lot of sense. You know? So you I really think of Valhalla formally, and I know if I connect as this kind of glue layer, between content sources and then perform in front ends. You can use Gatsby with it, but you can use Next. Js. You can use SvelteKit. You can use pick front, the light front end framework of the day. So that product that we're launching Soon, maybe by the time this airs, it'll be out of launch, end of June, it's called Netlify Connect. Nice. That's really cool. So the idea is that you've got

Shopify website and you've got, like, a raw database that you need to query and you have some weird API from the government And you wanna be able to, like, surface all of those things via a single GraphQL API?

Bingo. Yeah. We have a we have a customer in the beta cohort. It's kinda it's kinda funny, like, how interesting the, like, data problems that some teams have Or it's like, hey. We wanna get a new website. We're using Sitecore. Just like, okay. I haven't touched Sitecore in a long time. Mhmm. But we also are using Google Sheets and a CSV. I was like Mhmm. Alright.

Well, we can figure that out for you. So those are the kinds of, like, source plug ins. We'll call them, like, connectors, You know, for launch in the future that we want to enable teams to build or just, like, pull off the shelf, you know, if it's, like, a fairly common use case. So, obviously, we can't, Like, build a custom built CSV for every single one off use case, but we can enable those kinds of customers to build them, which will just work with the Connect product. So the so the connectors are

what takes the

the source and converts it essentially into A unified GraphQL API. Bingo. So I don't know if you all ever built a Kashi source plug in, actually. But, like, in a way, it's kind of building on this as, like, the prior art the inspiration for it in the future, it's like a fairly well documented, you know, good API for, like it's a little bit technical, obviously, but it's like, all a source plug in does is it creates nodes.

These nodes are then exposed on a graph, via GraphQL. And so What the, SDK in the future that would enable this will do is basically just kind of build on that as prior art and then say, you know, when you use this, SDK to build your source plug ins. Things just work, presuming that your source plug in creates nodes, and then, those nodes will be exposed in that GraphQL API. And does this allow you to then, therefore, have some sort of, like, relation between

the data from different sources as well?

Yes. Definitely. You can do that Today in the Gatsby source plug in land, but, yeah, we definitely wanna establish, like, relationships. So, like, you know, one such example that we hear about a lot is, You know, you have Shopify for, like, your commerce solution, but then you also want to enrich that Shopify data with, You know, a Contentful product listing with, like, more detail. And so we find is that those are the kinds of, like, relationships that customers wanna express. And with that API, with that SDK, You can express them via, either, like, the GraphQL extension point. Otherwise, you can also express relationships, like, natively in the plug in as well. Yeah. I do that. On my own website, I've got

blog posts and tips, and I probably have like 6 different content types in my Gatsby website, Which is they're all they're all just like text and images and whatnot, but they're all different pieces of content. However, sometimes I want to relate them to each other or Or at the very basic, I just want to add like next item and previous item, to it, and you can add a little bit of relationship there. And it's kind of cool because Some of the data comes from NMDX, but some of the other data I could pull either at build time or like it's It's, like, ongoing. Right? Like, is there a is there a layer to say, like, how often you should cache or scrape data from another API?

Yeah. It's a good question. So, generally, that's kind of like the webhook system. So, what we built on Gatsby Cloud was kind of this, like, Always on listener that, you know so, like, let's say, Contentful j Contentful data changes. That'll just fire a webhook. That will then, like, trigger the build, which will then resource the data. So we're doing with Connect is we're kinda taking that central idea, which is, like, when data changes in n number of content sources, just fire up a webhook, And that will then rerun the sourcing logic in that source plug in. So, generally, we encourage teams to, like, build on webhooks, but, also, like, just because they're webhooks, you can on a. You know, let's say you have, like, a really junky data source that doesn't enable you to, like, rebuild easily. Just expose yeah. Just rebuild every hour. You know? And by rebuild, it's actually kind of like a different model. What you're building isn't a site. You're building the GraphQL API. You know? And so, really, what connect is is it's a very fancy cache, for those n number of content sources. Yeah. That makes sense. And do does auth play into

this layer as well, or is that something that would then sit on top of that?

Yeah. Wes, you're pulling our future product rep road map from us. So, that won't be available at launch, but we are aware that, like, Honestly, like, the use case we hear a lot from our early beta customers is like, hey. We have 10 Drupal CMSs, and We don't want team x to have access to team wise data. You know? We wanna make sure that they're segmented and isolated. So we don't support that at launch, but it's definitely something that we plan to do in the future, probably in the next couple of months. All the source plug ins, are they

They're written in, like, JavaScript TypeScript, or is there a different it's similar to how Gatsby did it?

Precisely. So, What we're gonna launch later, we just call it the SDK or the Netlify SDK. So it'll have support for, build plug ins, which I think maybe you've seen before. It's kinda cool. You can Basically, like, a really robust, kind of powerful way in which you can augment your built site with build plug ins. And then as part of that, we're also adding the kind Kind of our calling the Connector SDK piece, the SDK piece of it. And, yeah, it's Node. Js, so teams can author in TypeScript. But, what it really is is just it's a well defined Node. Js API,

that you can implement to get support. Nice. And so like right now when you're looking at plug ins on like, let's say the Gatsby site, There's I mean, it's great. It's always been a really like nice interface to paw through the plugins and see what's all there. Is that all going to be moving into Netlify's, site and documentation? Is there gonna be, like, a new interface for all that stuff? Yeah. That's definitely where We're we're taking a very, like, judicious

approach, because a plug in ecosystem can be the greatest benefit and also sometimes the greatest curse. You know, like, think about, like, Apple App Store versus, like, Android. You know, it's like, yeah, the Apple App Store's a little more curated, and, you know, you just know if it's gonna work, You know, if you're using it. Whereas we we do think and kind of acknowledge that the Gatsby plug in ecosystem got quite large. And like Mhmm. I think oftentimes that's where a lot of users hit a lot Tripping points, you know, in the Gassy plug in ecosystem is like, yeah, it works great if I'm using a tenfold, but I'm using ThingX. And like, oh my god, it's not good, and it had all kinds of errors. So we're taking a very thoughtful approach that, yes, we wanna bring the bulk of that value over to this, like, new marketplace, but we We also don't want to bring over the quote unquote bad plug ins or plug ins that have been tripping users up historically. Yeah. So are these are all of Are all of the plugins going to be sourced from

Netlify

themselves as a team, or is it going to be community plus Netlify, community plus plus. So that's actually one thing that we found at Gatsby too is that, you know, we could leave it all to the community, into the CMS partners, into the CMS vendors, and that's Useful, but sometimes there are those that are just getting so much usage that, like, you kinda want the experts to help, like, lend a hand. And so, You know, we directly maintain things like Contentful, Shopify, WordPress, Drupal. We plan to continue doing that, and then, hopefully, we can get kind of, like, this Community flywheel going where you can attribute new ones, and they just work, you know, with this new SDK. Yeah. And is

Is Valhalla or sorry. Netlify Connect.

Will that be open source, or is that like, I know I know It was a paid product of Gatsby. And what's the plan when it's at Netlify?

Yeah.

It's a great question. So, by end of the month, you know, it'll definitely it'll be a paid product available on our enterprise tier over time.

We do want to open source that SDK, which is where, like, a lot of the value lives.

We're kinda thinking of it like the content engine, and we want to expose that API and make it, Contributable, open source, you know, so you get the bones of the product, you know, that are available to be used locally.

In theory, you could deploy that, You know, on other platforms, not including Netlify, because we do really value having an open platform where teams can contribute to it, and they aren't locked in to our ecosystem.

But we also just want you know, like like you mentioned, West, those those, like, large teams who just want it to just work without, you know, configuring x, y, and z. That's our overall kind of like motion we're thinking for Connect. I like it. And

what about the, like, query end of things? Are Are you gonna be bringing, like, do I just go use some sort of GraphQL, any plug in I want, GraphQL? Or do you do you have like a custom thing that Generates types and and queries for the client. Yeah. So

that's kinda where when I think about, like, what the future of Gatsby is, I think that Gatsby is the framework that supports connect best. You know? So it's like, if you really value these things, then, like, go use the Gatsby framework because It's kind of built with this in mind. And then for the other frameworks, you know, so let's say Next. Js or I really like Astro too. I think Astro's awesome.

I would say we don't have that solved yet. It's kind of like what are the idiomatic conventions for sourcing GraphQL data or just data more generally, in those frameworks. And then over time, I do see us building I think of them as like helpers or like primitives, basically. So something like a use query that works for any React based meta framework, or You know, similarly for actually, I have no idea how Astro sources data. So however, Astro sources data, you know, is something that we could, you know, think about solving for in the future. But at launch, We're mostly just saying, hey. Here's a cache, fault tolerant, hosted GraphQL API. Source from it as you will. And whatever front end framework you're using today, if you're using Gatsby, it would just work. If you're using other frameworks, there'd be a little bit of building on top of that GraphQL API. Mhmm. So yeah. Like, oh, Oh, bad. So Gatsby isn't going anywhere. Gatsby No. God, no.

No.

Yeah. It's interesting because when you when you hear, like, this is going to be, Or this comes out of Gatsby. It's a part of the Netlify stuff. We can we can get into some of that. But like, you know, you start to wonder is that like, alright, is that The big piece of the acquisition was to have a system like this as part of Netlify system,

or is there is just 1 piece of the puzzle? Yeah. I I always like being, like, extra transparent. It's a little bit of, like, yes and. So, like, definitely, we were required for connect or just Valhalla at that point. That was really the main thing that I think was most saying to Netlify's kinda, like, broader vision, you know, basically, on, like, the way to book for the web. Composable's hard. You know? So we want, like, a more integrated solution with Something like this at the center.

But, certainly, like, Gatsby framework and even, like, the Gatsby team that helped build a lot of the Gatsby cloud innovations, like, That was, like, 1 a, 1 b, you know, of the old product. It was just a strategy. Like, those things are really important, and it's important for me, particularly as, like, cofounder and just someone who loves and uses the framework All the time.

You know, it's important to me that I had a long term home, you know, which Netlify supports alongside, like, other frameworks like Eleventy. I think we're even a sponsor of, like, ASTRO. You know? So it's really important for us to keep those frameworks going,

which Gatsby is certainly one of the top ones that we're prioritizing. Nice. I like that a lot. Yeah. It's it's Going back to the, the GraphQL stuff, it's always tricky to figure out, like, should we build this, like, All encompassing thing where here's how you fetch all of your data and and do mutations and whatnot? Or should we Just put a standard out there and say this is GraphQL. You can use whatever GraphQL thing you want there. So I think it's smart that you guys are Not initially going with some sort of GraphQL based framework out there. You can say you can use whatever you want because there's lots of good options and then kind of Feel it out from there. You mean like our client side framework? Yeah, exactly. Like you could you could use 10 stack query if you wanted. Right? You could use

Apollo.

Apollo. That that's probably the big one a lot of people will reach for it. Or, obviously, if you're in Gatsby, you can use the The Gatsby integrations as well. I was gonna say too, like, yeah, like, Erkle is the one I've reached to a lot from my clinical labs.

But, yeah, I think what's, I think what's, like, really interesting is that, again, we're we're trying to have, like, the right level of opinion, you know, where it's like, this actually is kinda hard, and you should expose a GraphQL API. But, Yeah. Over time, I think that we probably will lean a little bit more into that space, you know, just because, like, that is kind of like a pain point. You know? Like, How do we source it? How do you how do we recommend team source it? But, I think right now, I'm kinda just wanna I wanna see, like, what patterns emerge. You know? Like, what conventions do people source data today, and how can we improve them in the future?

Yeah. One question we had when we had the folks from Sanity on is we Ask them, like, is GraphQL it? Because GraphQL came out and we're like, this is it, it's replacing. Goodbye, Vas. Everything's GraphQL.

And we had that for 5 or 6 years, and now we're starting to see a lot of people say like, let's just write SQL queries before we render our HTML. You know, like it's so such a hard Wing the other way where you go from not from REST to GraphQL, but you go from GraphQL to, like, literally no no API, you know? Like, what are your thoughts on where does GraphQL belong these days? Yeah.

So I think for us, The main problem that we're trying to solve is that sourcing from multiple CMSs, each with, like, a very different API, is extremely challenging and Very, very, very confusing. You know? And so the unification and the standardization and, like, the tooling around the GraphQL ecosystem, like, At launch in Notify connects UI, you know, we just embed, like, a graphical editor. And it's like, this thing is magic. Like, when you can see all your data from Shopify and WordPress and Contentful just working, it's like I feel like a wizard. Right? So for us, GraphQL is a bet that we made early on at Gatsby and, like, want to continue to make.

As far as, like, is that a bet every team wants to make? And, also, the sanity team, I'm sure, has thoughts because I think they, like, invented their own query language called, like, or something. Croc. Yeah.

I don't get any fighting words from them because I respect the sanity team a lot too. But I think that it's good to bet on standards. And so even though there are teams that are kind of, like, Building it themselves or, you know, using some, like, new RPC laying or something. Like, GraphQL is here to stay. It has a team and, like, a community behind it, and I think it solves a very Hard problem well. So for us, GraphQL is, like, a big bet we're making that we made 4, 5 years ago, and we wanna keep betting on.

So, yeah, I mean, maybe over time, we would, like, say, hey. You know, with this connect layer, like, you get a GraphQL API, but you also get this something else, You know, in which you can query more directly without GraphQL, but until shown otherwise, I definitely think we still wanna bet on GraphQL.

Yeah. I think it's one thing that we've heard time and time again is the people who get the most out of GraphQL are the people who who do need to serve to a lot of different places.

But, like, with this, it does seem like it's not just people who serve to a lot of different places, but people people who need a lot of different sources as well In in GraphQL, especially this connect can seem like a nice connection to all of that.

No pun intended. Right? Yeah. Right.

Totally. Speaking of GraphQL clients, you guys remember, GraphQL less? You remember that one that was, like, trying to be the the query less GraphQL client? Yeah. So I I just Googled it because I I know we were Talking about GraphQL clients, and they are working on, like, a v three, and there's, like, a really new website, gqty.dev, gqty.dev.

And they're working on some alpha v v three for this. So I this fell off my radar completely. I just Wanted to throw that out there in case it wasn't on your radar. This is kinda cool. I don't know what their status is, but they're still working on it. I was afraid it just, had Disappeared completely. Yeah. There was this one I remember hearing about, like, GraphQL blade or something too. There was a couple,

in this space for a while that, apparently, are still in this space that are, like, You know, use sorry. I actually have it up my window right now. Scott, it's, like, kinda like write JavaScript on the left, and then behind the scenes that, like, Compiles into the GraphQL query. But, like, you as the developer

don't need to care what you're using. You just write your code. Push pretty cool. The data that you need. Yeah. Yeah. Kinda fits along with the the message of GraphQL and all and all. Yeah. I I wanted to ask,

if you have any other crazy stories either in Gatsby be or in the Netlify Connect area of, like, odd data sources. I know you told us that there was, like, CSV.

I was at a yard sale the other day, and I found a AS 400, like IBM AS 400.

AS AS 400.

And I was like, I posted it, and that's the, like, the green and black screen that you see. Sometimes you go to, like, stores and they're, like, Punching in data. And I posted. I was like, oh, this is a relic. You know? And the amount of people that replied to us, we still use AS 400. I didn't realize that it was, like, still, like, a a major backbone of computing. And the the 1 guy Who works on the, like, TypeScript dev tools for a s 400 was like, hey. I work on testicles.

I blew my mind. I was like, I was just googling it, and there's, like, old JSON TypeScript support for a s 400. Like Oh my god. Unreal. Like so do you have any Stories, and you might not. But, you know, stories weirdest data source Crazy source thing. On?

It's kinda funny because, like, I feel like every other week, Like, we'll get, like, a a customer, and the and and they're always like, oh, we're using the CMS. Like, it's really great. And we're like, well, what is it? And it's like, oh, I don't I also don't wanna name them because I feel like I don't wanna shame that CMS. But it's like it's like I I think that's the main one. It's like, every new week I learn about some new CMS that someone just gloves. And, like, it also sometimes varies based on, like, industry. So for a while, we had, like, some, like, sports customers, like MLB and NBA. And, like, there's even, like, sports focused CMSs that are, like, different than, like, Contentful. And so, mostly, it's just, like, the art of content management is not Like, oh, just go use Sanity or Contentful because what everyone's using. It's like, no. We're using this thing that was designed in our basement by a team of 2, and it just needs to work.

Yeah. I know that, like, the the NHL sites all used, like, the same CMS behind the scenes so that they can all have similar websites, but they're all on different URLs and whatever.

Have you ever had a source from oh, let's do this. Have you ever had a source from PrestaShop?

I don't think I don't think I've heard PrestaShop. Okay. It does not come back. What about Joomla? Yes. Definitely. I've heard of Joomla, and customers have been have used Joomla before. And there might even be a Gatsby source plug in for it.

But yeah. Oh, sure there is. Those are pretty popular still. Yeah. I mean, those are the main ones. Just, like, we we we try to not make like, it's not like we're being judgy, but it's like people come with what have, and they just wanna build a freaking website. You know? Like, that's really what our customers wanna do. And so they're not following the hype cycles, and they're like, oh my god. You're not using Sanity. You're behind. They're just like, just wanna make a website that our dev team can contribute to and our marketing team likes.

Probably like other stories are just, like, The scale requirements that teams come with. You know? And so it's like there's been a lot of horror stories. Like, we had some hard nights building Gatsby Cloud of, like you we had a customer who came in with, like, 5,000, items. And, like, they were in the lead up to launch. We were helping them through it. And then they're like, hey. We just, like, quadrupled everything, and now it doesn't work, and it's falling over. And it's like, well, could you have given us, like, a little bit of a heads up? You know? And help us help you that you're planning on this. So a A lot of what we did on Gatsby Cloud was just, like, helping teams scale the those content sources. You know? So it wasn't just like a 100 page toy. It was like a 100000 page production grade, you know, website that was powered by it was Drupal in that example, but whatever it was. So I like it. And the other way around,

mutations, Because I think a lot of people listening may have last tried Gatsby when it was a static site generator and it was just Pulling data. Right? So what does the story of sending data to an API like that look like?

Yeah. That's a great question. So today, it's a read only clone. So what you get is that GraphQL API, which is, like, kind of like a copy of those n number of content sources that you have. Tomorrow, we do plan for that to be mutatable. We have some, like, pretty exciting stuff brewing that I don't wanna scoop too much, around, like, Making it so that you can edit the website directly, which would then, like, fire up updates to that content source.

So That's a space that we're definitely exploring, as part of the SDK. So mutations and data updating, not just the read only aspect, but, Unfortunately, I can't share much on that, but stay tuned to the space. Check out Connect in the future because that's certainly an area we're aware of and Exploring. That's exciting to hear. I think about

something like Tina CMS, which is like a It's not a CMS. It's a like a UI that sits on top of your website, and then you can hook it up to whatever your updater actually is. I think that's a really cool way to edit your website, especially as we we go a lot more component driven and you wanna be able to tie inputs to their where the data lives.

Definitely. Yeah. I think Tina's I don't know if they still have such a hard tie to, like, markdown, but I I they used to go to, like, every Jamset comp, and I always really thought their I thought their product was really cool because it I mean, the the problem that we see and that I think lots of teams see is that in this, like, decouple, they're, like, composable era, marketers actually feel, like, pretty lost and stranded and, like, Oh my god. I just wanna make an update to the website. Can you help me? You know? And then also, like, developers do not want shoulder tapped.

I'm like, oh, go go fix the bill. Go fix this. Go fix that. Like, just like so I think that's the area that we wanna explore most is, like, enabling Maybe, like, less technical users or, like, people who felt a little more stranded in the composable era.

Help them feel like they can actually add the website confidently. That's Hey. By the way, so Tina is still directly tied to Oh, is it? Markdown. Okay. Yeah. I I this is actually interesting because Wes and I have been looking at a a way of Having real time document editing based on, markdown files in GitHub specifically, we're just kinda tired of Notion.

And,

Looks like Tina does real time. So, Wes, this might actually be an interesting Oh, cool. I believe the Tina folks, they're from, Nova Scotia, I think, on the East Coast of Canada.

I believe I saw they're coming to next week, there's like a little tailwind cough happening here.

So I believe they're coming to that. So maybe I'll I'll tackle 1 of them and ask.

Okay. You are probably one of the best people positioned to ask this question that we get literally every single day is what CMS should people use? And like like you talk about markdown and we always tell people Markdown's good for us, but don't give markdown to your clients. You know, they don't know how to do that. So the second question is like, what?

How do they edit content? You know? Where do you store it? You know, I feel like I should just say, like, it depends, and then, like, I'll just end on that note. Yes. It always does.

No. So I will give, like, an answer. So, like, That was always our goal, being at Gatsby, was, like, we don't really want an opinion. We wanna meet users where they are. You know? So it's like, Would I use WordPress for all of my sites in 2023? No. Absolutely not. You know? But, like, we have lots of customers are, so we're like, we wanna enable them to be successful regardless of what they're using.

I think were I in like a greenfield space, you know, like net new project not tied to anything, I would look at CMSs that were kind of like designed from the start, to be headless. You know? I feel like a lot of the other ones, like, They can be used headlessly with something like Connect. You know, you can, get them working in this new headless era, but, like, they weren't really designed for those use cases and for those, purposes.

So Contentful is my, like, go to. I feel like it it works really well. Like, if I were, like, an agency or something, I feel like I would have, like, a a stack on, like, Contentful and Gatsby and maybe, like, You know, like, Sanity and Next. Js. You know? Or, like, it kinda depends, on what your team's like. Because, like, As an example, Sanity to me skews more developer y. You know? It has the whole, like I think it's like an SDL or, like, some kinda, like, config language that You have to ask a developer to configure, whereas Contentful is very much, like, kinda, like, more marketing friendly, where it's like, oh, go out all these content types, and Here's a visual editor, and, like, it just mostly works. So I think those are 2 safe choices. But, again, like, all caveat and hedge, where it's like, We wanna meet teams where they are. So I was like, keep using what you're using. We don't care at all. And

I think that's the right approach, but, Hopefully, that answers the question. Do you have any quest or any thoughts on a lot of these, like, component based Page builders, we're starting to see.

I know Prismic is gonna launch 1, Builder IO.

Stackbit is hiding pretty hem heavily sorry. What was the one you said? Stackbit. There's another one. Stackbit. Yeah. Where it's, like, component based. You bring your own code. Any thoughts there? I have so many thoughts.

I think it's the future.

I think that is, a space that has legs, I guess, let's say, meaning that I think there's a there there in that space. I think that the opportunity that I see is that there's a huge divide between, like, Let's say pure dev. You know, pure you control everything. You know? Like, you're gonna build every single aspect. You're gonna build your own back end. Could be the serve using surplus functions or whatever, but, like, you're owning that. And then something on, like, the other end of the spectrum that's, like, Webflow and Squarespace, and you're, like, Super, super locked in, and you tend to, I think, outgrow those tools. So for me, what I see as, like, the future is these, like, layers in between. You know, so it's not quite no code, but it's also not no code. There's it's not it's not no code. It's I would say it's low code. And to me, low code is, like, A super exciting space to be in. So to me, it solves the problem that composable kinda introduces where it's like, hey. How do I edit this thing? You know? And, I, as a marketer, wanna be able to, like, make whole new landing pages without talking to a single developer. And to me, that's the That's what I think a lot of teams want. And then, like, importantly, like, then you're not locked into the Webflow and Squarespace space forever. You know, like, you get a website that you can edit and find a different platform, and that is backed by, like, you know, React and GraphQL and whatever other standards that you're using. Yeah. I I agree that's we've been seeing it pop up in a couple of places. It's

it's, I believe, the perfect at least everybody's happy.

You know, the developers can still make their components, but the marketing people don't need to, like, bug them on Slack to update us a single page.

And you kinda have this, like, beautiful

page builder where you can drag and drop your things, but still have full control. And, like, it's not a toy. Right? Like, they're they're actual websites. Yep. To me to me, that's the holy grail. Like, we kind of ran out of time on Gatsby to build that, but that is something that that we saw where it's, like, In place editing, that cascades updates to the content management source, and that, like, looks like the RealPage as it is the RealPage.

That to me is the space that we wanna be in. And because, again, like you said, Wes, it solves problems.

Marketers are happy. Developers are happy. Designers are happy. Like, That's a pretty awesome space to be in. I'm I'm curious when

actually, I did they announce something last week? I got an email from Figma Saying, hey, can you you wanna check this out? We're announcing something next week, and I was like, why would Figma email me? You know, never in my life emailed, but I was like, they're for sure launching some sort of design to code thing, you know? Mhmm. And like, there's It's really interesting. There's all these big players in the space, and I think Figma will probably come out at some point, if not already.

I didn't go to the thing because I was I was traveling, so I can't tell you what it was, but I'm I'm assuming they are gonna launch some sort of design to component, Maybe even a CMS. You know? Yeah. It wasn't,

Framer in that space for a while. It was like a the kinda like design tool that exported, like, React components.

Like Yeah. I've always thought that's like a super exciting space. Yeah. It does seem like there's a a convergence

happening right now of all these tools, but where they choose to connect All kind of seems just a slightly in a different space to, yeah, it'll be interesting to see how it all shakes up and and what ends up becoming that connection.

Maybe a Netlify connection.

Yeah. I'm a know. Stay tuned.

So, Since since we joined Century, Scott hasn't been able to do his sponsorship ad reads or his sponsorship segues Because we don't have sponsors anymore. So Scott is just itching to to make those kind of things.

Yeah.

Making those kind of connections was Killing it. Can we ask you what your thoughts are on React ecosystem right now, specifically around server components and Whatever else you wanna rant about. Yeah.

Yeah. Fragmented and hard and challenging and scary It's kind of where I would say things are at right now, you know, so, like, I think React server components is Very cool and exciting. You know? I see what is going on there, you know, but I also think that tech's kinda, like, cyclical. You know? And we look back at the last 10 years, like, The whole server first idea, kind of like monolithic CMS, like, yeah, it doesn't work, it doesn't scale. It's hard, you know? And so, to kind of like Shift the pendulum back towards that way. I'm, like, a little bit skeptical, you know, because I think that we intentionally did not go server first. And I'm sure if the React team or anyone's listening, they're like, oh, but it's not. It's both. You can go static home. And it's like, yeah. It's true.

But I feel like it's, like, A bigger schism in this space than I think people realize. You know? Like, it's almost like a it's like a hard fork. It exists now in, like, the React space where there was, like, Pre server components and post server components. And if you wanna get on the bandwagon, you kinda gotta, like, upgrade and ensure that your components work in both lands. Like, I think it's hard. I think people, whether it's true or not, kind of analogize it back to, like, the, Angular JS to, like, Angular 2 I was gonna say it. Yeah.

Timeline. Because I was a big part of that. Like, I was the Angular JS technical product manager at Union Pacific. It was my 1st job. And I had to, like, talk to everyone and be like, things are fine. Even though I'm like, no. They're not really. And, like, I don't remember. It's like, think it was so hard because the Angular team bet on, like, Ascript or something, which is like, what the hell is this? Like Mhmm. Whereas, eventually, it became TypeScript. But, like, in those, like, early moments, it was just, Yeah. Super confusing and scary. And I say this all. Like, I think the React team, like, Abramov in particular, is doing, like, bomb job being out there in the community, like, Answering questions, talking through things, building in public. Like, he's doing all the right things and so is the React team, but I still think I would be conflicted if, like, How hard do I wanna bet on this? Like, feels like it's a little bit challenging and, like, such a drastically different model that I don't yet have confidence in it. So I don't wanna give, like, an official stance on server components from the Gatsby team apart from, like

I think it's scary right now is what kinda, where I'm at. It does feel to be like in these big moments, right, where you have a shift and it's like the before and after like you had with Angular or whatever, having that That big shift you're either buying in or you're not gives people an opportunity at that point to say, well, maybe I'm buying into something else Or I'm just gonna stick on the old version. And it's like you have to to make that decision. Now I'm starting something almost new completely if it's if it's that different or, that big of a change. Yeah. Like maybe we should be evaluating what else is out there, whether that be, you know, hydration less framework like quick Or solid compiled frameworks or anything like that. You now are like, well, should I be evaluating everything? That's why a lot of people went to react at that point. I went to React at that point. I was at Angular

All 3 of us. 1, 3, whatever. Yeah. Yeah. I was gonna say, like, the whole single page app crowd. You know? It's, like, a really interesting thing because, like, I kinda talked earlier on, like, hype cycles and how it's like what you see on Twitter is not what teams sometimes are, like, actually struggling with. You know? And, like, there's a whole cohort. I don't know how much percentage of React, but I would bet a decent chunk of React apps out there are just single page apps, you know, using create React app or Veatch or something. And, like, that's not really super well supported in the React server components world. And so it's like I think it's good because, like, clearly, React is is aware of, like, a performance issue, and, like, those apps don't perform very well. But it's almost like saying, we don't want those apps. You know? Those apps should be built with something different. And I don't know what something different is exactly, you know, in that scenario. Like, who's building the enterprise goopy type, sites that don't need server components and that Just need to be used for, like, an internal dashboard.

I don't know. I thought React was great for that, but,

maybe not. Yeah. We had, At Reactathon, there was, like, a panel, and Tanner Lindsley, who's the author of all the amazing, like, Rat Query and Not even Rakwir.

They're all agnostic now. And there's adapters for all the different frameworks. And so he runs Nozzle, which is a big, Massive single page application, very data heavy for doing things like search engine and whatnot. And he's like, I don't see the benefit to my business in doing server components because it doesn't need to be.

And I just don't know, like, what the upgrade path looks like. And he was saying the same thing. It's like, is this another Angular moment where people are just like, This is gonna be a big move. First of all, the only way to use it right now is with next, I believe.

So Is it one of those moments where you just, like, kinda say, oh, maybe you just move to Svelte instead? And, obviously, that would probably be a bigger A bigger move, but a lot of people are saying, well, while we're here, does it make sense to just look at something else? But even, like, solid west JSX based Yeah. Your rate templates would still transfer totally fine to anyone that uses JSX.

Yeah. Yeah. Like, yeah. Maybe that's a time in which you would Solve some of your other nagging issues with React that, you know Yeah. Have come up over the years. Yeah. It's basically like if teams are, like, even somewhat unhappy with their current solution, like The facing the monumental kinda like upgrade. Although, I do think I haven't done a upgrade myself of, like, you know, let's say, Or the React app to, like, a React server components based model. Like, I genuinely don't know how hard it is, but I think it'd be kind of daunting. And I think that If they're, like, not a plus thrilled, they'll be like, okay. Well, I might as well just rewrite anyways. You know, let's do something less complex, and that seems a little bit less intimidating.

Yeah. That's a super good point. I I'm very curious if anyone listening is kinda going through this right now. And, also, I guess, that's what I was gonna say, is that, like, You can just sit on your hands for a year and see how this all pans out. Totally. Obviously, that's what that's what Remix and Gatsby We are doing right now, you know, like, I'm assuming they are. Like they say, yeah. Like, it's not that we're not gonna support them, but we're not sure Yeah. We're not sure what that looks like, so maybe just sit on your hands and see how it all pans out. I do think I think I saw one of the remakes.

I don't remember if it was Ryan or Michael, said we're gonna explore React Server Components, like, recently. So I think they are investigating it.

We launched SB 5 in, like, November, and we supported React server components, but, like, the use client and use server convention, it doesn't it's not a full implementation of, like, Server first using SSR, you know, that the Next. Js, framework has. So it's like we support it for the bundle size reductions, which I think is super Interesting. Like, to me, that's one of the cooler things over React server components is how it can let you basically build more performing apps to load less JavaScript, from the

1st launch. Awesome. Actually, can you explain that a little bit more? How does that work? Is that if a component doesn't need to rerender client side, it doesn't send

Everything over that it needs? It's basically yeah. It's like, you know, I should I should know more on this. But I think it's basically it's like it's not sending, like, everything over the wire and components that are purely static that don't need to be, like, hydrated. Mhmm. I think that's kinda where the, like, use server convention, kinda, like, kicks in. You know? And then if it's like this is, like, an element of, like, dynamism on your web app, like, then you would use the use client convention. And that that's basically telling the React come by all there, like, hey.

Keep this thing warm. You know, it's gonna need updates.

I guess with that said, like, what does the future of Gatsby

look like, you know, given that, there are there are, you know, is continued development in movement. What what is What are some of the things y'all have planned there that you could get into or not? Question. So like I like I mentioned, like, I don't want to make some, like, Big mandate and say we're not betting on server components because that just for, like, the Twitter drama. Like, that's not at all what I what I wanna say. Deep camp. But I wanna give it a little bit more time to bake, you know, which is also kinda like what the formerly Gatsby team, who helped build the framework, is thinking.

We definitely plan for Gatsby to be the framework that supports Connect best, you know, the composable, pluggable, integratable, framework, you know, with Any number of CMSs.

And then I really want us to continue to lean into, like, the performance angle. You know? So I I care deeply about performance. I know a lot of Users and customers do too. And Gatsby scores, like, 10, 20 points higher than, like, most other frameworks. Not Astro. Astro beats us a little bit in some regards because they're, like, literally doing, Like, no JavaScript, but so that to me is, like, meet teams where they are, help them build if they're using a a content management system and they wanna be in the React ecosystem.

And that gets you very, very, very good performance without needing to be a performance expert. So it's kinda doubling down on what we've already been doing, you know, and then, like, deepening the focus on Connect That was kind of, like, the center,

of the Gatsby ecosystem. Do you have any thoughts on web components in this space?

Oh, man. I don't wanna get, like, I don't wanna get canceled on Twitter if you're not liking web components.

No. That's alright. I I mean, I'm more or less even, like, you know, like, how how do they work in the context of even, like, a a a system like Gatsby. Right?

I think that Web components are they have such huge advocates for them, and I think that, like, they can't all be wrong, you know? But, like, I've used web components. I use that component as too early. So I use polymer. And I'm like Likewise. Yeah. Oh my god. I don't like this at all.

And I'm like, please, please let me use React, please.

But I think I I see a lot of teams building this way, and I think it's useful to explore it this way. Whereas, like, web components are kind of like a future proofed way to, like, Build a component library or design system or something that isn't tied to React or Angular or Vue or whatever, you know, framework of the future, And then providing little layers on top, you know, that then, like, make it work in, like, a framework manner. So I I see that being a really useful use case for web components.

I can only say my personal anecdotal experience is I've found web components hard, and I tend to lean on a framework to help me

Build what I need. Yeah, I'll wait.

Let's move into the next section, which is our supper club Questions. These are a set of questions that we have for everyone who comes on. The first one we have here is what computer mouse and keyboard are you using? Oh,

Oh, that's a great question. I can hear the kitty clack, so I Yes. I think I have a w a WASD keyboard, mechanical keyboard. It's very solid.

I wish I was more of a keyboard nerd. I can't remember which switches I have, but they're, like, silent 2 switches.

I just use the Apple trackpad. I think it's great, and I use a tool called BetterTouchTool.

I don't know if anyone's heard of it before on Mac. I'm like fan. I'm like a massive Yeah. BetterTouchTool fan. Me too.

So, yeah, I use that and got a lot of gestures, you know? So, yeah, that's my kind of setup. So do you have, like, custom

Custom gestures that better touch tool will recognize,

and then you have like, what kind of things do you have set up? So many. Most most of it's like web browsing. So it's like fingers swipe down, closes the tab. Three fingers swipe up, opens a new tab. There's a gesture called tip tap that I love and better touch tool. I'm, like, nerding out on this stuff. Oh, I wanna hear more of it. Yeah. It's, I should share my, like, better touch tool shortcuts or something. But, if you do, like, your left finger, in place and then your right finger tapped to the right of it, That's like a tip tap right, and that goes to the tab to your right. You know? And then inverses tab to your left. Oh, I do. Forefinger press for quit. You know? So I wanna, like, quit an application. It's like I you know? So, yeah, there's a a bunch of shortcuts I use, but those are the ones that come to mind immediately. Do you come up with them? Do you, do

you find Yeah. Like Years of, like,

using trackpads and being frustrated by, like, limitations. And then actually kinda funny. Like, I just wrote a new, like, dot files, repo. I don't know if y'all do that. Like, a new machine. And so I've been, like, really exploring this and, like, how do I make it seamless? So it's, like, Years of being frustrated by not having enough gestures and then always adding them to my new machine and then sometimes even changing them over time. Sorry. I was just gonna say, I I've been a major BetterTouch tool user for

probably 6 or 7 years now, and I've never done the trackpad stuff on it because I I just use a mouse at my desk. And Now I'm I'm curious. Maybe I should give it a shot because I I use it so heavily in all the other

aspects. Isn't it kinda cool too? Like, I because, like, I just was getting my license yesterday because I got a new machine. I think their test tool is built by, like, 1 guy. Yeah. You know? And he probably he probably doesn't get a lot of, Shout outs for, like, hey, your tool's amazing. Like, I don't know his name, but his tool's amazing.

Yeah. Like Hazel? Hazel is another one of those just built by 1 person. Yeah. Yeah. The guy is unreal. And his name is an Andreas

Hedgenberg.

And he like he's been doing it for probably 10 years. And any time I post in the forums, he's there in like like 3 minutes, like 10 years in. And you're not Sick of this. And there's just and there's there's he's the only person going deep on, like, these obscure macOS issues.

You know, like

How he does it is is beyond me. There's something beautiful about the, like, indie creator space on, like, Mac in particular, I think, where it's like Yeah. Just people who care,

is Underrated, and definitely BetterTouch tool is one of those tools. Maybe we should try to have him on. That'd be interesting. Didn't realize there was a better snap tool. Yeah. There's that one too. As part of BetterTouch tool, I think he just like took it out and and made it into Oh, really? Like a window manager. Because like it's just 1 tiny part of better touch tools, a window manager. It's Unbelievable.

Yeah. Keyboard cleaning tool. Oh, that's fun. I'm just looking through all of his software. What, what text editor theme and font do you use?

I'm Versus code. I tried hard to keep on Sublime Text because I loved it for so many years. And, like, Versus code, like, the ecosystem and the plug ins are just Hard to beat, and, like, the TypeScript support has just been amazing.

I think I'm using, like, Dracula Pro or something.

My buddy is Zeno Rocha.

I think he's the creator of it. Now he's at a new new company called Resend. I think he built that theme, and it's the best theme. I also there's a font I use too. I think it's, like, Dank Mono. It was from Yeah.

Phil from Formidable. He used to be at Formidable. I don't know where he's at now, but, That's my editor stack.

Which terminal and shell are you using? I just use terminal. I've tried so many, like, tools like iTerm, and I used Hyper for a while.

Okay.

Terminal's my go to, and then the the shall I use is z a ZSH. I I think I actually use, like, all my ZSH. Yeah. I just I just shared my dot files repo because I just created it. It's got all Do that. It's got all that stuff. It's GitHub.com/dshauforward/dot

files. What, if you had to start coding from scratch today, like, anything, what where would you go? Web, Not web native anything? I mean, I

I would bet on React, and I'd bet on the web. So I feel like that's gotten me pretty far, and it's Still very much, like, a good standard.

What else? I mean, what am I building In this scenario, like, am I building, like, a full stack app? Like

Whatever you want. Like, what what would interest you to even

Yeah. Well, I mean, I'll just show you something. Like, I've been building some stuff. So I have a little home theater PC. That's my that's the area in which I like because I don't code as much being a director as I used to, but I still caught on the weekends and, you know, have a little fun. And, I used a tool called Fly. Io, which is pretty solid.

It's kinda like render, which I think you got you all covered a couple weeks ago.

But, Sorry. You said it's fly dot I o? Fly dot I o. Oh, yeah. Yeah. We covered them as well. Nice. So, yeah, I I thought that was really seamless. Mostly, I did that. I mean, obviously, not if I can be used for some of these too, but it's like, I love using other tools just to see, like Oh, yeah. What's cool and hot and what's new. Right? And so that was a really good experience. And, like, I just use Express. Like, sometimes I think that tools that last and that have scaled to so many different Objects are, like Mhmm. So amazing and worth betting on. Like, I don't know if you all saw the the Figma team launched their, like they did, like, some, like, new database deep dive, and it's like They were just using Postgres, in, like, a single instance for, like, 10 years or something, and it's like, yeah. That's a pretty good stack.

You know? So Yeah. Big one can do it. That app probably is dealing with a massive amounts of

data. So I would keep it simple. So, yeah, Postgres, Simple way to, like, host a back end with, like, Express. Yeah. Edge functions are super cool, but, like, for a lot of the apps that I need, you know, I'm not building for enterprises. I'm building for my own use cases. I don't really need edge functions. You know, the the user of my application is me. So,

So, yeah, that's kind of my stack. I like it. I have recently started using, Hano JS, because it's it's very similar to it feels a lot like like express because that's that's mine mine as well. Right? But it adapts to literally everything. This would work with Notify too because it, Works on Deno, which is what Edge Functions use. So yeah. That's exactly why I picked it. It's like I so I deployed a website to Deno Edge functions on Netlify a couple of months ago just so I could say I did.

And I was like, this is great. And like I did a whole talk on like Using standards, right, the request and response and fetch and all that stuff. And part of that is that's great, but I also still want the express Kind of feel. And Hano JS has like a node adapter, so you can just run it locally. You can spin up a quick server really quickly. I've been a big fan of that. What what are you using for your home theater setup, if you don't mind me asking?

Yeah.

It's kinda one of those things where I wanna set it and forget it. So it's, Ubuntu on, like, an Intel NUC From, like, 10 years ago, still works.

I I had to upgrade.

This is recorded.

I recently downloaded a home movie, that's Next distributions.

Yeah. That that, actually, like, Oversaturated my hard drive, so I had to buy a little, like, 256 gigabyte, just, like, tiny little solid state drive that, I made it so that it downloads there first.

So, yeah, it's just an Ubuntu stack. And then, like, a really great tool that I've used in the the home movies game is, obviously, Plex. But There's, like, a a number of, like, really amazing utilities like radar and sonar and, couch potato's okay, but not as good. So those are for, You know, downloading and managing, like, your home movies. Linux.

Distributions. Yeah. Linux distributions.

Yeah. We've been I've been on Embi for a bit, but I do wonder about I tried Embi, and I didn't like it as much as Plex. I don't really love it. Yeah. Yeah. Yeah. I switched To I was on MB for probably,