The Changelog: Software Development, Open Source - JAMstack, Netlify CMS, and 10x-ing Smashing Magazine (Interview)

Episode Date: May 30, 2017

Matt Biilman and Chris Bach joined the show to talk about JAMstack, Netlify CMS, how open source drives standards, and 10x-ing the speed of Smashing Magazine.

Bandwidth for the changelog is provided by Fastly. Learn more at Fastly.com. announcements, they've expanded their offering to include high memory instances in $5 Linodes. High memory instances are optimized for memory-intensive workloads like high-performance databases, in-memory caching, rendering, and data processing, and the new 1GB Linode is their lowest-priced instance ever, just $5 a month. This makes it way easier to choose Linode every time you spin up a new server. Linode also increased the outbound network speed limit on all plans to a minimum of 1000 megabits, super fast. Check out linode.com slash changelog to learn more and get $20 in and hosting credit. Hello and welcome to the ChangeLog, a podcast that gets to the heart of open source technologies and the people who create them. Myself, Adam Stachowiak, and my co-host Jared Santo are talking to Matt Billman and Chris

Bach about Jamstack, a new way of building websites and apps that deliver better performance, high security, lower cost of scaling, and a better developer experience. We talked about the redesign of Smashing Magazine on Jamstack, Netlify CMS, and open source CMS built with Jamstack principles designed around a fully Git workflow and the ways in which open source drives standards. And we're back. We're talking about the modern web Jamstack. Now, Jared, I just,

I literally just learned about Jamstack from you in the pre-call because I hadn't even heard about this. It's so new. It's that new. Well, I just learned about it about a month ago, which was kind of the kickoff for this show when there is a post published called Smashing Magazine just got 10 times Faster. And we're going to dive into that. We're going to talk about Jamstack. We're going to talk about CMSs, CDNs, Netlify, all sorts of fun stuff. But first, let's welcome our guests, Matt and Chris.

Thanks so much for joining us. Thank you. Thanks for having us. So I suppose I should set the stage a little bit since I arranged this call. I'm very excited to talk to you guys about this. But we have a lot of moving parts to this conversation. There's a lot of actors. So you're going to hear Jamstack, which is kind of like Lampstack or Meanstack, only I look at it as upper layer, whereas those are referring to specific technologies like Linux, Apache, MySQL, PHP,

the old LAMP stack. JAMstack is up a layer. It's not speaking to specific implementations of technologies, but it's more of the idea of JavaScript APIs and markup is what it stands for. And the general idea is ship static pages and decorate them and build on top of them with JavaScript and third or maybe first party-party and maybe third-party APIs. We'll get into that. So there's Jamstack.

There's also Netlify CMS, which is an open-source project. It's a CMS, which comes from Netlify, the business, the group. That's where Chris and Matt are from, co-founders. And we're also going to be discussing Smashing Magazine and the recent redesign, co-founders. And we're also going to be discussing Smashing Magazine and the recent redesign, March 2017.

They relaunched. It's in beta right now. You can check it out at next.smashingmagazine.com. Brand new design, brand new technology stack off WordPress and really a bunch of other tools and onto a custom thing built in Jamstack style.

Guys, is that a good foundation or or did I mess anything up there? I think that was pretty spot on, yeah. I mean, the Netlify open source CMS is a Git-based attempt at breaking the gap, and the JAMstack is really all about enabling the decoupled way of approaching things, the journey away from monolithic apps. So yeah, I think you nailed it pretty good. Cool. So we're going to focus this conversation on Jamstack. And the cool thing is, as Netlify

and the team that rebuilt Smashing Magazine kind of from the ground up built it, they open sourced a bunch of goodies. So not just Netlify CMS, but also GoTel, GoTrue, GoCommerce, these microservices written in Go that are powering the new Smashing Magazine and really enabling for this style of application. So we want to focus on those things. I think we'll probably use the case study

of the Smashing Magazine relaunch as a anchor or as a pin for the conversation, but we really want to focus on the open source and really the ideas, if possible. So let's start with Jamstack, because Adam just heard about it today. I just heard about it a month ago, probably our listeners for the first time. But we've all been kind of doing things like this for a while. Tell us about the term. And did you guys coin it?

And where did it come from? It was actually like the i think the first guy that said the word was a friend of mine andreas steph johnson who works at uber and and it sort of came around because as you mentioned like this is not it's not really something new right it's something that people have been doing in different ways like starting to really decouple the the front end and the back end. We've seen like a huge growth in the space of static site generators and build tools.

There's the huge growth in just general front end build tools like Gulp and Grunt and Webpack. There's the whole tendency around progressive web apps and so on. So it wasn't so much that the JAMstack was like we invented something and started doing something completely different. It was more a question of all these people starting to essentially build websites and web apps with a new architecture without really having a good nomenclature around it. And obviously, because of what we're doing at Netlify, we had contact with a ton of people in the space and everybody were sort of suffering from not having a way to talk about what they were doing and not really having a category to refer to. And that's when that term

started to emerge of saying like, everything we're doing is centered around like shipping mock-up to the browser and then using JavaScript as the runtime and talking to all these different APIs, whether they're self-hosted APIs, the microservices or fully managed services. It's like, that's the core architecture. And seeing that people are really starting to build

with a set of constraints, that means you start saying, we will decouple the front end and the back end completely and rely on pre-building as much as we can in mock-up and serving that directly. But then using JavaScript in the browser as the main runtime and talking to these different, very encapsulated services. And that's sort of when the term came about

and started to be a useful nomenclature to talk about this category and this architecture. So as I was saying in the intro, the JAMstack does not dictate technology choices in terms of how you go about it. So the J stands for JavaScript. Of course, that's a technology, so it does. But it's not at the level of a framework or a toolkit.

No. Correct? Exactly. It's very true when you said that the stack has sort of moved up a level. I feel that it's really about this journey away from the monolithic workflow, right? Where you have these apps where you have to run everything at a time. And we're seeing that they became more and more bloated, less and less performant,

have more and more security issues. Malware is becoming a $100 billion industry. 7% of all sites are hacked. At Netlify, we get 60 million requests every month, alone, starting with WP Ad wp admin that are just malware saying that if you happen to have a wordpress site installed we'd love to infect it and and the negligence test that used to be like six months of having a default drupal site or wordpress site or anything like that that you know have you know it's a normal site with a few custom plugins and uh

and aside and and you leave it alone for as long as it takes to whether until there's like a 50 chance of this being something bad happening to it and today people are talking about that can be as little as as two weeks right basically if you don't update php and sql and apache and this and the site itself and and the custom plugins things can can go over already really fast, right? So we see this way of building, this way of decoupling things where you build things in advance.

It's a solution in so many ways. It's way faster, right? Because first of all, you can have multiple points of origin. Instead of having one server that runs everything, you can distribute the site itself on a content delivery network. That means on edge nodes all around the world.

And you don't have to build it on the fly, which makes time to first bite and stuff like that so much faster. And at the same time, it reduces the surface area attack from malware tremendously. Because you're not running this huge, very popular monolithic app every time you have a visitor. Rather, you have all the runtime in the browser, and it connects to these specialized APIs that have a much, much smaller surface area. And lastly, scalability. Now, when you don't have to build it on the fly, it means that you can guard yourself against speed traffic in a completely different manner. I mean, like when we started out, we were looking at hack and use and every single day,

there seems to be some like young startup that finally gets the break and they're there. And then, ah, you know, it leads to broken sites because they simply cave under the traffic, right? And this way of removing the building and the hosting and decoupling the front end and

the back end really enables a lot of things. And number two, we also feel that the legacy web is rendered on the fly, whereas the very popular web building right now is dominated by Git. Now, Git is social coding. Git is a lot of things. But Git is also essentially working about structured layers of data, consistent layers of data. So something that runs on the fly and something that works with version-controlled layers, snapshots of data, is not inherently very compatible. So for us, it's also about building out best practices and workflows that support the modern way of building, which is Git, which is advanced markup and stuff like that. And then we

saw this trend of five years ago, front-enders, they were cutting out PSDs. I know it's putting it up a little bit square, perhaps a little even coarse, right? But still, I worked with a lot of front-enders that were cutting out stuff in PSDs, converting it into HTML, and then sending it

off for implementation. And today, it's really like you have front, you have friendliness that are not friendliness anymore. They're web developers. We should think about that nomenclature as well, because they're doing advanced mock-up. They're compiling. You know, the Jamstack is all about enabling them to close the loop without having to send something for implementation into a monolithic app with everything that comes there, right? So it's sort of a broad mission and then we just felt like talking about static sites made very little sense because first of all it's not staying at all it's just that the dynamic part has moved up the level

so now it's going on by runtime and on client sites right sure and it wasn't very fair and then of course there's also like a negative connotation with a term like static that didn't do this movement justice at all. And when people were calling us and saying, okay, so let us explain our stack. And then they spent like 10 minutes describing what really is the Jamstack, right? Which is this mind-gid-centric way of working on one side and then using API microservices on the other side. And they were looking to get viable workflows as far as publishing and use of CDN and all those things goes.

So for us, that's just the jam stack, right? And it's not proprietary in any way whatsoever. It's just a little bit easier way of talking about things. And it really is about trying to introduce some best practices. Yeah, I like that. Get everybody to speak in the same language. Exactly. Yeah, I always remember Thomas Reynolds from Instrument who was a technical director there and built the middleman that's one of the static site generators

that we've seen some really cool projects built with. But just with the term static, I remember him telling me that they had just at Instrument built a major project based on middleman. And he was like, this is a project with 200,000 lines of code in Ruby. It makes no sense to talk about it as like a static website, right? It had like a whole layer of publishing static JSON as an API that could be consumed by JavaScript client-side and so on. It's a super complex project. And again, it was just a sign of how badly needed the new nomenclature were at the time.

Yeah, we actually had a show on Middleman a while back. Maybe two episodes, I don't recall. But we had that conversation with him as well. Very interesting. I'm also a little bit of a new media, new age journalism, not aficionado, but this thing's fascinating. So I enjoy hearing the stories of how new publishers, especially indie publishers, which Changelog is, goes about publishing today. So that was interesting to see what Vox Media had done with middlemen and stuff like that. We should probably point out, because I said there's the CMS, there's also Netlify, the business.

And it's worth noting that while all these technologies and ideas are not proprietary, very much you guys have skin in the game of people doing this style of application. Can you tell us about Netlify and what it is? Netlify is a broad automation platform. So really it's an attempt at a custom infrastructure, which is a CDN that's built out virtually on top of a bunch of different providers and provides instant cache validation,

high cache ability, and atomic deploys. Enables a lot of the logic that used to be on the server side, but brought straight to the edge nodes. And because we have that, then we're able to build out a bunch of the logic that used to be on the server side, but brought straight to the edge nodes. And because we have that, then we're able to build out a bunch of features on top of it and then wrap it all up in automation. And what's really the idea is that developers have a place where they, in a few minutes, can get all the best practices,

custom domain, HTTPS, continuous integration into Git, and a post-process site that's globally distributed. And then we scale, of course, that for businesses that it also wants to get all the performance benefits and the security benefits and so on and so forth from the Jamstack, right? And that's Netlify as a business. But what we strongly believe is that

everyone is better off by not rendering on the fly, by not using these monolithic apps. So for us, it's very, very much about pushing the category forward. And that's why we're so engaged in open source. And that's why we also did, I'm sure we'll get back to the whole smashing project, which was all about saying,

we'll invest heavily in building out these microservices as long as you guys agree that we get to open source it with everyone else. Because we do believe that that's how standards are pushed, right? Absolutely, absolutely. Well, I think what we'll do is, I want to hear a little bit of the story of the Smashing rebuild.

We're coming out five minutes before our first break. So if one of you can give us the quick summary of what happened, the 18 months, the things that had to be developed. If you could do that in five minutes, that'd be great. On the other side of the break, I do have some pushback on specific points because I believe that, and you guys are all in on this,

it makes total sense that you're very bullish on it. In engineering, there are trade-offs and there are many situations where the JAMstack doesn't necessarily fit very well. And I think we should talk through some of those. I think it'd be fun. Absolutely. To go through a few of the finer points with you

and have a conversation. So who wants to try and just give us the background of where Smashing was, why Jamstack was selected, how it was built, and that whole thing? I think Matt can do that because it really started with an article, an appearance at a conference, and then the whole thing went from there. Yeah, I tried to give a quick version of the story right so I got asked to write an article about static site generators back in November last year 2015 actually

in 15 yeah I wrote an article called the why static site generators are the next big thing and when I passed Smashing Magazine the first draft of course one of the points was about like how performance can be a lot better with this approach. So basically from Smashing, immediately pushed back and say, that's fine, but you need to also really compare static site generator build site with a highly optimized WordPress site that uses all the caching plugins and so on so what i did was that i i took smashing magazine itself that very much fit that bill did as a static scrape of it and and put it on netlify and then just ran a common speed test against it and and showed that it would be six times faster on average if it could live directly on a content delivering network. I put that back in the article and I must admit I kind of expected Vitaly to be like,

we're not going to publish that. It makes us look bad or something. But he was totally game and just put a checkmark on it and published the article. And then that article became the article in all of 2015 on Smashing Magazine that got the most engagement. And based on that, they asked me to give a talk about this new stack at Smashing Conference in San Francisco in April last year. And I gave my talk there essentially about the Jamstack. And after that, the founders of Smashing came over and said, so we saw these numbers, right? And we've been looking at this.

What would it take if we wanted to put all of Smashing Magazine on Netlify? What would it actually require? So we sat down and really started looking at what would it actually take? And one thing we could see was that at the time, their system consisted of Smashing Magazine is not just articles right they have a shop where they sell ebooks and printed books they have their event pages they need to sell tickets they have a job board and at the time they they had like wordpress for the main magazine, an old Rails app for the job board, Shopify for the job, Kirby for the event pages.

And then they wanted to introduce their new membership feature and had no idea where in the system that would live. And they already were struggling with having to maintain the same themes across five different platforms, essentially, and keeping all of those in sync. But what we could see was that in the space of the Jamstack, there were still some holes in the ecosystem. There were no good open source solutions for all of Smashing Magazine's needs. And based on our experience, we could see that what they needed at the time was not

super unique or anything. It was just something that wasn't there in the ecosystem at the point. So as Chris said, we basically told them, okay, we are going to make a huge exception from how we normally work, where we just give people a platform and they build. And we're going to take a role in this and really help you build this project. But we are going to make everything small, reusable APIs that we can make open source and that we can just contribute to the general ecosystem because we really believe that there's a need for that in this Jamstack space. We already had the initial version of Netlify CMS, but needed to take it to another scale to handle the amount of content and contributors that Smashing Magazine has. And then we built out GoTrue.

That's the layer that handles authentication for Smashing Magazine. We built out GoCommerce, which is a completely headless e-commerce API. We built out GoJoin for managing subscriptions for their membership features, and GoTell as a comment engine, and made all of these open source and helped them get the new Smashing Magazine to become a reality. Matt, perhaps you can also just go into it, because the e-commerce is not like we built out Shopify in any way, right? No, I mean, one of the things that's really interesting with this stack is that if you were to build in the old stack and e-commerce, right, then you need to build all of it, right? You need to build the product catalog, management, and all these things.

You need to build all the UI for rendering the HTML pages and so on, right? But GoCommerce is a very simple API that almost condenses down to two API calls. One's to create an order and one's to pay for the order. It doesn't have any user management because that's handled by another API and just sent back and forth in the form of JSON web tokens, completely stateless. It doesn't have any product management because that's just handled by the website itself. So when you trigger an order with GoCommerce, you just tell them the path of the product on your website and GoCommerce will look up those products and get the metadata from that and calculate the price of the order and so on. So because of these architectural constraints,

like there's no product management that's just managed by Netlify CMS as part of managing the general website. And because of that, it was viable to build these tools. Like if this had been a traditional stack, this would have ended up being a completely custom, big, monolithic app that wouldn't really be reusable for other people.

But because of this decoupling between the front end and these different small services, it was possible for us to condense all the functionality that Smashing Magazine needed into a set of small, simple APIs that only does one job, but hopefully does it well and can be reused by anybody else using like meeting several of these functionalities. Let's pause real quick here because I want to pick back up on that specific point. I have questions about the GoCommerce aspect of it, but we're hitting our break. So let's take that up on the other side of this break. We'll be right back.

This episode of The Change Log is brought to you by TopTal, a global network of top freelance software developers, designers, and finance experts. If you're looking for contract or freelance opportunities, apply to join TopTal to work with top clients like Airbnb, Artsy, Zendesk, and more. When you join TopTile, you'll be part of a global community of developers who have the freedom and flexibility to live where they want, travel, attend TopTile events all over the world, and more. And on the flip side, if you're looking to hire developers, designers, or finance experts, TopTile makes it super easy to find qualified talent to join your team. Head to TopTile.com, that's T-O-P-T-A-L.com, and tell them Adam from the Genius Log sent you.

All right, we are back, and we are talking about the JAMstack, specifically the JAMstack implemented on behalf of Smashing Magazine and all the cool open source that came out of that. A couple of questions referring back to the other side of the break there, Matt, when you were talking about GoCommerce

and the e-commerce side of Smashing Magazine is you said that there was no product management. I'm not sure I followed that because, tell me if I did, because the actual product descriptions and imagery and all the things that you would need for product management are stored in Netlify CMS. So then the GoCommerce just reads that.

Is that what you're saying? Yeah, basically all that GoCommerce expects when you create a new order is that you send it a list of line items. And each line item has a path. And then in the settings for GoCommerce, it has the main URL of your website. So what GoCommerce will do is that it will look up each of those paths on your website. And then it will look for a special script tag with some JSON inside it that is the metadata for the product. And that's sort of the source of truth for the product. So even if all of the checkout and so on

is handled client-side with JavaScript, you can't fiddle with the prices and so on because GoCommerce will look at that metadata and verify the prices. But it means that GoCommerce doesn't need to have a product database or things like that. If you build this with a typical e-commerce system, you would need all these products to live in the database of the e-commerce system and so on. What about inventory, coupons, tax rates?

Yeah, so all of the tax rates and so on, they are defined in a settings file, again, on the website. And the GoCommerce will load that settings file and then do all the tax calculations based on that. The coupons are even stored on the websites as well. Of course, you need to make sure you set some form of authentication for those. So people can't just go in and read what coupons you have. But the idea is that you just give a URL with authentication where your coupons are stored. And then GoCommerce will just read that. And that is defined in JSON and just will define some rules. And GoCommerce will verify all of that.

We don't have inventory yet for GoCommerce, but we also have some plans for that. So you, back to the coupons, you put your coupons at some sort of endpoint that's accessible via the web, but is protected somehow via some sort of authentication scheme? Are you just talking about basic authentication? Typically just HTTPS plus basic auth. auth right and so so your go commerce micro service has that authentication but you know the front end doesn't and so it can make that call nobody else can precisely okay and no inventory yet so i i think

of course with for smashing magazine all of this is managed in Netlify CMS. But again, there's no coupling here, right? Like, GoCommerce doesn't know that Netlify CMS exists. Right. And you could even use GoCommerce with a traditional Rails application or something like that. It wouldn't care. You could also use it together with inventory managed in Contentful. Or if you buy business,, you have a CRM where

all your products are stored or whatever, a big inventory system or whatever, you can generate the website from that and then hook up GoCommerce, right? So GoCommerce is completely decoupled from the other parts of the system. Right. So how do you manage the... I'm just stuck on the security there. So you have some sort of endpoint that's just password protected somewhere.

How do you manage the credentials for that? Because isn't the whole point is you can ship it off to a CDN and not even think about it anymore. But now you have to, now you have to password protect a certain portion of your website. Well, depends a bit on your CDN,

how easy that is. One option, if your CDN can't do it, you will need to put that file somewhere where you can require authentication. Right. So it gets more complicated unless your CDN has specific features now. Or you can potentially just put that file under

a long hash URL that's not exposed anywhere. Just hide it? Yeah, essentially. I mean, in the end, if you use a very long, like with enough cryptographic complexity that no one will ever be able to guess it, if you use that in a URL and it's not linked to anywhere and not exposed in any site maps or anything,

then that will work as well. Yeah, maybe. I mean, perhaps if you're selling t-shirts and stuff. It depends on, I guess, the... It's just risk versus reward, I guess. I'd certainly put that in 1Password too, so I don't know about that. I definitely need a link somewhere

so it might actually get clicked from some point and exposed. Yeah, you would try to. I just feel like that's a slippery slope. And for a bigger setup, I would absolutely recommend using BasicOff. Yeah. And of course, HTTPS. Right.

So moving a little bit aside from that, one thing that's struck me with specific, and we'll move off of smashing here in a minute and talk more about the CMS because we'd like to. But one thing that struck me is, Chris, you said that building monoliths is a problem and these big systems that all have everything in them and dynamic rendered. And with this system, now you have microservices.

But wasn't Smashing Magazine already? I mean, one of their problems was they had too many little things, right? They had a Ruby-based shop. They had a WordPress-based blog. They had a Magento and then later a Shopify-based. They didn't have a monolith, right? And that's part of the problem with the monoliths, that you can't really mix and match them.

So if you're in Shopify and Shopify can't drive your magazine because it's not really a publishing platform, then you can't really just use Shopify right and if you're in WordPress and the e-commerce features they are not really up to up to power with what you want you can't really use WordPress for the whole thing or you have to go with using WordPress for everything and then you're sort of stuck in that world. Their problem was not so much that they had different services involved, but that with the monolithic approach, you can't really mix and match those services.

Whereas with the Jamstack approach, they can just build one front end that talks to all these different services, right? But all of the design layer and theming layer and all of that is in one place. So you're saying they basically had four monoliths. Yeah. And it's better, because I mean, your code has to live somewhere, right? So this is like move your monolith to the front end.

Like microservices on the back end, decouple those. And then couple it on the front end where it makes the most sense, because that's where your styles, and that's where your layouts, and that's where all the things need to be shared. Yeah, exactly. I mean, the whole point, again, is getting away from having to build everything every time someone misses, right? And of course, you can optimize against that to some degree by putting stuff in front of it but at the very end of that you still have your html you still have your times of first byte you still have the basics that are running on

your own server somewhere yeah and that's what we want to get and and uh we're working uh i guess we'll get back to it as well but sarah swaden was talking a lot about uh she was the front-end developer for smashing magazine and she talked a lot about how that worked for how anything you push your patent libraries instantly live, like the style cards are actually working. Because she wasn't sending anything off. What she was implementing was the site itself. But I'm sure we can talk a little bit about the Smashing Magazine case later. Right.

Let's talk about what came out of it. So we've talked a little bit about GoCommerce, a very simple microservice for transacting. There's GoTel. Because they had comments, there's GoTel. GoTru for

auth, as well as Netlify CMS. One point that I would just make around this idea of Jamstack is, it's not that you're removing complexity, you're just pushing it into other places. And lots of times that complexity goes into other people's pockets, so to speak. So you're using services, and whether they're services that you write or third-party services, which is the case for Algolia, which is being used for

search, or many people use Disqus, if that's case for Algolia, which is being used for search, or many people use Disqus, if that's how you say it, or Disqus for comments. What's often missing is those, which is very easy on dynamically rendered sites, becomes very difficult all of a sudden. And now there's not solutions out there. So one of the things I'm excited about is how many things you guys had to build to accomplish this. Because now actually there is an e-commerce thing we can use

and there is authentication and there is a comments thing we can use if it fits our use case. As opposed to having to rely on somebody else's service, which could go away, could charge lots of money. Thoughts on that?

We obviously thought it was really important to start helping out building a solid open source ecosystem. Because as you mentioned, like we've seen over the last five years, this really powerful service based ecosystem emerged that that wasn't really there five years ago, right? Yeah, where you have tools like Disqus and Golia and so on. And we just, when you look at sort of the traditional web space and you look at, for example, the CMS layer, right? It's what Chris was mentioning for the Jamstack, there's some great solutions already in the terms of content for data CMS forestry and so on,

but they are all proprietary. And when you look at the traditional CMS space for dynamic sites and so on and from the legacy stack, then you'll see that there's a bunch of businesses that are really, really good businesses like Squarespace, Wix, Weebly, SiteBuilder and Kentigo and all of these site core proprietary CMSs in the CMS end of things. But even when you combine all of those together and you then look at the statistics for what tools are most websites built with, combined, all of those goes into this little bracelet called other, right? And even Joomla, like good old Joomla is bigger than all of those combined in terms of actuals here, right? And then you have like Rupel and you have WordPress, which is just in a completely different league, right?

Sure. So what we're seeing is that open source drives standards. And for these really strong standards to emerge, we have to have a really healthy open ecosystem. And that was one of the major reasons that we said yes to Smashing to make this huge investment in building out all of these services and so on because we really thought that when we started this project,

so many of these services were either just available in proprietary form or they were available inside specific agencies that have built their own stack and so on. And that might have open sourced some of the tools, but that where all the main knowledge of how do you build a big project in this way was tied inside proprietary repositories and so on. And we saw an opportunity for really contributing.

I think that's also part of the story is that at Max's background, he was the CTO of the largest agency in Spain that made more than 100 websites a week, so on a very large scale. And I came from an agency background as well. And what we saw was that the APIs, they can obviously, they can be anything and everything, right?

So all these microservices can be job boards and can really be so many things, but there are some things that are much more standard than others. Content management, comments, subscription, commerce, and of course, authentication and form handling.

Those are sort of the ones that we just see again and again and again and again. So it made sense for us to say, okay, we're going to put some effort into contributing something to this space. As far as open source APIs goes, those should be it.

So you have a basic toolkit that you can run with and of course do anything you want with it. And the whole point here is staying agnostic, saying you can use two of them and then do your own thing for the rest or whatever. That's the beautiful thing of decoupling the front and the back end is that you get to mix and match. And since you don't have to run the code together, it's not like if you chose a traditional legacy system, you choose, for example, PHP. And that's just the end of it like when i was in agencies i often had you know there was a cmo or someone that said okay we want to use the eeg

wordpress because that's what we're used to updating and that's a fine and you know there's a lot of good reasons for choosing it uh besides that as well but the point is just that no matter what i had to go back to 10 developers and saying okay now we're coding in php because you know that's just the name of it right whereas now you, well, let's look at the resources we have and what's interesting to us and what will bring joy, right? Should it be made in React or Go or.NET or PHP or whatever, right?

Because the build tools now are executed differently and we don't have to run them anymore together inside so you can have both, right? So I think the darling for us here was really the content management because where there are some fantastic as i mentioned earlier some some fantastic services out there they're all proprietary if they are open source they're sort of more with a small scope and then most of them are api based and for us uh all of this is about i think enhancing that git workflow

and so everything we do whether it's open source or if it's part of the business, we always measure ourselves with how does that play into the Git workflow for developer. And I think that the CMS, Matt was the one who saw the opportunity of saying, okay, what if we did a Git-based CMS? What if this was actually just like a single-page app that was built to look agnostic, would work with any site generator, but then just work with consistent layers of data in Git?

Because then it's a one-to-one, right? It's not something you make work with Git, but it's just part of that workflow. And then on the other side, you can get a local, dynamic, real-time preview of everything you do, so you feel completely at ease. But every time that you click save,

you're actually running a branch deploy preview. And every time you say, okay, that looks fine. You use rich takes editors. It looks completely like anything would for content editor that isn't a developer and whatever they're used to from a legacy point of view. And, but when they click publish, then a legacy point of view. And, and, but when they click publish,

then just merges into master behind it. Right. So you're, it's, it's like so far you've been, you had to choose, right. Okay.

So CMS, obviously we can all agree. That's a no brainer. It's not for developers. The developers would rather just write the code, right. The CMS is an extension of the code that really just enables content developer writers, right? And so far, you really had to choose

who are you catering to, right? And we thought that maybe, just maybe you can have that where you can get both. We can have a developer workflow that isn't compromised, but still you stay in Git. This is your workflow. This is how you do things. This is how everything plugs in.

And this is how you collaborate with everyone else. But you also cater to the end users as far as continuity does go. And I think that's the really important thing here. That's also, you know, we're getting a lot of contributors already that are taking this and running

with it for their own use cases, which was exactly what we were hoping for. That's the key point that I think that Adam and I were missing as we discussed this before the show, is Netlify CMS that came out of this. This Git-based workflow, we were thinking, is this just a CMS for hackers? Because sure, we love a Git-based workflow,

but going back now, thinking how Vox Media and The Verge made Middleman work for them, their journalists aren't writing in text editors with Git. They use Google Docs because that's what they like to use and they take the output of that and create static sites. And that's because they don't want to have to teach all of their journalists the command line in Git. And so you're saying that Git-based,

and it's all text files under the hood and you can edit those directly and just commit and push, but it's also providing a nice user experience for authoring, which doesn't rely on them knowing Git at all? Not at all. They don't have to know how it's spelled. They don't have to ever have even heard of GitHub. Not at all.

Nice. So tell us about that.. So tell us about that. Yeah, tell us about that. Like, how does it work and how does it get integrated into, how do you use it and set it up? Yeah, so basically, as Chris mentioned,

the idea of the CMS is that it's a single-page app in React and by default, it just talks directly to GitHub's data API. So the way you set it up is that you essentially just have to include two files in your final website. One side is an index HTML that we give you that just bootstraps, that just loads the React application. And typically, you'll put it in a folder called admin as the index file. So when you go to slash admin, it loads the CMS.

And then the other file is a YAML file, config.yml. And that's simply where you configure how is your content structured for this specific project. So the CMS in itself doesn't really, it doesn't care what you use your content for or how it's published or what kind of stack site generator you use. Or if you're even using a stack site generator, right? Like you could use it to manage anything you want to be persisted as structured content in a Git repository. And it has a core abstraction called collections.

So all content is organized into different collections. And then right now at this moment, collections can be persisted in two different ways. One way to persist the collection is that you have a folder with similar entries that all have the same custom fields and so on. So they are all the same content type. And the other way of persisting a

collection is that you have different unique files that each have their own content type and instructor the first kind is like for smashing for example it's it's all the articles it's all the categories it's all their ebooks it's all their events and so on. Each of those are a collection of similar files. And then the other kind of things are, for example, the coupons is one specific file with basically a JSON document that the CMS manages. The settings is another file. The duration is a file itself that has like these are the featured posts, this week's featured category and so on. Based on that configuration file, the CMS gives non-technical or people who just don't want to write code a UI that's very similar to what you would expect from any other CMS.

You get your collections that you can navigate between. You can go to any of like for smashing. You can click on articles. You can see a list on all of your articles. You can click on an article. And when you click on an article, you get a form on the left hand with all the fields for that article and then on the right you get a preview running directly in the browser

of how will that article look like when you publish it similar to if if you've ever used ghost and you've used their markdown editor just instead of being like completely unstructured where you just have a title and a Markdown body, in Netlify CMS, you can have any kind of structure of your data, right? So for smashing, you might have a title and an SEO description and a main image and a summary and then the main post body and so on, right? But as you type, you will see a preview on the right side of how will this actually look like once we hit publish. And then the beauty of the system is that as an editor, you just go in, you maybe create a new article, you write that whole article, and then you hit save. And instead of saving that article in a database, like in WordPress, it will create a new pull request in Git, create a new branch with that article, with those changes, and create a pull request. And you have like a Trello-like dashboard where you can see all the pull requests in process, right?

But again, completely abstracted away from the Git terminology of pull requests and so on. It's really just like here's your draft here's the one that are ready to review here's the ones that are ready to publish and once you hit publish the cms will merge in this pull request and it just supposes that you have some kind of system that handles rebuilding the site every time that happens and of course we think netlify is as a platform is a pretty awesome solution for that but but it's not a requirement at all either so the i've been kind of silent for most of the show right now but curious if if i got this right so all the collaboration still happens in the netlify

cms admin area whatever that is where that lives yeah although you could still collaborate on github if that's where it was hosted or Bitbucket or wherever you can host your Git code. So the idea though is for the collaboration to take place inside the CMS, not inside of GitHub or at all. But you could if you wanted to. But you still can, right? And that's one of the beauties of it, right? That normally one of the paths have to compromise, right? That normally one of the parts have to compromise, right? If you use WordPress, then the developers have to give up on a Git-driven workflow and so on. And now all content is just in some binary blob in a database.

Don't get version control or anything like that. And it's a very separate workflow for how the developers work with all of the themes and everything like that, right? And if you just use like a pure, like you just go all out, just use Hugo and GitHub, well, then the content editors have to compromise, right? Like suddenly they have to learn how to interact with Git and understand the concepts of pull requests and so on, right? And this approach is really about giving both of these sites what they want. So the developers just have their normal Git based workflow. And as a developer, you can still edit the content directly in your text editor if you want and completely ignore the existence of the CMS if you prefer that.

But as a content editor, you can, on the other hand, completely ignore the existence of GitHub and text formats and all of that and just work in the CMS, use a rich text editor and hit publish. We're up against our next break. Actually, a couple minutes passed, but let's break here. And when we come back, we'll kind of talk a bit more about workflow and then maybe throw some hardball questions at you. This episode of The Change Log is brought to you by GoCD, an open-source continuous delivery server from our friends at ThoughtWorks. GoCD lets you

model complex workflows, promote trusted artifacts, see how your workflow really works, deploy any version, anytime, run and rock your tests, compare builds, take advantage of plugins, and so much more. Check out gocd.io slash ChangeLog to learn more

and now back to the show all right we're back with matt and chris and of course jared talking through jamstack modern tooling for good different workflows i would say jared right i mean different workflows for producing a site like this editorial teams It seems you've taken care of the developer side as well as the non-developer side needing a more CMS type of workflow. And that was probably the biggest question I think we had coming into this call was like, how do you do the workflow? Because if it's simply a code-based or a GitHub issues slash pull request workflow, then you sort of axe a ton of potential users and essentially lock out maybe journalists, unless you teach them things that they shouldn't have to learn to produce good content, right? And so it seems you've solved that. Although I would potentially throw in an argument of maybe it's kind of like lack of focus in a sense, but I'm

not sure I would term it that, but that's the only way I can think of it is that you've got basically two ways you could do it. So maybe you have some collaboration in GitHub and maybe you have some collaboration around a article where you essentially have to force people to choose a path, right? You wouldn't want, or maybe you're actually inheriting some of the issues and some of the collaboration happening on a GitHub type place to sort of allow people to choose their own path or use both. How does that work in the CMS? Like do you, in this dashboard, Trello-like dashboard of, you know, the editorial workflow, you see collaboration on GitHub or whatever you're using to host your code? How does that work?

We tend to see collaborations in both places, but as the CMS matures, we see more and more of the collaboration around content move into the CMS layer, and then the collaboration around design and code and those changes happening in GitHub. It's very powerful, though, that the two are tied together, right? Because often when you make design changes, being able to just always work with the real content and so on is also part of it. And getting the same guarantees for the content that we're used to have as developers for our code that you can always run git blame, right?

You can see at any point who made any change at any time to any piece of content. How did it look like before? You can always reverse a change. You can always see a snapshot of how did your website look like at any specific point in time, for example. All of these things are really powerful. We're trying in the CMS to also lean as much as we can without getting too tight to a specific platform on features like pull requests and so on that are not just Git but are also tied to GitHub or hopefully in the future also GitLab and so on. Right now the CMS backend requires GitHub, but we have a pull request in process to support

GitLab as well. That's exactly what I was going to ask to clarify. Is this a Git-based backend or a GitHub-based backend? And it sounds like right now it's GitHub, but that's not the end goal. No, no. We want to support a broad solution of Git backends.

But right now, GitHub is still far ahead of the curve in terms of their API for interacting directly with commits and trees and things like that. But we are, on the one hand, working with using the current GitLab APIs to let the CMS work with that. And then the guy that made that pull request has also opened an issue on GitLab itself around enabling some more APIs to get the integration even tighter. I have to admit, I've always longed for this type of CMS where you can have what we've known for GitHub, being able to have a site that's a static site generator feel where you can actually use the code, write and mark down whatever your workflow is. But then you sort of lost that CMS approach, which allowed you to auto-complete tags

and have all these extra fields and features like you're talking about that Smashing needed. And so I've kind of always longed for it. It always seemed like this pipe dream, so to speak, like who's going to build that and will they actually succeed? And it seems like we're talking to the people who's going to build that and will they actually succeed and it seems like we're talking to the people who may have done it we're working on it at least doing our best but but yeah that was exactly what we aimed to the things like uh that i guess right

i'm assuming that when the in terms of editorial workflow when they're writing content it's written to a markdown file or is it written to json is it what is the do you have control over that what's that like yeah you can control that so internally the cms has a concept of formats and you can set the format either for a collection or for a file and right now we support a body with front data matter that will typically be like a markdown body and then front matter in either YAML or JSON or TOML. And then apart from that, the CMS right now can also edit JSON files or YAML files or TOML files directly. And it has this concept of a format so the idea is also like from the beginning when we built the sim is we thought a lot about making it an extensible system where for a specific project you can add things to it so we are planning on exposing that formatting abstraction so for a specific project if you had

some weird internal format or whatever you you could write a little formatter that essentially needs to implement two methods, from file and to file, where from file just takes a string and returns a JavaScript object of structured data. To file goes the other way, right? Takes a JavaScript object and then outputs the file format you want us to persist and get.

So the CMS from the ground up is built with these abstractions in mind that lets you adapt it to a lot of very different use cases and to be very flexible. One thought I'm having here as a developer is I sure hope I can have my content

and my code live in separate repositories. You can do that if you want to. Because does anybody else not want, like, just fix a spelling error on article number 47 in your Git history? Like, the people who are using the CMS side of it. I just feel like there's a lot of commit noise

that would come into your Git history. That's true. By the default setup, you do get some commit noise. But on the other hand, you also get this superpower of being able to see how exactly did your site look like, not just from the theme perspective, but with all the content at any specific point in time. But again, the CMS doesn't care about what you do with the Git repository. So there's also nothing stopping you from creating a separate Git

repository for the code and a separate one for the content and then just manage the content one with the CMS. And we've even talked to one guy that's working on using the CMS to edit a repository just with content that then gets exposed as a static content API and then consumed by a Rails application, right? So the CMS is really just in its essence, a tool for managing persistent structured data in a Git repository with a user-friendly interface for people who don't want to write code. What's the state of this thing?

Is it, I know you'd mentioned that you've kind of broken your own rules, so to speak, as a service to say yeah smashing magazine vitalible i mean who says no to smashing magazine by the way i mean if you get a chance to you know open source some cool stuff and establish some standards as you mentioned open source create standards you get a chance to do that you kind of have to think twice for sure about like, yeah, we should definitely do this. You know, I imagine a lot of this is still sort of proving the concepts, but it sounds like even Smashing Magazine hasn't fully rolled this out yet. So it's at next dot Smashing Magazine dot com. Is this a work in progress? What's the state of this?

Can people pick it up now? Where are we at? So we we are starting to have a lot of people picking it up and we're starting to have even the first external maintainers on the CMS that are not part of Netlify. We've been using it internally for a long time in production. So all of, if you go to netlify.com, you'll see that we have a very active content strategy

with lots of blog posts inside of the week and documentation and so on and that all like we've been dark fooding the cms for a long time now and are using it there obviously like this is a work in progress there's a ton of work going on and there's a ton of improvements coming and there's 10 open pull requests right now. So it's very much a living project, right? But you can start using it now. And for some use cases right now, it will be a really good fit. There's something that we have developers on as well, right?

So we want to keep pushing this and we have dedicated resources just for this going forward because we think that it's worth it, right? And of course, if no one picked it up and no one wanted to contribute and stuff like that, then we would have to say we were barking up the wrong tree. But right now, there seems to be a lot of interest for it. I think because of the reasons that we talked about earlier of accommodating the Git workflow and still giving the content editors an experience

that's not technical and so on, that this might be a real, real thing, right? workflow and still giving the content editors an experience that's not technical and so on, that this might be a real, real thing, right? So at least we're really psyched about it and we keep going. And it can be picked up. And of course, anyone that wants to use this and share whatever they do around it, right? I think in general, with the modern front-end stack, there's so many, like look at static site generators right there's so many custom jekyll installs out there millions where people have done so much work around it but either they're not comfortable or for whatever reason it's not really open source so where the basic tooling is open source the workflows really are so yeah anyone that picks it up we always you know encourage it of course of course you know but but we also really if they

want to share it with the world, then that's even more beautiful. And I should also just say that some of the things we're working on is just also to make it easier to pick it up. For example, writing the configuration YAML file by hand. Now we're working on a UI for that and so on.

We keep pushing to get the initial setup even simpler and we'll probably also push to get more like we have one startup theme right now we'll list that out a bit more and we'll launch more themes with the cms integrated just again to to make it easier to pick up and get started with so right now you're still like if you want to use it it's it's ready to use and you can you can start using it now but you need to be fairly hands-on and of course as we progress it'll just get easier and easier to get started with it is there anything that uh in this conversation that was more Smashing Magazine proprietary kind of stuff that had to be built on top of because

you were obviously building this out and is there anything that wasn't Netlify itself? Netlify CMS I should say actually. The only parts that are proprietary to Smashing is the actual

front end work specific to their design, right? Like, obviously, that's all specific to them. Then we had to write some scripts specific to the migration around, like, how do we get stuff out of their WordPress database with the set of plugins they're using and so on into Hugo, and some of that is very specific but apart from that I would say that everything that's matching is using is is completely open and can be used by other people that's a something worth pointing out which we haven't stressed much but we should definitely give a shout out to

Hugo which is a go based and excited that's super awesome friend of the show Steve is it Francia? You say his last name at Google. He's been on GoTime just recently. I would go as far as saying that the Smashing project itself right now would probably not have been viable without Hugo just because it's pushed the performance of static site generators so far. That with all the articles and all the events and pages

and eBooks and everything, the Hugo part of the Smashing Magazine build for production build is a little more than 10 seconds. Yeah, it really is fast. What we did was also as part of that, and again, so people could take that experience and start using it themselves.

We made a boilerplate that's also open source. It's called Victor Hugo and boilerplate for Epic websites. But it basically packs in an asset pipeline and webpack and so on. So you don't have to install that on the side, but it just works. So it is, of course,

Hugo, but with a little bit of extra functionality there. So it's just easier just to get started. And then we're working on templates as well. We have a few templates already. Just so people can start with the CMS and you go and get something up and running as frictionless as possible.

One last question for you guys before we let you go. Just listening to this conversation and thinking about Jamst and by the way the cms looks spectacular so thanks so much for putting that out there for people to go check out and hopefully contribute back it seems like a nice advancement in these types of things i can't help but think is this is all this movement seems like a reactionary movement to past experiences. You know, like I'm never going to get slashed on it again type of stuff. Or hacker news or Doug

or I don't know what you get anymore. Whatever it is, that influx, right? Because we're all afraid of the concurrent users thing hitting our dynamically rendered page and the database going on fire. We've all had that experience most of us with wordpress and it seems like you guys have referenced wordpress quite a bit uh matt you mentioned how jumala has a bigger uh user base than a lot of these little services

we're talking about which i think is amazing and i just wonder how much of this is a reaction and perhaps in certain cases an overreaction to bad experiences with WordPress whether the the non cached version or a caching plug-in that's given you hell what are your thoughts on that because it seems like you mentioned PHP and WordPress quite a bit as the anti pattern and this is the solution to that problem well I think that's like yeah WordPress is easy because it's 27% of the internet, right? So it's an easy reference and people know it. And WordPress is just an example. There's a lot of monolithic apps out there, but it's just so people sort of have a frame of reference.

But I think there's a lot of answers to this because, yes, one of it is, you know, a few years ago, you couldn't build out your own CDN. A CDN wasn't accessible for anyone else but the ones that could go in and negotiate their own peering agreements with data centers all over the world. And now it is. So that also means that the performance benefits you get from working in this way are becoming really high. So you really get something out of it. But I think there's so many things. There's also the emergence of mobile making performance even more important than ever before. The malware issue is increasing so that, you know, the pain points there are larger and

larger every day. But I also just think that technology matures, right? First of all, JavaScript and browsers have matured to a point where it just makes a lot more sense the more you go on to use these external APIs. Even on most analytic the monolithic apps you you know like facebook comments obviously posted by facebook you use that api so you talk to it from the client you don't run your own comment section as part of your monolithic app anymore so i think uh someone told me the other day there's more than 90 percent of anyone running

a monolithic app will still actually have most of the things that need real-time dynamic updating be connected to from the browser to API. So it's sort of happening anyway. And then you have the Git workflow, right? Like Git is a real thing. And that way of working, I think it's a natural progression of saying,

okay, that's not something that's happening, that happened, right? That is sort of the way that most people work with version control collaborator on code. And accommodating that workflow as much as you can, that's also a natural development of that, right? So I think that there's so many answers here. And there's a lot of planetary alignment here

of microservices, of of uh of micro services of advanced markup and and get workflow of of all these things that are sort of coming together and and yeah all of a sudden being able to actually quite easily push to a global network right so you don't have to have that single point of origin anymore. All of that, all of those possibilities are what's pointing the arrow, so to speak, right now. I think when we look at specific points of the security point, I think

there's a conflation perhaps there because the advantage that you're getting by moving off of a WordPress or a Joomla to a smaller custom thing, whether it's a microservice or a slightly larger custom CMS, is because it's obscurity. It's because there's fuzzers out there hitting slash WP dash admin like crazy.

In fact, Adam might know this very well because we used to be on WordPress ourselves. And one of the things Adam kept asking me is like, how do we lock down our admin? They're just trying to hit our admin at all times. And I said, well, the answer is you just get off of WordPress and now you don't have that problem anymore. But we have a, I mean, for our site,

we have a Phoenix-powered, so it's Elixir CMS that renders every single time. It's dynamic. We routinely have sub-50 millisecond response times. We have a very small footprint. There's the security. We have the obscurity now. We don't very small footprint. There's the security. We have the obscurity now. We don't get hit.

No one's coming after us. And so that's a little bit of a conflation because I think you get that just by moving off of those things and not because of the JAMstack in particular. The surface area, you say you have less surface area, I guess. I mean, there's still

the same amount of functionality requires more or less the same amount of code. And so really you're just saying, well, this code lives over here now and that code lives over there as opposed to all in one place. So maybe you have more obscurity. Performance, anybody who has,

can use varnish, can stay off of the getting slash dotted. So there's workarounds for that. Caching is a thing that works. So that's why I say perhaps there's an overreaction in certain cases. But I do really like the idea of, first of all, the get powered workflow is very nice. I really like the idea of having freedom of choice each time you go to build a new section of your website in the microservices term. But now you also have an orchestration problem. So there are trade-offs going on here, right? each time you go to build a new section of your website in the microservices term.

But now you also have an orchestration problem. So there are trade-offs going on here, right? Of course. Any architecture will always have trade-offs, right? That's just inevitable, right? Obviously, we're doing this because we think that the trade-offs are really, really worth it for a very, very large amount of projects. Then there's some projects where they won't be worth it

and there's some projects where these constraints are not a good fit. But I think from my point of view and also as someone that sort of, before we started building Netlify, I was building a fully hosted content management system called WebPop, which was a dynamic system, right? And that started sort of at the time where I saw everything starting to change in front

end development. But I just think really I learned from building in Spain tens of thousands of websites and with WebPop, a fully hosted platform for thousands of web projects, they were not really in the vast, in terms of just automatically getting the performance, and also in terms of creating a cleaner architecture where the services that need to run during a visit are very isolated, and you're very aware of those, and the rest is just pre-built. I think from my experience, this is a very healthy set of constraints. Also think that what we see is that again and again, you talk about security, for sure.

To address that, that definitely helps. If no one's targeting you, then there's not a malware issue. Malware can be something that infects a build phase, but the build phase has to go on. Someone can hack your site by themselves and try to get your password and stuff like that. something that infects a build phase, but the build phase has to sort of, has to go on, right? Someone can hack your site by themselves and try to guess your password and stuff like that, but 99.9999% is completely automated.

And malware has to infect the build process. So if there is no build process, as soon as you remove that, of course, that means that you're taking away the service area of tech. Then you're reintroducing them via APIs. And that's the question of, are they smaller and more specified

so they don't get the same attention and by that living obscurity? And then there's also the question of, you don't necessarily have to run all the APIs depending on how the usage is of the site. Whereas in a traditional site, you will have to run something no matter what, in order just even to serve the HTML.

A bound performance, what we see is that have to run something no matter what, even to serve the HTML. A bound performance, what we see is that you can have these fantastically optimized sites, but if you look at the global traffic, then if it's the server in New York, then time to first byte and stuff like that is really low. But then if you go to security or test my

site.io or something like that, and you test it from different points around the globe, then you'll often see, okay, well, any traffic coming to Tokyo or something like that, it's a lot longer. That's because, you know, a CDN and Vanish cache and stuff like that can be great also for caching some things, but not necessarily all of them. And very often the HTML and the time to first byte has that round trip to the origin server included.

So even the ones that, and some of them we know that, you know, from talking to them that are spending like, and I've seen the amount of money every month, like tens of thousands of dollars on their setup and some way more than that. And they still have like, you know, much to be left aside when it comes to initial loads times, especially globally.

So, you know, your points are super valid, but there's that to take into consideration. And the other thing about Matt is just having something where you don't have to worry about it. In agencies, we're always doing this hosting provisioning, but we didn't actually know how much traffic that was going to be there. But, you know, if you put it in some cheap host and it did go down, then you would sort of be, there would be hell to pay, right? So you left it on something bigger and then even then, like three or four times a year, it went wrong because, you know,

there was a viral element and it really went off, right? And I feel that having something where you can just automatically push it, no matter if it's a small landing page that just, you know, wants to set up samples for detergents and only is accessed by a QR code in a few local

supermarkets, right? And basically gets a few hits a day or it's your own personal blog post, or if it's something that's getting millions of hits every day, knowing that you can have like sort of a default setup and just work with it because it's, you know, Jamstack based because it has multiple borages because it doesn't have that thing that has to rent every time. Then I feel it's a pretty powerful thing. Absolutely. I think one of the places where this style of application has lacked is in tooling and available libraries and stuff, which is why we're super happy that you guys and people

like you are working on open source tooling and building out the ecosystem of microservices that people can start with. And so we actually have more viable ways of getting these dynamic yet static Jamstack sites without having to give up all the dynamism, which makes the web so interesting. So for that, we're thankful. I couldn't say that better myself. That's not the thankful part. But saying that, you know, retaining all the stuff that's great about the web right having all that personalization and all those those those services but at the same time doing it you know scaling in a in a viable manner that's the goal absolutely the best place then to go to to get started you do have some pretty good documentation i say pretty

it not as a degradation, but a compliment. Good documentation. Got a quick start at netlifycms.org. So we'll link those up in the show notes. We didn't quite cover getting started, but we'll leave that for the docs because they are just that good. Thank you very much for coming on the show today. Cheers.

All right. That wraps up this episode of The Change Log. Thanks to our sponsors, Linode, TopTile, and also GoCD for sponsoring the show. Also, thanks to Fastly, our CDM partner. Head to Fastly.com to learn more. Our music is produced by the mysterious

Breakmaster Cylinder, and our episodes are edited by Jonathan Youngblood. We'll see you again next week. Thanks for listening. you