Chris Bach: The Origins of Decoupled and Composable Web Architectures – Episode 203

Content Strategy Insights

Content provided by Larry Swanson. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Larry Swanson or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://podcastplayer.com/legal.

1y ago 36:49

MP3•Episode home

Chris Bach Over the past ten years, Chris Bach has been at the forefront of the transformation of web development. Chris coined the term "Jamstack," which refers to one of the first conceptions of a composable web architecture (the acronym JAM accounts for the JavaScript, APIs, and markdown that make up a simple decoupled web system). He also founded Netlify, a company that supports these new architectures and which now serves tens of millions of customers. We talked about: his role as the co-founder of Netlify the origin story of Netlify and decoupled web architectures how the JAMstack movement arose in the tech ecosystem of ten years ago how phone app stores set the stage for decoupling apps from data the technical developments that permitted the development of this new ecosystem: cloud computing, APIs, Git, static site generators, more capable browsers, etc. their development of the open-source developer community that supports the JAMstack ecosystem the emergence of headless CMSs alongside the JAMstack ecosystem how his 14-year experience in digital agency work informed his work at Netlify how issues like performance, security, and scalability show up in the JAMstack world the benefits of decoupling back-end services and front-end web presentation the advantages that composable architectures offer: simpler migrations, quicker time to market, reduced operational costs, etc. the evolution of his conversations with enterprise clients over the past 10 years how composable architectures permit better decision making and quicker action around adopting new technologies like generative AI how generative AI is changing content marketing and his thought that less content of higher quality will be crucial going forward Chris's bio Chris Bach. Serial entrepreneur, unicorn founder (Netlify), co-creator of the "Jamstack" terminology, featured as a "2024 top 60 angel investors that back B2B startups" by Business Insider, and outside of 50+ angel investments he sits on 15 advisory and executive boards. He also an advisor for TUM (Technical University of Munich), Copenhagen University, and the Danish Innovation Center. Danish but lives in Silicon Valley. Connect with Chris online LinkedIn Video Here’s the video version of our conversation: https://youtu.be/88Cr6nh6xjc Podcast intro transcript This is the Content Strategy Insights podcast, episode number 203. Ten years ago, web development was in a very different place. New technologies like cloud computing, APIs, Git repos, static site generators, and headless CMSs were emerging, but how they might all work together wasn't yet clear. Into this primordial version of the modern web stepped Chris Bach. Chris co-founded Netlify, an innovative development platform which has been instrumental in creating the web's new decoupled and composable architectures. Interview transcript Larry: Okay, here we go. Hi, everyone. Welcome to episode number 203 of the Content Strategy Insights Podcast. I am really excited today to welcome to the show Chris Bach. Chris is the co-founder at Netlify, a web services company, a development platform where probably most of the stuff you look at on the web is happening over there. He's also an advisor to a lot of other companies, an investor. He sits as an executive on a number of boards. So welcome, Chris. Tell the folks a little bit more about what you're up to these days. Chris: Thanks for having me. Yes, I am the co-founder of Netlify, as you said, a developer platform. We run a lot of site stores, applications, and so on. For the last three and a half years, I've been CSO there, so a little less operational. And then I actually just stepped out of my full-time role there. So now I still sit on the board. I continue my work as an advisor, as an investor, and as a board member. Also looking at a little bit of climate tech, which is a little outside the scope of today's conversation. Larry: Yeah, I'd love to talk more about that some other time, but, well, first thing, I think a lot of folks like Netlify. In the landscape that many of my listeners occupy, it's a thing their content is going through every day, but they probably don't know what it is. Can you describe the company and maybe the origins of it too, because it was a new concept when you started it 10 years ago? Chris: Absolutely, yeah. So the origin and the backstory of this was that the web 10 years ago was struggling and it was losing out to walled gardens like App Stores and so on. And it wasn't because you're using one piece of software, let's say WordPress or Drupal or whatever, it didn't really matter. It had to do with the architecture underneath it. And that architecture meant that a website essentially was a program running on a singular server somewhere and building a version of itself for every single visitor. And that made it fairly slow. It also made it very vulnerable. The code was exposed and it didn't scale very well. And my co-founder and I were sort of eager to see what could be done to change this, because the web is a place where everyone has permission to publish and so on. It should be a place where, if you want to publish something, you shouldn't have all these gatekeepers and it shouldn't be controlled by a singular company. Chris: And what we saw was that, if you could do essentially what happened with mobile apps, which is decoupling the application itself from the back end, that would solve all the major issues. So the notion is that you can more pre-build a front end, and that front end means your UI, your presentation there, whatever someone is going to experience on that browser, however they're visiting that, if that could be separated from the back end that has to run and feed all the data into it, well then, that can be pre-built to a higher degree. It also solves for if you have multiple digital touch points. Let's say I have a mobile web application, I have campaign sites, I have my main.com and so on. All of those can draw from the same back end because they're built separately and then they would just access the back end as what we today would typically talk about as a headless API or microservice and so on. Chris: And this decouplement just made a lot of sense. Essentially, we wanted to decouple the front end from the back end, and in that we saw that it would solve for notions of scalability. You would have multiple points of origin. It would be way faster, more secure, more scalable, but it would at the same time also require a reinvention of the ecosystem. So let's take e-commerce. Every e-commerce provider at that point, well, their output was always a website, it was a dot com or whatever it might be. And so that means that you can have that and then that outputs your website and that's it. And so you can't marry that with something else that also has an output of a website. In other words, we needed someone to come and invent some headless commerce solutions and headless content management solutions and so on and so forth. Everything from form handling, which it was one of our first debits because it was so frequently asked for. Sign up for newsletters or whatever it might be because this started with blogs in the beginning. Chris: But this was really the notion. There were a few things already that we had made as third party services. So if you think of payment gateways, that was a typical thing. I don't build that myself. We figured that out even before then. But we still ran these monoliths. And so we said, "Okay, well we can't build out an ecosystem, but we can pave the way of saying, when you go," what we today talk about as composable, headless. When you follow the best practice of the Jamstack, in Danish where I'm originally from, Denmark, you say, "Dear child has many names," and there's a lot of ways of talking about it, a lot of nomenclature out there. But essentially if you follow this architecture, then when you get, let's say, a traditional CMS, what you're also getting is not just content management. You're also get an template engine, a build tool, glue code. You're getting all these things that you don't really think about, but it's there to help you output a site at the end of the day. Chris: Now, those things, I can mix and match the best builder and the best tool over here and the best commerce solution, the best CMS, but how do they actually talk together? How do they integrate? How's that notion integrated with things like CD/CI? That's continuous integration and deployment. And how is it actually distributed/hosted afterwards? And so in other words, you needed to rethink the whole workflow, the whole orchestration and operation parts of how we do these site stores and apps. And that was a platform that we felt that we can go and build. And so that's what we did. That's the origin. We built on Netlify as a workflow platform for anyone that wanted to build these decoupled sites. But, of course, back then, there wasn't really a notion of decoupled and what it actually entails. So we came up with the terminology around JAM. Larry: And talk about JAM. Well, actually, I'll let you define it, because I've heard the M described as a couple of different things. But you invented this, so I'm going to defer to your origin story knowledge of it. Chris: This is JavaScript, APIs, and markup. It was the notion of decoupling, but there were a lot of things that led to this decoupling that enabled it. Chief amongst this was actually that browsers had become an operating system, because that's why you had an App Store on mobile phones. Many people don't know that when Steve Jobs presented the iPhone in a PDF, the App Store didn't exist. All those icons were showcased to websites. It was only because, again, the web wasn't in an architectural state that was performing enough that we shifted and said, "Well,

134 episodes

#Business #MBA #Content Strategy #Larry Swanson #User Experience #Tech #Software Development #Podcasting Education