Introduction

[00:00:00]
>> Today, we are going to be learning about the Jamstack. And we're gonna do kind of a crash course through some of the concepts that we can follow. We're gonna be making some assumptions about the stack that we use, just to make things a little more expedient. So I am in far more experienced in Gatsby than anything else, so I'll be using that for a lot of the examples.

[00:00:24]
That does not mean that you have to use Gatsby if you want to use the Jamstack, that's just my preference. You can use any amount of JavaScript, from vanilla through your framework of choice if you wanna do a Jamstack site. So a little bit of information about me.

[00:00:41]
My name is Jason. I've been lucky enough to make a career out of learning and teaching. I currently am a principal developer experience engineer at Netlify. Prior to that I was the head of developer relations at Gatsby. Before that, I was a frontend architect at IBM. I've been doing this stuff for a long time, and still loving it after all these years, so very excited to be here and teaching.

[00:01:05]
I also run a regular live stream on Twitch. It is a pair programming show where I bring somebody from the community on and they teach me something. And we build it live in about 90 minutes. I put these on two to three times a week. It's a whole lot of fun.

[00:01:21]
And so if you're interested in tagging along, we've got live chat. You can do things like play sound effects and mess with me while we code. It tends to be very unstructured and chaotic, which is kind of the way I like it. So [LAUGH], if that's your bag, come and learn along.

[00:01:38]
So to start, what is the Jamstack? Specifically speaking, Jamstack is an acronym and then a nonsense buzzword, it stands for JavaScript, API's and markup. And stack is just what you call the list of tools that you use. So what this kind of means in practice is that you're taking JavaScript on the client-side and you're using that to call APIs which then updates your markup.

[00:02:09]
There are some kind of, that's the broader strokes, right? So if we put this another way, the Jamstack is an approach to web design that emphasizes shipping only static assets. And what that helps us do is eliminate a whole bunch of complexity. So I know that a lot of folks in here are frontend developers.

[00:02:31]
So one of the problems that I have is, how many of you are frontend developers but you've found yourselves writing Node servers, or deploying things to containers, or things like that? Right, there are a few hands. I'm sure that people watching on the stream are screaming right now.

[00:02:44]
This is my job. When I went to IBM, I found myself on a frontend team, but the vast majority of time that we spent was on trying to write API proxies, on getting our Node containers set up, on figuring out how to write Nginx and Kubernetes code. So that we could deploy our frontend services.

[00:03:03]
But ultimately, there was no server logic. We were just trying to write all of the server code to get some static files up onto the Internet. So what the Jamstack does is it says, just skip all that, don't do that, build static assets and put those static assets on cloud storage, some kind of CDN.

[00:03:22]
And just let that be the website, you don't need to have a server, you don't need to have a bunch of containers or Kubernetes, or any of those things. Those are tools to solve a specific job, but it feels a little bit right now, especially at bigger companies, that Kubernetes is the hammer and everything is now a nail.

[00:03:38]
So Jamstack is a way to give us an alternative to that. We don't have to become full stack developers to ship something to production. So why this is important is it opens up a lot of doors for us. So some of the benefits that we'll see is a huge amount of reduced complexity.

[00:03:58]
Because we're only shipping static assets, we don't need to worry about what a Vagrant cache is or how it works. We don't need to worry about Apache, or Tomcat, or Nginx, or any of those things that you've probably stumbled into. And like, I have no idea what this is, but I know I need it.

[00:04:13]
We don't have to figure out how to stand up PHP or Ruby, or Node, or Go, or whatever your backend is. We can just write HTML, JavaScript, and CSS, and put that on the Internet, that's the whole process. So it takes a ton of steps out, a lot of cognitive overhead.

[00:04:31]
They are also dramatically lower costs. When you run a server, a server costs money. It has to be up 100% of the time and it needs to be scalable and available. That means that if you have high load, you have to start paying for scaling, you have to start paying for horizontal scaling.

[00:04:51]
And higher load and more memory and processors to handle more visitors. All of those things add up to a whole lot of overhead. In addition to that, you'll find yourself spending a lot of money on people, right? We also ship faster. So you're able to get something to the browser significantly faster when all you have to do is write some code and then put it up in a CDN bucket.

[00:05:18]
Your possibility for failure goes way down, which means that you can ship more confidently, and it's easier to rollback, which means that you can just try it. And the bailout is really easy, it's not expensive to do that. It also gives us increased autonomy. When you've got a frontend developer who doesn't have to be a full stack developer to ship to production, they can put things out there quickly.

[00:05:38]
They can handle a project from beginning to end. So let's kind of dive into what that means. So reduce complexity, in a traditional app, you would need, in addition to your friend, you've probably got some kind of a server. In front of that server, you've got a load balancer.

[00:05:55]
Maybe you've got some kind of a caching layer. And then behind your server, you've probably got a database. And all of those things need to be up, configured properly, high performance and scalable. Because if you get a lot of traffic at one time, any one of those points of failure can take on your whole website.

[00:06:13]
When you have only a CDN, when you're only shipping static assets, that's a single point of failure. But CDNs, in a traditional web sack, are the least risky part. They're the thing that's most designed to handle scale and most designed to handle huge spikes in traffic. So you're taking your lowest risk point of failure and making it the only thing you have to worry about.

[00:06:35]
So in the vast majority of cases until you get into some really intense levels of traffic, CDNs are kind of a solved problem. We don't have to worry about them, we throw our static assets up and AWS or Azure Cloud object storage or Google Cloud object storage, they just handle it for us.

[00:06:53]
It just works. When we get to lower costs, CDNs typically are extremely cheap. And in a lot of cases they're free. If you're using something like Netlify, you're not gonna pay for it. You have to use quite a bit of the Netlify service before you're gonna crossover into paid territory.

[00:07:11]
AWS has a really low cost. And most of the competitors out there, CDNs are commodity now, it's more of a race towards the bottom. So, the cost to us as developers, as consumers, is extremely low. And in a lot of cases, free. And on top of that, when we look at the lowered complexity, because we're not hiring someone to be a full-time DevOps stack tweaker, now we are able to allocate those resources elsewhere.

[00:07:40]
And it's just fewer things to manage, it's fewer hours to put in to keeping our apps alive and healthy. And that means that we're spending less to do more. We're focused on features, not on the foundation, on the the kind of the periphery that keeps the app alive.

[00:07:57]
When we have fewer moving parts, you can get things out the door very quickly. And I already talked about this a little bit, but to just reiterate the importance of this, when you are only editing static files, that it works on my machine thing is actually a pretty good indication that it works.

[00:08:17]
You can put it up on a CDN and see a preview. I think a lot of the big cloud providers out there now are offering this kind of Git-based deploy where you open up a pull request and you can see what that's gonna look like. And open it in all the browsers, run it through your browser stack, like Internet Explorer and Edge and all those, to make sure that it looks right on all the browsers.

[00:08:39]
And once you're sure, you just ship it, it just goes live. You don't have to worry about these big heavy blue-green deploys and necessary rollbacks and all those things. You can still do all that, that it's definitely not off the table. But you don't have to care what it is.

[00:08:52]
If I just said that and you're like, what the hell's a blue-green deploy, that's okay, you don't need to worry about it. [LAUGH] Jamstack takes that off your plate. The increased autonomy is probably the thing that made the biggest impact for me. So when I went to IBM, my team was one of 37 that was working on the IBM Cloud Platform.

[00:09:13]
And what we found was that there was this really cumbersome deployment process. Where you would pull a production branch and then you would put it into a queue and then you would have to go to somebody on another team and ask them to review it. And then they would put it in another queue and then on Thursdays it would go live.

[00:09:31]
And that's not necessarily a bad flow. I think for a lot of large companies that's actually a really good flow. I've heard of much scarier processes elsewhere. But what I saw was that when we switched over to some Jamstack experiments, our team was able to deploy continuously. They would make a change, and as soon as that pull request got merged, those changes were in production hours later.

[00:09:54]
And that was night and day. We started getting called into meetings where management wouldn't believe the numbers that we were giving them, on how quickly we were shipping things, on how fast things were getting through. They were like, what are you skipping? Go ahead.
>> So is Jamstack cloud platform agnostic?

[00:10:13]
Or can you use it with AWS, Azure, whatever you want?
>> Exactly.
>> And also, can you use it with internal hosted servers, someone with an in-house, non-cloud, on-prem server?
>> Absolutely. I mean, if you wanna go to the simplest possible implementation, you could open up your FTP client and go to whatever server or whatever, a server in your basement, if you want.

[00:10:38]
And you can say, put these files in this folder and then make it addressable on at this URL. That's a Jamstack site. So the the cloud providers make the wide availability and the CDN part much easier, but it's certainly not a requirement. So the autonomy will make a huge difference here.

[00:11:02]
It really is, especially if you're used to working on a team that's got a longer deployment process, it's gonna feel like cheating. It's like finding the cheat codes. There are a lot of additional benefits that we'll kind of look through as we get to them today, but one of them is better security.

[00:11:20]
If you're only shipping static assets, there is no server to attack, there is no database to attack. So the worst case scenario is that somebody can deface the site if they get access to it, but they can't get access to your data. They can't go and steal user data unless you've put that user data into your static files, which, that would be a different problem, that's not an attack vector, that’s you being irresponsible.

[00:11:46]
[LAUGH] And so that really cuts down on your risks quite a bit. You also get better performance. When you are only shipping static assets, you have fewer round trips. On a typical site, you would maybe go from the browser to a load balancer, to a server, to a database, back to the server, back to the browser.

[00:12:11]
And you find yourself kind of, there's just a lot of hops, right? And each request has a little bit of overhead, just slows things down. When you're only putting up a CDN request, you're going one hop, it's from the browser to the CDN and back. And typically the CDNs are set up to be geographically near the people that are requesting them.

[00:12:29]
So that means that instead of waiting for someone in Australia's signal, restricted by the speed of light to get all the way around to San Francisco and then all the way back with all the intermediate hops in between. They're in Sydney, they hit the Sydney data center and there's 15 milliseconds of overhead there.

[00:12:49]
And it's really, really nice. You really can feel the difference when you're using the Jamstack versus a kind of slower traditional stack. And now that's not to say that you can't solve these problems with servers, you definitely can. It's just significantly harder. You get better reliability, talked on this a little bit.

[00:13:12]
But when you don't have a server that can fail, when you don't have a database that can fail, when you don't have a Varnish cache that can be misconfigured and break everything, then those can't go down. You only have the CDN and CDNs very rarely go down. And when they do, it's national news.

[00:13:29]
The whole Internet goes down. So you have significantly lower risks of being DDoS'd, of hitting the front page of some website and having a new spike of traffic that takes down your server because it can't handle 1,000 simultaneous requests. Those problems are all significantly reduced when you're working with static assets only.

[00:13:55]
And then scalability, again, because you're only using a CDN and CDNs are designed for scale, it just does it. You put it up in a cloud bucket and they will automatically distribute those files, they will handle auto scaling of resources if you get a spike in traffic. And it doesn't mean these problems go away, it just means that they're not managed by you anymore.

[00:14:18]
And typically speaking, they're managed by people who are extraordinarily good at it. I've talked to the the engineers at Akamai and Fastly and they start to explain what they do and my eyes gloss over and my brain starts to melt out of my ears. And I realize that I am not the one who should be trying to handle my scaling.

[00:14:35]
[LAUGH]