Software Huddle - Jamstack and Composable Web Architecture with Brian Rinaldi

Episode Date: May 28, 2024

Today we have Brian Rinaldi from LaunchDarkly on the show. This is the final episode of our in person coverage at the SHIFT Conference in Miami. And although Brian works at LaunchDarkly, we actually didn't talk at all about his employer and instead chatted about Jamstack. Brian has a long history with Jamstack, has written a lot about it. Jamstack was popularized and created by Netlify. And there's been a lot of history of controversy with the term. Some people think of it's merely a branding ploy or a marketing thing, and others find it simply confusing because we have terms like LAMP stack, MEAN stack and MERN stack. So Jamstack automatically gets lumped in with those, but it's not actually a technology stack. It's an architectural pattern. Recently, Jamstack has been giving away to what is known as composable frontends and we picked Brian's brain on this and what this means not only for Jamstack, but also the future web development.

Hey there, Sean here. Today we have Brian Rinaldi from Watch Darkly on the show. This is the final episode of our in-person coverage at the Shift Conference in Miami. And although Brian works at Watch Darkly, we actually didn't talk at all about his employer and instead chatted about Jamstack. Brian has a long history with Jamstack, has written a lot about it. And Jamstack was popularized and created by Netlify. And there's been a lot of history of controversy with the term. Some people think of it as merely a branding ploy or a marketing thing. And others find it simply confusing because we have terms like LAMP stack and MEAN stack and MERN stack.

So Jamstack automatically gets lumped in with those. But it's not actually a technology stack. It's an architectural pattern. Recently, Jamstack has been giving away to what is known as composable front ends. And we pick Brian's brain on this and what this means, not only for Jamstack, but also the future web development. All right. So before I get you over the show, last thing, if you have any thoughts, suggestions, or feedback for the show, feel free to reach out to me or Alex. And with that said, let's get you over to our conversation with Brian. Brian, welcome to Software Huddle. Thanks. Glad to be here. Yeah, thanks for joining

us here at InfoBip Shift, where you're speaking, I guess, in a few hours. Do you want to give a little bit of background about essentially who you are, what do you do, and also some of the stuff that you might be talking about today at the conference? Sure. So my name is Brian Rinaldi. I'm a developer experience engineer at LaunchDarkly. I work on obviously everything related to feature management, feature flags, all that kind of stuff. I write about it, speak about it. Here at Shift, I'm talking about something that's kind of unrelated to LaunchDarkly. I mean, obviously you can use LaunchDarkly in anything, but this is not necessarily a talk about feature flagging or anything like that.

This is about something that I've been interested in for a long time, which is building sites using this kind of JAMstack methodology and serverless and composable backend architecture and things like that. So that's what I'll be talking about today yeah and i know uh you know i've read some of your blog posts it's been something like you've written about like kind of outside unnecessarily your day job but just really you're interested so how far back does that like history relationship with jamstack go oh god it goes i mean i was talking about it last night because matt billman uh ceo of netlify is here and he and I was talking about it last night because Matt Billman, CEO of Netlify, is here.

And he and I were talking about when we met. And I was actually speaking at an event. This must have been like at least 2013. We were figuring it's about a decade ago. Because he hadn't even launched Netlify yet. It was still like in a private beta. And he and Chris Bach, the co-founder, they came up and were like, oh, you know, after my talk, because it was all about like,

I mean, there was no Jamstack. He invented the word years later. But this was all about like static site generators and Jekyll and the popular ones back then were like Jekyll, Middleman, and Hugo were really big and popular. And I was already out there talking about it. I just kind of became fascinated in a way that like, okay, it started with a project at work, as often these things do,

where they wanted me to build a site and they wanted me to use WordPress. And I'm like, I don't want to use WordPress for various reasons. It's a good tool, but back then, I mean, database connection errors were frequent. And if you got a sudden burst of traffic, suddenly your site's going down and things like that. And so I had become fascinated with Jekyll. sudden burst of traffic, suddenly your site's going down and things like that. And so I had become fascinated with Jekyll. And I was like, can't we just do this in Jekyll?

I mean, it's just content. There's nothing interactive here. And they said no. And thus started my endless, I was like, no, I'm going to prove that this is something like worth doing and I started writing about it and I started speaking about it and that's kind of like from there on it I mean I've kind of always had a fascination with that way of building websites because it felt like it took me back to when I started because I've been developer for like over 25 years and it took me a little

bit back to like the roots of like the simplicity of building for the web back when I started versus I mean. All the complexity now. Yeah. It's a little bit complex now, right? Yeah. Well, we've gone through these different eras when in like web development, right? Where 20 years ago it was pretty simple.

Like you had sort of like a html front end everything was like a server request to do something dynamic it was uh and it was slow but it was easy to understand you had you know clear separation between front end back end and then there was a period where we kind of like tried to stuff everything into the front end at one point and then we kind of had periods where we were doing we were we had some stuff that did stuff on the back end and front end and a lot of times it was like like a copy like your back end was essentially sending like html your front end and we've been slowly trying to like improve it over time while balancing the developer experience and user experience the whole

time but we kind of like keep adding complexity along the way yeah definitely has gotten more complex and you know here i thought server-side rendering was invented like two years ago what We kind of keep adding complexity along the way. Yeah, definitely has gotten more complex. Here I thought server-side rendering was invented like two years ago. What are you talking about? Yeah, that's how React invented that. Right, back then it was easy. Everything was a server request. Funny enough, we're kind of headed back in that direction, right?

I mean, a lot of the newer frameworks are kind of like, you know what? Maybe that wasn't so bad. It's not identical to the way we did it 20-some odd years ago, obviously. Like, we're now sending a lot more things in structured kind of data formats and things like that. And then using that to render. It's still now we're moving a lot more of it to the server.

I mean, if you've been in this industry a while, like, any kind of area you focus on, you notice it shifts back. It is interesting. Or as technology changes. I mean, like, you know, when I started, it was all on the server. But, you know, the server was slow. So, like, we started moving things to the client, which is even like if you think about it back then,

Flash and Flex, which I used to do, moved a lot of the business logic to the front end. But then we got rid of Flash and Flex, and we moved it all back to the back end again, and then we started moving it again to the front end and doing client-side rendering and all this kind of stuff. And now we're like, wait, that's not working out so well, so let's move it all to the back end again. It's just back and forth i think we go through these extremes right like fully server is probably not ideal because you don't want to have to refresh the entire page

every time someone like clicks on a like button or a thumbs up button or something like that so then you start sprinkling in some client-side code that can do something dynamic to hit the hit the back end and pull that data in but then then someone was like, well, that's good. What if we did everything in a single page app that like everything is essentially, you know, dynamically rendered? And then it's like, okay, well, we've gone too extreme to that. And then it's like a reverse back to the server side. And probably like the ideal is really some sort of balance in between, right?

Yeah, I definitely think so i like i'm a big fan of this islands architecture idea where it's like okay um i can kind of even do mix in some static like pre-rendering right where but the components on the page that need dynamic pieces can be hydrated like in like a either client side or server side rendered or things like that like so you kind of mix and match those different ways of building things but which sounds complex but then actually when you're trying to build it it really isn't that isn't that complex it works like frameworks like astro for instance really make it easy to do that yeah um and we're starting to think of our apps of our pages in terms of components anyway, so then you can sort of break it down and like, hey, some of these are static and not changing, and

some are more dynamic and need some more functionality. Exactly. If you think about it, if you look at a lot of web pages, the amount of dynamic pieces that are on there, when you start cataloging it, outside of like, say, hey, here's the admin for the tool, obviously there's a lot of dynamic things going on there, but you have tons of parts of the site that, okay, we just through Reacted this for what? For showing our documentation?

I mean, really, do we need that? Maybe there are pieces like, oh, hey, you can add a comment to the documentation, star, rate the documentation, just using docs as an example, right? But those pieces need some kind of client-side functionality. But the content, I mean, that's static, right? Like, why would I have to do any kind of client-side rendering? Or even, for that matter, maybe not even server-side rendering. Maybe I just push that piece up as static, or I server render it. But the point is, it's like, I don't have to necessarily do all the client-side rendering for those content pieces,

which is what we were doing for a little while. We were, like, throwing React at everything and saying, like, hey, you know, even, I, even if you think about Gatsby, that was the whole, I mean, you were static rendering, but then we were still hydrating and throwing React at a statically rendered page. It's like, hmm, you know. I don't know that that was the right solution to the problem. Obviously, we've kind of, you can see we've evolved in towards that like saying like, okay, maybe that wasn't the best solution for the problem. Yeah.

Well, with Jamstack, like I feel like if you look at some of the history there, there's always been this like controversy around like, is it sort of just like a branding marketing play versus something that's like net new i mean what are your thoughts on that and what was it that jamstack did bring new or maybe it didn't bring anything necessarily like a new opinion on how this should be done so i mean none of the stuff was new it just was a the terminology was new uh you know and i talk about this i'm going to talk about this this afternoon which is basically like i mean the term was a bit of branding because, I mean, static sounds old. Static sounds like, well, how am I going to solve, I can't, my page is not static. Like, there's things going on that are interactive. Like, that's not static. I can't do that static.

But at the time, when I was out there speaking, like when I met Matt in whatever, 2013 or whatever it was, right? You know, that's what we were calling it. Static site, you know, static sites and static site generation. And even though the end result wasn't necessarily static because we put some client-side JavaScript on there and, you know, maybe call some external APIs and things like that to get more data that is actually loaded at runtime or whatever. But we'd still call it a static page. I think Matt and Chris, they obviously were trying to build a business off of this and

it's hard to sell companies on static sites, right? And so I think that's where the term came around. It was like, can we reframe this stuff we're already doing, but in a way that doesn't emphasize, that doesn't sound old-fashioned. It gives it like a new way of thinking about it. So yes, it was a marketing term, but also, I mean, I think it was effective. And described some real shift in some sense. Also, we wouldn't probably be talking about it if it was called like static sites, you know, like basically like 12, 13 years later. Now, speaking of, you know, Matt and Chris and

Netlify, they recently, like last year, like stopped, killed off the the community for jamstack so i guess like what does that mean for the future of jamstack is is it is that a sign essentially that we're moving on from that to something new um you know i i kind of got myself in a little trouble because when they did kill that discord community i wrote a post that kind of everybody took as me saying jamstack was dead and considering I've been writing about it and like talking about it for so long, it suddenly became like, you know, okay, if he says it's dead, it must be dead.

And I'm like, no, I didn't say it was dead. I mean, like the thing is, it had become a fuzzy term. Yeah. It had become kind of, you know, vague in terms of what it represented. It was now server-side rendering and edge rendering and serverless. have become kind of vague in terms of what it represented. It was now server-side rendering and edge rendering and serverless. I mean, it was essentially an umbrella term covering a lot of different things.

Which just tends to happen with terms like serverless. We're seeing the same thing where everything is being called serverless. Exactly. I talk about that a little bit as well. As technology is mature, they tend to kind of, things kind of grab onto it, and the term expands because we start drilling into something, and it becomes a bit more than it was when we originally envisioned it.

And it gets more complicated, and the term gets fuzzier, but it doesn't render it meaningless. I mean, you still know what serverless more or less means I mean I have a general idea of what that means and I know what Jamstack means and people are still building using kind of a con you know conceptually Jamstack even though we've broadened the term maybe a little bit I understand some of the kind of core principles of it but the terms kind of core principles of it, but the terms kind of fall out of favor. I mean without the community, even at the time I was

calling it, I was saying, hey it's more of a community than it is an actual stack because it was never really a stack. I mean JavaScript, APIs, and markup and like yeah your PHP uses JavaScript, APIs, and markup right? So like it's not really a stack, it was you know more of, right? So it's not really a stack. It was more of a methodology, and then it became more of like, okay, well, it's an umbrella for all of these things, and we can kind of say,

oh, if I go to a Jamstack conference or I'm reading a Jamstack book, I kind of know it's going to cover all these things in this umbrella, right? And if those things kind of suit me, then, hey, that's the right place for me to be. That's my community, right? But then they killed the community, and it was like the term has kind of lost some of its favor since then, even though we're still doing things the similar kind of ways.

Yeah, I think some of the confusion is because they actually called it a stack yeah so then you immediately associate it with like mean stack burn stack lamp stack like all these types of things which are actually like a collection of technologies that you're putting together to solve or like build build web applications whereas jamstack like you said is essentially a methodology yeah yeah I mean even when they redefined it I think it was like 2022 they redefined it officially and made it broader and fuzzier and a lot of people complained it just kind of matched where Netlify was going are you sure people on the internet complain I don't know I haven't posted on Twitter in

forever now so like I don't even. I haven't posted on Twitter in forever now, so I'm not seeing the complaints anymore. Now with Astro and some of these other tools that are out there, we're moving towards these composable front-ends. Can you talk

a little bit about what is the shift that composable is bringing, or what problem is that solving? I think the thing to understand about composable versus jamstack is jamstack is very focused on how you build your actual website and it's about it's about building web applications right so like so you know you're talking about like the you know the tools you'd use like an astro or an xjs or whatever you're talking about like okay you'd use, like an Astro or an XJS or whatever. You're talking about, okay, we're going to use serverless and all those pieces. And composable is really about the back end piece.

It's not concerned, actually it doesn't even, composable doesn't necessarily just apply to a web application. It could be just how I architect, kind of combining all of the back end pieces. Like, oh, okay, commerce is like, e-commerce apps are usually a common example because how, you know, you have your payment APIs and your, you know, your product database and your inventory and all these other pieces like that you're trying to bring in all these different pieces and the way we'd have to have built that is you'd build like a back end for your front end, the kind of Bff pattern where it's like okay now i'm combining

all these different apis and doing all this complex logic like where it's like okay get the customer things from here and then go out to the inventory or the order system and see what orders they have and then you know so like you're weaving all these apis together and the composable architecture kind of says like okay we're going to kind of create some consolidated way of communicating with all these apis where we don't have to necessarily um you know kind of do that by hand each time right so so like if you look at some of the platforms like even netlify's as an example they kind of bring all of these APIs together into a single consolidated

way to interact with them, and then you build reusable components that the components are more back-end than they are focused on front-end, where I can more easily reuse pieces, microservices, and things like that to communicate with all that back-end.

Are you saying reuse even across companies? Like there would be component frameworks and stuff for the front end? Or more just within your company, I can reuse this component in different areas? Yeah, I think it's more within the company. This is not like reusable UI components. I think there is a composable UI and whatever his company makes. But this is more really about how you access the data pieces. So how you combine all those different ways that you're getting data into something that is reusable across different pieces of your mobile app and your you know your um you know your web app or whatever

other pieces you might have to build that are all kind of using leveraging this data right um but i can now more easily access it and this as opposed to like kind of constantly reinventing the wheel and trying to weave all these pieces together um yeah so like what was the sort of motivator for moving in that direction? Was this something that... and who initiated sort of this approach? Is that something that also came out of Netlify or is it... No, I think Netlify jumped onto it. They've helped kind of broaden the term in terms of like, you know, within the web development community specifically. I mean, if you look, there's something called the Mock Alliance,

which has been around for a while. And the Mock Alliance, one of the, like, it's more of like, it's a little more prescriptive in terms of like how you, you know, the mock concept of building web apps, but composability was always a core tenet of that, like using a composable kind of back-end architecture. And I think that's the C in mock, actually.

And that's been around for a while. They've been around for years. And Netlify was a member of that, but they're not the only ones. I mean, there are other companies, even I worked for one for a little while, that were trying to work on ways to use GraphQL to kind of be that front-end layer, the glue that brings all these APIs together.

And there's lots of solutions that have been around trying to do that for a while. So it's been there. It's just, I think now suddenly like as more companies and bigger companies and well-known companies like Netlify kind of jump onto that, you're getting more marketing and buzz around it. And so people are becoming more familiar with the concept. Yeah. What are you thinking about the front end ecosystem right now? Like it seemed like for a while there was a little bit of a lull where it was mostly React and

Vue and now we've got the React meta frameworks and things like that. We've got Astro, which you mentioned, and Solid and now even like HTMX and stuff like that. How are you feeling about front end development as it is right now? I complain a lot about it. Yeah. But I will say, like, okay, I'll out myself that I was never a React fan. I was always a reluctant React user. I kind of got dragged along because, well, you really couldn't avoid it, honestly. And so I built a lot of things with Next in particular.

But, like, I didn't, I found that it was just kind of a unintuitive way for me like I didn't like building apps that way. That's how I felt about Angular was I had a hard time I mean I could do it but like I don't know like the framework didn't align

I think with that well and it didn't feel natural to me whereas actually React felt for whatever reason, more natural than something like Angular. Are you a front-end developer naturally? Is that sort of where you would categorize yourself? Yeah. I mean, I've been doing

front-end stuff for focused almost exclusively for the past decade. Front-end being might include serverless stuff, that kind of full stack. I'm not a huge fan

of that term either, but, you know. Was anybody truly full stack at this point? Yeah, I'm kidding with all the stuff there is. But I would say same thing as you.

React seems more understandable to me for front end stuff, but I consider myself as more of a back end developer that can fake a little bit of front end. I feel like React is easier

for those folks, but the true front end people that actually understand how a browser works, how HTML and CSS work, I feel like have more frustration with. Yeah, you know, and I kept I think it was I don't know that there was a particular framework that I loved

of the single page application type framework. I've come to really like Astro because I can, I know enough React now I can throw in React components and like, hey, that's easy. And I feel like it gives you a really great way to kind of, I think one of the difficulties has been that people who built their whole ecosystem on React and Next.js in particular, making a transition to something else is really difficult. Because are you telling me I've got to toss all this away and I can't reuse any of that?

At least Astro gives you a way to, okay, I can piecemeal my way to like stop using, you know, Next as like the solution for every single piece of the app. I can still use React components and bring some of the ones I've already built over and maybe, you know, transition my app to like something that has, that uses a lot less JavaScript that, you know, is going to be more performant and things like that. So I'm like actually really hopeful, not just of Astro, but there's tools like Enhance is another one that's trying to do that. I feel like there's a bunch of different tools that are out there that are kind of pushing things forward in a direction that I like

and I think is going to help. So I'm hopeful. It's not like there's fewer frameworks, but I also feel like we have been narrowing down. I mean, you can use whatever you want, but I think if you look at what people are talking about, what they're using, it's either like Svelte, SvelteKit has kind of gained

some prominence and then and then still next js is like you know massive yeah and then but then you see like kind of a lot of people moving towards like i think astro has really garnered the the kind of most attention because just because they seem to be doing in a way that that i i think it's because it's doing in a way that allows people to kind of make that transition without kind of giving up on everything they knew before yeah not starting over yeah so you think there's some consolidation happening or like i think stabilization so i think like i'm curious to your opinion on this like there's been so many you know there's lots of jokes of course, about like how, you know, how many JavaScript frameworks there are.

And there's a new one all the time, but like, are, you know, is it that people are like perpetually unhappy if they're like, you know, work on web applications or front end engineer, or does that speak to maybe more of like a fundamental flaw with how like the web works like is there what from like if we could go back and basically re-architect or redesign HTTP and the sort of underlying protocols of the web like would we have gone in a different direction knowing what we know now because when that stuff was done like you know you know 30 plus years ago like I don't think people like had the vision of where we are now, where you're

running essentially full scale. You can essentially run Figma's Photoshop and beyond running on a web browser. Yeah, but that's the amazing thing to me about the web. It's like, hey, we built this thing 30 some odd years ago, maybe no more, right? Now 50, I don't know. Yeah, I don't know't know. Yeah, yeah. So like, you know, yeah. And here, you know, if you think about it, right,

like you're running that full application, which we would have had to build like a, you know, a desktop application back in the day, right? And now you're running that in the web and actually it's doing things that those desktop applications couldn't even do back then, right? Like it's pretty impressive all the things it can do.

It feels very interactive. It feels like an application. And yet the same web still supports everything you built back in like the 2000s, right? That like those pages are still running and they don't break. And so like, you know, that to me is the beauty of it. Hey, it's flexible enough.

It's going to support that stuff. And maybe we wouldn't have built it that way if we did it today. But at the same time then, if we were to redo it now, I mean trying to redo it and maintain that compatibility with everything we've done before, to me that's a key part of the web is that we have maintained that history. This stuff still works. Yeah, I mean, I think that's the unique thing about the web versus pure desktop

or maybe even pure basically stuff that's running at the operating system level. You'd have built a website in the 90s that still should be able to run and render today. Right, as long as it doesn't have Flash, right? Well, there was even somebody trying to, they were building some things to allow some of those old Flash games to still work. Yeah, I invested too much,

there was a period of time in my early career where I invested too much time in Flash. It was an action script. Oh, yeah, that's how I got my job at Adobe. too much there was a period of time in my early career where I invested too much time in Flash and ActionScript oh yeah that's how I got my job at Adobe I was I mean my first

kind of DevRel job was I was Flash and Flex community person at Adobe basically

so yeah I think I invested more yeah definitely I had a I had a whole career built around it. And then one day Adobe says to me,

they're like, okay, as of tomorrow, you're basically all focused on front-end stuff, not doing any Flash. You're going to do JavaScript and CSS and whatever. I'd done before, but it had been a while i had really gone all in on those tools yeah yeah that's wow yeah yeah you mentioned behance it made me think of uh just web components where do you think web components are and like are they ever going to take off like where are we at with those i mean i feel like they are right they are kind of like

we're finally reaching that point where like more frameworks are just kind of putting that as a core tenant. I think from a client-side standpoint, I think web components are here. They're part of things you're probably using already in your stack. But I think from the one that's enhanced is doing something slightly different, which I think is a little bit more cutting edge. And there are a handful of frameworks that are trying to do server rendered web components, which is where it gets a little more complicated. And I think those are still maybe not, that's not quite there yet from like a, hey, widespread

adoption thing, but I think frameworks like that are kind of pushing that. It was even in the ThoughtWorks radar or whatever, that that was one of the ones emerging things to look at was SSR on the server, sorry, web components on the server. And so I think it is gonna be there. But that, to me, already assumes, like we've accepted it from a front-end standpoint. It's already there.

It's there. And I think largely you're seeing it kind of become a part of more tooling that just says, by default, we're using web components. Like Eleventy is, for instance, bought in on the web components for front-end stuff, like big time. What's the advantage of running

or having the web component server-side? You know, I haven't used it much, so I'm not exactly sure I will articulate this well, but essentially, I know Enhance's idea is that you're using your full-stack web standards standards and you don't have to rely so much on JavaScript. They use the web components to basically allow you to render pieces of that island's architecture kind of thing. But instead of relying on a React component, I'm actually server-side rendering a web component. So I can do even less reliance on client-side JavaScript.

So I think Enhance is all like server-side rendered, but it's all using web components to kind of componentize that, you know, your application, but then you render just the component that fits in to that spot of your application. Yeah, yeah. And I think I was wondering the same thing that you're asking, and Brian LaRue, who's like one of the Enhance guys, he was saying, I think you have these enterprise companies

that have all these different apps, maybe written in different languages, that are returning markup and stuff like that, and that they can now render those web components and have some sort of compatibility across that, I think is helpful to a lot of them. I see. I guess in a bigger organization, then you have teams

that are working on, they can make different language choices, but still come together at essentially the composable level. How much of these changes, whether it's the shift

to Jamstack or even some of the stuff that we're talking about in terms of frameworks are motivated by improved user experience or improved developer experience. I'd say if you listen to people like Alex Russell, for instance,

who I think has made a lot of good points about this, we were focused for years on improving developer experience. It was like we were building frameworks that made the developer experience better. And I mean, there's a value in that. I mean, if we can improve developer experience, in theory, we could get more done. Like, you know, developers can build better things, whatever. I mean, there's value to agree with him in many respects, was we sacrifice the user experience for that developer experience.

And I think that's maybe what we're seeing. That shift that I feel like is happening is shifting back towards like, okay, well, we know we're passing too much client-side JavaScript. We know our bundle sizes are ridiculous. We know some of these applications on mobile that are using some of these frameworks end up performing pretty badly, especially if you don't have a high-speed connection on your device.

So we've gotten used to seeing loading spinners all the time to load, like, simple stuff, right? So I think we're now kind of moving towards some of these frameworks are pushing us towards, like, okay, we need to think about that and rethink that, even to the point that I think, you know, you're seeing with React server components is React has kind of responded in the same way.

It's like, well, we know that this has not been the greatest experience for end users, so we're going to start to kind of move things where we can send less JavaScript and do more server-side rendering and things like that to improve the performance of the apps on the client. Are you using much React server components? I am not at the moment. That's how I am too. I'm like, let that stabilize a little bit first, right?

Yeah, I mean, I think it's... I feel like, for instance, Next.js has kind of said, like, if you're going to use the newest version, you are basically bought in on React Server Components. I mean, you cannot use them, but we're really pushing you in that direction. Which, I mean, to be fair, I think it's a better direction for it overall. So I think that's a good thing, but I haven't. There's going to be some churn in the short run, though.

Just like as we figure it out, we have to relearn all these different patterns and things like that. Right. What's the frustration level where it's gone too extreme to the server side and then it goes back to the client side? Yeah. We all change our minds. It's like, you know, I feel like it's like the, you know, when the FDA or whatever gives

you like the, you know, nutritional, this is bad for you. No, that's good for you. Coffee is really bad for you. No coffee is actually good for you. No coffee is bad for you. Like the nutrition pyramid for you. No, coffee is actually good for you. No, coffee is bad for you. The nutrition pyramid from when I was a kid is now rotated and looked around. Yeah, well, you know, it's not that different, right? You look back at stuff you did a while back and you're like, yeah, no, I would have built that.

I don't even know why I built that that way. I look back at stuff I built six months ago that way and I'm like, why did I do that? I don't get it. I would not do that. Every once in a while I find something that I wrote code-wise or even write content-wise, I look back and I'm like, hey that was not bad. That was pretty good. I was a good job, Pat, Sean. But I think a lot of times you're like, what was I thinking? You know, sometimes I had somebody come to me, like, a couple years ago, and I built their site for them, and, like, I was living in Wisconsin,

so I was, like, this would have been, like, almost 18 years ago, and they're, like, I'm, like, wait, you're still using that site? And they're, like, yeah, yeah, it still works. So, like, I mean, I think, think sometimes, when I was a young developer, I was like, I've got to do things the right way. There's a right way and a wrong way to do it, and it's better just to like, you might as well not do it at all

if you're not going to do it the right way. And then as you're in this career for a while, you start to appreciate the value of just getting something done and something that works. And like, ultimately it's like, you know, it was like 18 years later and that thing was still working for them.

It's like, okay, well, I did something right. I would have never built it like that today, but it did something right. Yeah, I think that's like a pattern. I also went through that phase when young in my career. And I think it's a natural thing when you're younger. And maybe part of it is that you're not at a point in your career or within the organization where you're at.

You can see sort of the full picture of everything. So you're not thinking about the balance between, hey, we have a customer that is signing a big contract that's motivating the timeline on this. You're sort of very hyper-focused on this one thing where, okay, we need to design it this way, and you're not necessarily at the level where you understand all the business parts of it or the idea that sometimes it's okay to take on tech debt in order to get something going

because you don't even know whether it's going to be there six months from now or not. Right. Yeah, I mean, you know, I have things that, like, I run this site, cfe.dev. I don't know if you may have heard of it, but where I've been doing virtual events for, like, seven years now, funny enough.

And it's, like, an old Hugo site. But I keep being like, oh, I need to redo this. I need to redo this. But for seven years, that thing still, I mean, it's still working great. And it does everything I need it to do. So yeah, I want to rewrite it, but also, I probably don't need to rewrite it. And I think sometimes, as developers, we just want to move on. We're like, I want to do the next thing. I want to do something.

And it's like, there is some value in just building something that works for a long time and just saying, you know what? It works. Don't mess with it, right? Yeah, a lot of times from a user perspective, they don't care what the stack is. I mean mean as long

as they are able to accomplish the thing that they want to accomplish like they're not thinking about like if they are thinking about like is this client-side render server-side render like what framework are they using like like that your your product might not be actually working that well if that is their thought process essentially yeah in terms of like composable uh i understand that it's it's sort of more along the lines of jam stack of being like a methodology or like a a way of thinking about building web applications but are there like trends from in terms of the tool stack that people are typically using there or you know strong opinions about it should be this collection of tools or what the stack looks like.

So the mock piece has a little more prescriptive, and I'm blanking on some of the details of how they tell you to structure your application. But composable in general, no, it's not necessarily. It's kind of like JAMstack. It's not particularly prescriptive about how you build things. I mean, most, as I said earlier, most of the time, like that kind of API layer is something built in GraphQL.

So, you know, if you look at some of the tools that are out there to help you do that, they tend to use GraphQL, which, I mean, honestly makes sense because there's no other way to easily weave together APIs that are kind of disparate and have different kind of interfaces and whatever. So like REST really doesn't scale for combining APIs very easily whereas like GraphQL kind of makes it simpler, especially with some of these platforms that's just like drag and drop almost. It's like, okay, connect this API. Netlify has, for instance, a bunch of pre-built ones or common ones.

You can just kind of like, boop, boop, boop, I need these APIs and put your details in there. And it's like, okay, now I'm connected to Storyblock, who's here at the conference. And that's already hooked up. But still allow you to, say, connect your internal REST APIs. They might be internal data pieces that you need to somehow integrate with the hell of that. So GraphQL really does make it easy to do that.

And that's why the company I was at, we were trying to do that too, figure out a way to easily allow you to just drop in those pieces and combine. At this point, most companies have... If you're building a complex site... Composable, by the way, is more like... It's not like, hey, you and I are going to go build a site for fun. We're like, hey, this should be composable because we're not going to encounter that problem. A few APIs is a big difference between a bunch of different APIs.

When I would go talk to these companies, for instance, they're not just talking about external third-party APIs. Even internally, right? They've got a big company. It's like, hey, this team is building APIs and this other team is building APIs. And guess what? Those APIs don't know how to talk to each other either. So how can we even connect all these different pieces, right? Because even their internal APIs, they were like, oh, we could just add a layer on top

of that and then have one way to connect to all our internal APIs. That is even amazing. Never mind the third-party stuff. They were having this problem internally. But it's more of a big company problem. It's not like, hey, my hobby project, I'm going to go build something composable. I think that even if you look at the companies doing this, like, who are kind of turning in that direction, some of the criticism of Netlify as an example was that, oh, this is, now they're going all enterprise-y.

And it's like, well, because that is more of an enterprise-level problem as opposed to, like, a developer-level problem at a, you know, small kind of hobby project. Yeah, yeah. Well, I think that's a good point. Like though, that it will be a lot of times like engineers can like fall in love with whatever some of the new hotnesses and we, we end up sort of like over engineering certain projects. You see that all the time. I think in like the, in the data world, like the modern data stack would get so in love with these like complex ETL data pipelines and, and like, you know, big warehousing solutions. And sometimes a spreadsheet and a Python script is good enough

and you don't need all these other bells and whistles and stuff like that. Yeah, for sure. In terms of GraphQL versus REST, is that something that you're seeing as a trend, that picking up more momentum even outside of Composable? No. I just feel like most companies don't adopt it unless there's a specific need. That was honestly the big trouble we had when I was at that company

was convincing anyone that they needed to move to GraphQL. There's a lot of complexities around GraphQL that I think it solves a particular problem. And this is one of those problems it solves, but as a general rule, I haven't felt like developers have kind of said, oh, I wanna move off REST. I mean, there's a simplicity around REST that's just like really, you know,

I don't need to think that much about it that when I get into GraphQL, like writing queries and all this stuff, it just, it feels more tedious. I think it's similar with like gRPC as well. It's like, you know, Google developed that because part of it's like, you know, the dealing with scale problems.

So they're looking for any sort of, know micro optimization that they can do but most people are you know they don't have that problem that google necessarily has and there's a lot of value you get from doing sort of the simplest thing that like developers are comfortable with if especially if you're doing an api based product yeah and i mean i don, I don't think, like, I think GraphQL can be a great solution for particular problems. And if that's the end result, that's fine. We don't need to move everything to GraphQL. I think it's just, like I said, the problem, for instance, of underfetching and overfetching

are not necessarily the problems that you're going to face on every application. Like, it's not a big deal in many cases like that I over fetched a bit, right? But when you're dealing with like you know, reams of data, like large amounts of data and things and you're in these kind of scenarios, like then yeah, it becomes maybe that's a problem and I need to deal with it by using something like

GraphQL to like be more specific about what I need to deal with it by using something like GraphQL to be more specific about what I need back from that API. Whereas in many cases, REST is going to work just fine. At the bigger companies, are you seeing a lot of momentum with GraphQL? Or is that slowed as well? Like if I do have, like you're saying, a strong set of APIs across all these different teams. I mean, I think slowly. Big companies are, you know, and it's hard.

Like, it's not necessarily the easiest thing to adopt. But, I mean, I think there's been a push for this. I know companies like Apollo, for instance, are trying to get companies to buy into that solution. So, and there is a need for it. I mean, when we went out to these companies, they knew there is a need for it i mean when we went out to these companies they they knew there was a need for it it was just you know it's it's hard to get companies especially right now to invest in something that ultimately doesn't change like the output right like we've

changed something behind the scenes and like there are tangible long-term benefits to this, but short-term, it was a very expensive project that didn't change anything in our application itself. Yeah, it's hard to show what is the increased revenue impact of switching from REST to GraphQL. That's just a difficult argument to make. So unless you have a really, like you were saying, specific use case that you can't do today or is not a reasonable thing to do under the current constraints of REST,

then it's hard to make that technical argument. And you've already bought, I mean, it's not like you, it's easy to just switch all your APIs. You already bought in, you have REST APIs all over your company, right? So you can just, it's like, well, now if I start transitioning, unless I can find a way to easily make a big project,

consolidate everything, I'm now using REST and GraphQL, which is not actually, it's just not helping me in any way. So, yeah. Well, as we start to come up on time and wrap up, we've got a few quickfire questions for you that we ask everybody. So if you could master one skill that you don't have right now, what would that be? You know, it would not be specifically around any particular technology. It would be, I feel like I've been in DevRel and done this stuff for a long time,

and I feel like I've never quite gotten how to build good communities. I built communities, but I feel like a lot of it's just I haven't gotten to that point where I can really get them kind of organically interacting and things. It's just so hard and so much work. It is tricky. Yeah. Yeah, I think not to go on i have one we could do a whole show on this i think but like yeah i think there's there's um

it's hard to do that as it's it's not a recipe i don't think like you can't just copy what someone else did and then apply it to whatever your technology is there's there's i think a lot of it's like an art and science sort of combination there. What wastes the most time of your day? Oh, me being me. I don't know. Like, I just, you know, I've always said, like, you know, people live stream their coding and I'm like, nobody wants to see me code because I am like, I'm all over the place.

Because when I hit a problem, like something difficult, I need time to process it. So like I just swap and do something else. Yeah. In the back of my mind, it's going. Yeah. It's like I'm not like, I'm not the kind of person that can sit there like two hours and just code. So I feel like I end up,

a lot of context switching wastes a lot of time in my day, but it's my own fault. Yeah, so watching a live stream of you coding would be mostly you going and reading a random article and how you're doing. Exactly. It's like the old joke about what they used to say about Richard Feynman, the physicist,

where it's like to watch him solve a problem like what was his strategy for solving problems and essentially the problem would be written on a chalkboard and then he would sit there like this for you know whatever 15 minutes in total silence and then he would come up and write the answer and it's like that that's his process it's like that doesn't make for a compelling live stream if you can invest in one company that's not the company you work for, who would it be? Oh, God, that is a good question. Okay, I'm thinking about this.

If I could invest in one company. You know, it wouldn't be, I would tell you what it's not. I mean, I think there's a lot of stuff, like, for an AI that I really believe in, but I also feel like nobody's figured it out yet, so I don't know who these companies would be. Yeah. You know, where I could easily place a bet there. You know, and there's lots of companies I love,

like, I love Astro, for instance. But I'm also like, when I'm thinking about investing, I'm like, hmm, I don't yet know what their business model is. So would I invest there just because I love them? So that's a roundabout way of saying, I don't know. This is why I leave investments. I have somebody who does my investment for me cool all right and then what tool or technology can you not live without what tool or two i mean it's right now i mean honestly it's vs code because i just like i i'm

in vs code all day long and and it does everything i want to want to be able to do. And now with like Copilot, it's like, I feel like it's just, you know, made my midday much easier. So, you know, it's got to be that. Everything else is like, I feel like it's easier for me to switch frameworks than it is for me to switch coding. Yeah, yeah, yeah. And what person influenced you the most in your career? frameworks than it is for me to switch coding. What person influenced you the most in your career? You know, I'm going to say, funny enough, and I can't even remember her name, but it had nothing to do, again, with learning to code.

Because I feel like coding is just a skill you can like that's like somebody can help guide you maybe but like I think ultimately I can just sit on the front of my computer and learn a lot of these things but like the people skills are hard yeah and that I remember I was working at this company and she said to me like that I always came with the why nots and never like really I didn't come with the solutions and and that stuck with me and I really feel like I've been able to change the way I approach things at work where it's like you know it's easy as a developer to like see all the technical problems when somebody presents you something. Instead of trying to...

And so you can start throwing up roadblocks and like, oh, no, we can't do that because of this. We can't do that because of that. Instead of trying to figure out how to get to an end point that... It's kind of like with with improv the like and yes mentality but we've all probably been in workplaces where we've worked with someone that's just like you know they're like the wet blanket or like in a meeting and it just like brings down the entire energy level and sometimes like an idea um that maybe is not a great idea

can you know can help inspire someone to lead the thing in a direction where it leads to a good idea. So if you're just putting up roadblockers, it's just like everybody's just kind of scared to essentially say anything. So I get that. Absolutely, yeah.

So I would tell you she was not a particularly great boss. And that was actually one of the worst companies I ever worked for. That was super helpful. But it was actually very helpful because everywhere from then on I think I started figuring out how to not be

the roadblock to be a part of the solution. Last question. Five years from now will we have more people writing code day to day or less? You know I'll be honest code day to day or less? You know, I'll be honest, it's probably gonna be less. I think, you know, like it or not,

companies are gonna be like, you know, we accept a level of problems with AI that as long as I don't have to hire people to do that work you know I'll accept that it's sometimes wrong and maybe it builds not the most scalable applications that we can't reuse the code because it's not it doesn't understand code reuse very well and all these things but you know what like it's good ultimately it's good enough and and it's a lot cheaper than a developer. So I'm a little bit, I'd say, I'm a little bit pessimistic about our outlook right now,

but I wish I could say otherwise, but yeah, that's my feeling. All right, well, on that dour note, Ryan, thanks so much for being here at this developer conference where there'll be less people in five years from now yeah hopefully not i hope that i i you know i've been wrong many times before i've so i'm you know i'm hoping i'm wrong about that but awesome well thanks thanks for spending time with us oh yeah thanks for having me