And I'm really relying on you as capable developers, as people with experience in React, to figure out stuff on your own, ask questions, help each other, and we're definitely not gonna finish much today. I just want you to get your feet wet and understand what is possible so that you can go figure it out yourself. This is all I can do in three hours. So, a bit about myself. I have done React for two years, Gatsby for one year, briefly joined the Gatsby team, working on some internal stuff, and then got a better offer at Netlify. But I think that Gatsby is a significant innovation in the React space. I think it helps counter a lot of the problems with React and people yell about JavaScript frameworks being heavy and having issues with performance. I think this really solves that, just like Next.js as well, but in a different way. And we'll talk a little bit about why Jamstack. I think a lot of people are confused by this term. I was confused, even when I joined Netlify. Netlify is not the creator of Jamstack, but strongly promotes it because it's a CDN first hosting company. But I'm not here to talk about Netlify, I'm just here to talk about the idea in general and whether, what use cases it suits. Okay, so hopefully everyone has downloaded this GitHub. repo. We're about to get started. The first thing I want you to do is to immediately go to the GitHub repo. Where is it? Okay, so we have notes in a sample site in the GitHub repo. And inside the notes. This will take a while so I just want you to get started with it first. There's a welcome page. It just lists the lesson plan for today, as well as some basics that you probably already have. And then if you go to the first one, the intro to Jamstack. So I'm gonna ask you to kick off a build while we talk so that you can see the whole process start to finish. So I'm gonna just click to deploy my dimension starter. It's gonna link to the Amplify console. That's the tool that we're using for today. Hopefully everyone has an AWS account. If not, this is where you start signing in and all that. It may require a credit card, I'm not sure, but I mean virtually everyone uses AWS. And if not, you can use Netlify. Netlify does not require a credit card, but I'm basing on AWS today. So if you log in, you get to this flow. It's basically just gonna deploy that site that we chose. And we're just gonna click connect to GitHub. I'm already connected. You may need to log in on your own. It says GitHub authorization was successful for me. Again, if you're not logged in, and if you're doing this for the first time, you may need to do some authorization. I'm gonna go with the default name. I don't think I have this default name already. And yep, and it's creating my app. Okay, so I want you to do that. This is the dimension starter. We're also gonna clone overreactor.io. If everyone knows that's Danny from the React Core team. I'm also gonna clone that. Let's just do it. So I opened that link in the intro to Jamstack Notes. Is anyone lost? Reach your hand? Okay. Who's lost? Okay, where did I lose you? Sorry? The AWS team. Yeah, you click this link and it opens to a new window. And you just follow the instructions all the way through. Where's the link? The link is in Jamstack Jumpstart Notes 01. Intro to Jamstack. Yes. If you don't, you can choose to sign up for one or you can try to use Netlify as well. But I won't be teaching that today. I can cover that later on. I realized, again, I realized I should have put that in the instructions. People should sign up for AWS first. So apologies for that. I didn't really, I think I just assumed that people would have it. Okay, and if you're lost, I try to ask someone next to you. Okay, so I'm just going to deploy those two sites. There's other sites that you can deploy as well. But I just want to give you the sense of that's all the work it takes to start deployment in a Jamstack world. It really is, you're taking that source code, you're copying, you're cloning it over and you're pushing it to the servers. And it's very, it's very light. Oh, the one we've overreacted at IO, you've got to change the name of it because they don't allow dots in the name. So I'm going to clone this again. This is the overreactor.io clone. If you look at the URL, it's too small for you to see but it has, it's just a GitHub thing. That's all the link does. So I click connect to GitHub. And instead of that name, I'm going to change that name to something else that has no dots in it. Things are very slow suddenly.  Okay, overreactor.io.jsconf, whatever. Just no dots in the name. I already complained to AWS about the validation there. They should validate properly. Okay, so I just want you to get started. That thing will be building and kicking off. And we'll talk about that later. But now I just need to give you this intro to Jamstack. All of you already saw this. Don't worry about it. What is Jamstack? Jamstack stands for JavaScript APIs and mockup. And that's a very silly name, right? Every app uses JavaScript APIs and mockup in some way. Why is this such a big deal? And so I want to give you the context from where we're coming from and try to make sense of what this all is. So in the beginning, the very first website was a Jamstack site, right? This is from, I think CERN. And it was just vanilla HTML and just some links and you could link around. And then we needed more and then I'm just gonna have more memes because I like some presentation stuff. And then we needed more and we started serving things from an origin server. And then we wanted more dynamic capability. So we wanted to have a program running behind it to dynamically generate some sites. So for example, I can have a counter and it shows the current time as of the time that you visited. Should I be sitting down? I feel like you can actually see it. So then we all need some persistence. So we started adding databases behind the server. And that's how you get Wikipedia, for example. Right? But then there's a problem with this. And so the open source stack to all of this is basically became lambda. That was the dominant paradigm from 1990s to 2000. Towards the late parts of 2000s, we started with one more dynamic stuff on the client side, the front end. So we started to innovate on the JavaScript angle. Notice there was no JavaScript in any of this. And now there's a little bit of JavaScript on the client side. We started using move tools, jQuery, YUI, whatever. And eventually we started to run into problems with this stack because we start to have scaling issues. And so we have to throw in some caching at intermediate layers. We have different names for all of these caches, like red is or whatever. And then we introduced this idea of a CDN. We put a CDN in front of our origin layer. A lot of you have done this in your own setup. And a lot of you just haven't worried about it. But these are the kinds of things that start to be introduced at scale. And you start having all these problems with monitoring, versioning, replication, fingerprinting, and even more, like security stuff. Basically, when you run to raise money from a VC, you make a deck like this. And you put the text, like, slightly askew. And you say, pain points. These are the pain points that we saw. So basically, what is the pain points? What's the origin of all this? This is modern infrastructure that we build up piece by piece. Never really plan for it to all stick together. And what is the source of it? It's really basically the running server. We have to scale it. We have to manage it. It'd be ideal if we don't. So it really boils down to security, reliability, and complexity, which is correlated with cost. I have a link, actually, from, does everyone know who Westboss is? Westboss is one of the best JS developers in the world. He runs a server. And when people order his stickers, his server crashes. And server slowness, you folks totally crash my server. Someone was trying to subscribe to his course. The server crashed, so he lost the login. Making your own server is hard. His own site 404 is just because he just set it up wrong. Like, experts get it wrong. How can we make it easier, right? So that's the context that we start from. The other thing that started happening is JavaScript started eating the world, right? We went from JavaScript in front end. We had all these, like, it was a toy language from ES1, ES2, ES3, and then there was 10 years that we did nothing. And then now we have a yearly cadence in TC39. It's actually a pretty serious organization. Will Smith again. OK, so then we started breaking, trying to break apart the, so we had frameworks come out of it. We went from jQuery to backbone knockout Angular. And then we also started eating the, we looked at the back end and we said, why you know JavaScript? So obviously, we started turning out JavaScript on the back end, popularized by MongoDB, with Mongo Express, Angular, and Node. And so now we have this full JavaScript landscape, by full stack JS, which is, like, that's kind of what I like to talk about at a JSConf, like, JavaScript slowly, if anything can be rewritten in JavaScript, it will be. That's called Edward's Law. He's one of the co-founders of Stack Overflow. So this all is fine, but we're just reinventing little parts of, like, the lab stack, just like replacing parts of it with JS. And that's why we have the myth of the full stack developer, like, having to know everything from Postgres all the way to CSS. So the problems with this, like, we've only replaced the lamp stack with, like, JS versions of the lamp stack. We haven't really done anything. We still have this, we have different logos, but we have the same sort of caching and security issues. So, and the big one is performance, the bigger and bigger JS bundles on the front end get the more load it has, especially for mobile users. I'm sure everyone here knows about that. The performance study is all the scared numbers, but my favorite is the 4% of mobile users who throw their phones while waiting and being super, super frustrated. Yeah, I value, but I have a very thick case on my phone, so it's very drop proof, but yeah, I can probably throw it if I want to. According to Alex Russell on the Google Chrome Dev Routes, the ideal budget for your first load should be 130, 270 kb of critical path resources. Let's just call it all JavaScript.  More after compression. Before, because they care about parsing time as well. That's the time the interactive. It all counts in there. We'll have some charts as well. So this is literally during the math. If on a 3G network, you want to have a five second load, you work backwards on the transfer rates, you set a budget of 130 to 170. I recommend this blog post. It's a pretty good read on where you need to be in terms of performance budgets. Conversely, this is a log of general JavaScript bundles overall. We passed that 130, 170 kb mark in 2011. We're currently now at 400 kb for the median desktop and mobile bundle.  When React Scripts, what React Scripts does is just it generates a fat JavaScript bundle for you, right? Does a little bit of code splitting, but that's it. So it would be nice to improve the performance and the time-term interactive of there. And so this is kind of the performance issues that we start dealing with. We have the initial request. This is the original nice request.  It really blocks the time to be able to render this.  By default, Create React that gives you an empty div. It's just a blank white page. It's not very good for SEO and not very good for performance as well, because everything is just stuffed in your JavaScript, everything that you write. So that's the client-side rendering paradigm. This is kind of the chart where you have your get.  You get the bundle back, and you're rendering. This is all blocking, and therefore your time-term interactive is very far out. FCP is first-contentful pain. So as opposed to server-side rendering, why a lot of people move to Next.js is because you just have to get requests. They render on a server, and then they send you the server-side rendered HTML. And therefore, there's no client-side rendering to be executed before your site is interactive. So the mean stack actually worsened from the lamp stack in terms of it has the same issues as security, reliability, complexity, and cost. And then it added a performance thing on the front end. Not great, not great. It's very good news for JavaScript engineers, because then we're just employed everywhere, which is really nice. So there's a spectrum, but I think those are not the only two choices, and that's what we're all here to learn. There's the full client-side rendering on one end, and then there's full server-side rendering on the other end. There's a space in the middle to do other stuff. So we'll talk about that. That chart is from Google, by the way. Meanwhile, all this is going on. I've just told a story of the past 20-something years. Meanwhile, all this is going on. Other stuff is happening in development ecosystem as well. The API economy rose as well. So these are all companies that don't have direct customers. Their customers are you guys.   You should not be. My favorite is PLAD. A lot of people here don't know PLAD, but PLAD basically integrates with all banks in the US. I don't know if they're in Europe as well. But basically, if you want to deduct money to start up like a Robin Hood, you just integrate with PLAD, and immediately your customers can just send you money from their bank accounts. It's amazing. This is stuff that you don't want to build yourself. So all these APIs are just available for you to interact with. So then it's like, OK, the jobs of a backend developer or of a product developer is increasingly decreased. The undifferentiated stuff, you don't have to do. The stuff that really makes your company stand out, your project stand out, that's the stuff that you should be focusing on. And just pay these guys to do the rest, because they're just specialist at it. The other trend, serverless, launched in 2014 by AWS Lambda, but there was also Google App Engine before that, and quickly cloned by the other two big giants, Google and Microsoft. So that's GCP, and that's Azure. Other way around. Everyone started using Git 10 years ago. People, Git wasn't a normal thing. So we wanted to take advantage of all of this to try to see what all these trends are. Everyone started using build tools. We went from an age of just including scripts into actually putting these things in our build processes, and it's part of our CI and CD process. Anyone know? Let's play. Obviously, this is our favorite over here. What's this on the right? Roll up. Roll up? OK. What's this? ESLint. ESLint, very nice. This one, this is the challenging one. So this is Google Closure Compiler. It's the one that React actually uses to compile some source code to actually deliverable. So then at Netlify, we started looking at all these static site generators as well. It's a rising trend of basically build tools coupled with Git workflow, coupled with all these other stuff. And we realized something that was very non-consensus at the time, which is static site generators are the next big thing. It's rising, and people are actually using it to do some pretty interesting stuff, especially with the new generation of static site generators like Gatsby. You're not just generating static HTML, like Jekyll, Hugo, those are the first generation. Just generate a static HTML. That's it, you're done. With Gatsby, you're generating HTML, sending it, and then you're also generating a JS bundle and rehydrating it so it becomes an app. We use staticgen.com to track all these static generators. And it takes advantage of this new generation. I just jumped ahead of myself. I'm sorry, over there. A lot of people don't know what rehydration is. So it's this process of we switch around the client-side app thing. So we have the initial request. And when we send the HTML, it already looks like that. There's a shell of everything that's pre-rendered. The perceived performance, the perceived loading, is super fast. ViewPainted, it can be, oh, actually, yeah. So this is still HTML, ViewPainting. And then JavaScript, by the time the JavaScript bundle arrives, it can actually become a dynamically loaded app. There's an uncanny valley here where JavaScript is taking over and rehydrating all the elements on the HTML. And that's a problem that Google is actively working with the two main, with Gatsby and Next.js to solve, which is the uncanny valley. Most of us don't care about this detailed performance because it's on the order of hundreds of milliseconds. Milliseconds. So anyway, just to tie it all up, all these trends, Git workflow, build tools, serverless, API economy stack sites, that is the Jamstack. That's what enables the Jamstack now versus 20 years ago. So the focus is really on user experience. We just want to send markup and JavaScript to your user. You ping APIs if you need to to generate that markup. But then once the app is on the user side, you just interact with APIs on your own with JavaScript. There's no running server to interact with. The best parallel I can say about this is basically mobile apps. Mobile apps are all static assets, but no one accuses them of being static. They're all dynamic as you want. Will Smith again. And that kind of follows the purple pattern, push, pull. I actually don't really know what the PRPL stands for. But these are all best practices according to Google. I honestly don't care enough. You're not going to code all this by yourself. You just want to use a firmware that does it for you. And that's what Gatsby does. By the way, that's why their color theme is purple. So in comparison of all the rendering paradigms, static rendering is the easiest because you do all the work upfront ahead of time. And when the request comes in, you just send HTML. Whereas server-side rendering is a little bit slower because you do the work on request. When you send a request, work is done, and then the render comes to you. And obviously, client-side rendering is the slowest. So that's the full spectrum. I honestly, I recommend this blog post by Adios Mani again, rendering on the web. He goes into a lot more detail about how you can pick the right level of dynamism for your project and your performance needs. And I like talking about what is gemstack and what is not gemstack so you can understand. These are gemstacks, static hosts. So Netlify is on there as well, and Amplify Console as well. S3 bucket, GitHub Pages. What is not gemstack is WordPress, Drupal, any running server-side-oriented things. Yeah, I could probably do this slide better. I should put a non-gemstack. The original gemstack site, this is still up. I have this romantic idea of the unbreakable web, like the website where you don't have to keep a running server around. This is the original Space Jam website, and it's still around. It's been around for 20 years. It will be around for many more because it's just static assets, and we can keep that forever. And so that's the rough intro. I think I don't have that much time to skip ahead. There's a trend also of headless CMS. Those of you who work for agencies will be very familiar with the... So this is the rough setup, which is when we're building, we use Git to push through our static-side hosts, and we can pull in from headless CMSs or whatever content sources we want. They can be markdown files. They can be APIs that we run, or it's someone that we hire to do that. So headless WordPress, Ghost is a major CMS as well. Contentful, some of you have used it. I think you. Scruvito, these are all very, very focused on agency use cases. If you need to set up a site for a non-technical user to start editing content, and you're the developer that you're contracted as a freelancer or something, and then you hand it off, I think this is really good. Or if you just... For me personally, I can do all my content on Airtable, and it just pulls in from Airtable as well. So I really like all that, and it's all collected on headless CMS. Where Gatsby comes in is... Gatsby regards this as all the content mesh. This is their word for it. Again, their blog posts journey to the content mesh is their VC pitch, basically, like what is going on in terms of... Why is this an investable trend? And basically saying all these content systems will ingest it into GraphQL, will run it through our React server or build tool, and then we'll push it out to static hosting, which is amplify all this hosting. So that's the rough idea. This is... This is Brendan Eich. He always bet on JavaScript, so I've sort of taken his quote and just made it into always bet on Jamstack. So that's the rough intro to Jamstack. Like why is a trend? Why people care about it?  In fact, I think JavaScript and APIs are the most boring parts of Jamstack. Actually, Markup is the more interesting thing, because Markup is no longer static Markup. It's Markup that's being run on the server and then again on the client. And that's exactly what Gatsby does. So I think now we're at a point where... So we just finished the intro to Jamstack piece. You can have more reading over here. I have more information and links. I really like Chris Coyer's talk about the all-powerful front-end developer. Basically, the more you can do serverlessly, the less you need to do on the server side, and therefore the more you can do as a front-end developer, as a product developer, as a JS developer. So I really like that. Okay, so what I'm gonna have everyone do now is check their Amplify console. So everything should have deployed already. And if you see over here in my console, when we started this session, you should already have this deployed. More or less everyone sees the same page. And when you click on this, you can actually see the deployed site. It's at some random hash and it's something.amplifyapp.com, something like that. Yeah? Cool. Now I'm also gonna go over to my overreacted IO clone. Again, that is the same thing. I've cloned Danny Romoff's blog just by clicking a few buttons, right? So like the potential of Jamstack is that you're just, everything is Git-based and you can, if it's open-source, you can fork it and you can deploy it very easily. It costs you nothing. And now the main thing I want you to do is it not just cloned, it also forked it to your GitHub. That's why you had the GitHub connection. So over down here, there's a link to your GitHub. So if you click over there, it links to that fork of GitHub that they created for you. And now you can change anything in the content. So let's say, I'm going to change where's the content? Source, Pages. And this is the overreacted IO source and this is a Gatsby site, by the way. Everything we're cloning is a Gatsby site. Let's say I wanna change the title of this blog post, name it and they will come. I'm just gonna change it over here, index.md, change it and say, hello, JSConf Asia. Notice I'm working entirely inside of GitHub. So what this is doing right now is I just committed that change to Git, right? You can do the same thing for the Gatsby started dimension as well. You can change your markdown files, you can change JavaScript, it doesn't matter. What this actually does is that it will start to kick off that build. Right. And this is the process. It starts to provision a build bot for you, basically like a build server. It will run Gatsby build on your project. It will deploy your site and it will verify by checking, by taking some screenshots. If you go back to the build history, you can see our original build. This build is just kicked off based on my updating of my markdown file.  There's no backend because I didn't deploy a backend. But they also verify by generating all these screenshots. So you can see that you're deploying what you expect. Yeah, this is my clone of overreactor.io. Didn't take very much. And that's the potential of Jamstack. I think that if everything is Git-based, that's the ultimate version control for both your app as well as your content and both can go in-step with each other, which is very nice. Okay, so yeah, that's the first piece. I just want to pause here and ask if there's anyone with questions, if they're lost. I've been talking for a bit. No? Okay. All right, so now we're gonna go to the intro to Gatsby part because now you have two Gatsby sites. You have this site, which is the starter dimension site. And this was created for you by just clicking that button, right? You have the overreactor.io site. And this was created for you again by that. These are examples or more complicated. Overreactor.io is very complicated. There are Gatsby known, has like 200 lines of just configuration. And I'm gonna teach you how to read all this. That's the hard part. But what we're gonna do now is we're gonna go to part two, which is the intro to Gatsby. Okay, so this one I don't have slides, but I just have a rough idea. So what is Gatsby? Gatsby is a site for creating websites with RGS. Okay, so I'm just gonna switch over to the thing here. So what's important about knowing to know about Gatsby? So Gatsby takes content, like all sorts of content. Let's just have different kinds of content. So let's just have like images, JSON files, markdown, some API requests. For example, if you wanna run a shop on Gatsby, you can ping the Shopify API, ask what's available and feed that in. So all of these become nodes. I'm gonna show you how to do that in a minute. All of these become nodes. Some of them need to be transformed. So an image may need to be transformed into for resizing for optimal image compression. So like better image, I don't know. JSON doesn't need any transform, so it just goes straight to. Markdown needs transformations from markdown into HTML based on markdown. So you have a remark transformer. APIs, also you're fine. You may need to log in and have some authentication here. But basically, the idea is to take all these nodes and wrap them up into a single GraphQL layer. And then from the GraphQL, everything is fungible, everything is kind of requestable from each other. You can have pages. So this slash pages folder is a special magic folder. Inside of this, every single page like about.js, index.js, every single page can make a GraphQL request, request any single one of these things. So we're using GraphQL as a unified data layer, right? With type checking and you can prototype the data as well that you get from this. And so there's this guy and then there's Gatsby node.js. So pages are just by convention. It would just run through everything for you.  Instead I'm gonna have a template. Day template.js. Inside of my Gatsby node, I'm gonna say, take all these markdown files and run it through Gatsby.js and programmatically generate page one, two, three, four, five, as many as I want. Same thing for images, same thing for JSON. Basically, standard format for consuming all this, coming into here, GraphQL. And then this is all react, right? You're requesting it. So it does one server-side render into HTML, as well as a whole bunch of different JavaScript bundles. Sorry, so there's a lot of different HTML as well. So every single route has its own HTML folder. So if you turn JavaScript off, if your SEO is, if your search engine doesn't run your JavaScript, it's fine because it can read everything on your page. But then it also generates the JavaScript bundles so that on the client side, it rehydrates into a full single-page app. So as you navigate from index to about, it no longer requires the HTML because it just requires the remaining data that it needs. Okay, so hopefully that was like, this is the first time I ever did that, but. Am I missing anything? No, I think I'll just show you. Okay, so this is the exercise that I'm gonna hopefully get you to start. I hope it won't go off the rails that quickly, but we'll see. So the repo I had you clone has notes, right? And that's the thing that you've been reading, but it also has a site. So over on the site, I think I've left, I filled in quite a lot of stuff, but I want you to be able to fill stuff in yourself. If you MPM install the dependencies inside of site, actually I'm just gonna go ahead and just, sorry? Is this it? That's all I know, I'm sure it's true. Yeah, I've had that in my mind. No, I think I, so what I did was I had a git subtree by accident, so I just need to remove git, get in it, get in. Sorry, sorry about that. I wasn't hiding things from you on purpose. Okay, so if you git pull again, git pull force, it should be, yep, I see the site on the site now. Okay, cool. So we're not gonna go to the data stuff and I left, let's just nuke, let's just go into source slash pages. Can everyone see this? Oh, this is dark. Okay, color theme, light, much better, right?  So I'm in source slash index.js, source slash pages slash index.js, right? And I'm just gonna have this simple thing here saying page one. And that's all the, that's all I need to do to get this started. So make sure to install MPM install so that all the dependencies are installed as well. Sorry, I'm not very well organized. But, all right, I'm gonna run you on start and kick that off. The main thing it runs is Gatsby develop. Now it's compiling all the pages and so you can see, ooh, ah, hang on, I have a spare page. Okay, it looks like I committed something that I should not have. So I think if you just name this site title query two, it should be fine inside of layout. See, I was trying to save all the work that you need to do. Unfortunately, I don't think I did it very well.  Okay, so my index.html has this page one. Can everyone get here? Still, I'm still selling. Oh, I'm so sorry. Why don't we watch some YouTube while we're... Questions on this? Does this make sense? Yeah, to create your own policy. No, Gatsby comes with it. In fact, it's a pro and a con. The pro is that everything has a standard data layer and you can prototype very easily. The con is that it takes a while to spin up so it's a bit slower. But I think you trade the upfront power. You trade the upfront startup time for overall power. I'll show you. Yeah, it's a request. So I know people are MPM installing. I'm not really sure what to cover now. Let's see. Just real quick. Yeah. I can't even say that we get it because I haven't set it up yet. And for requiring, like, to call me and shouldn't, I've got a Singaporean install phone so it's not really going to work. What, AWS? Yeah, that's a 4-meter like request. Okay, I'm sorry about that. Just keep it... Yeah. Okay. Yeah. I mean, I've just been instructed to use AWS for this tool but then there's other static site hosts that you can use as well. Okay, so I just want to give you the idea that just by convention, anything inside of pages, anything that's a JavaScript file and has an export default is a page that you can start rendering. So it's a little bit like Next.js as well, like that's magic pages folder. And it's different from React Scripts because React Scripts doesn't have anything by default.  Every single page is code-splitted based on the page boundary. So let's set up a different page like about.js and I'm going to import React as well. Or I can write my own export default function return h1 about page. So that's it. I just created that JS file. I created the about page. I think it recompiled so I don't even have to restart the server. And now if I go to localhost 8000 slash about, it's going to show me my about page, right? So very like, you didn't even set up routing, which is fantastic. Although you probably need to put links between them. One thing I like to show people that stuff is being statically rendered is in the network tab. When I refresh, I get an about.html. This is an HTML document. Oh, I've actually not server-side rendered this. Okay, so in development, this doesn't work, but in production, you actually will see inside the preview the pre-rendered page, which is pretty cool. To prove that it's just HTML and no JS.   So that's a rough idea. Okay, so I'm going to leave you to it right now in terms of the exercises. So where we are now is intro to Gatsby. We're making pages. And we're going to make a layout component. This is pure react.  A layout component is very useful to have consistent layouts between your pages, right? Right now, I don't have any consistency between my pages. What if I made a react component, imported it from there, and then used it in both pages. So I would like you to do that, and just get familiar with the development flow, and look at the rest of the, if you're slightly ahead of the rest of us, look at the rest of the docs as well. Well, I'll show you one thing as well for those people who are at the graphical layer. So localhost 8000 is where all the sites is, but underscore, triple underscore graphql, this is where the graphical layer is, where you can start querying all the pages. So here I think we have site page. You can just look around as to what the nodes are. And you can see what I talked about. Like right now we're consuming JavaScript files, and it's setting up pages. So these are pretty helpful. Honestly, I don't navigate around these a lot just because I know I don't need it, but it's pretty helpful for figuring out graphical. Where's site title? Yeah, I wanna query site metadata. Okay. So the place to query is site.site metadata. I'm gonna query all of this stuff, see if I can get anything. By the way, this explorer on the left is a new addition to the GraphQL ecosystem. It was done by my friend, Sean Grove at OneGraph, and you used to have to type. Who has time for that, right? So I think the way to request site metadata. I'm not sure I'm doing this right. Hang on. Yeah, okay, so if I request title, description, author, anything, I can start seeing my site metadata. So this is configured inside of Gatsby-config.js. This is the starting point for all Gatsby projects. All Gatsby projects must have a Gatsby-config.js. This is where you pass in any data. It's a free-form JSON object. You can pass in whatever you want. Gatsby infers the types. Here I've only passed strings, but you can put numbers, arrays, whatever. And it infers the types, and you can start querying it from your GraphQL. And so where that is starting to become interesting is inside of your pages. So let's say inside of my page, this is super annoying, I'm gonna get rid of it. Inside of my page, inside of index.js, I wanna request, I wanna use my site metadata. So I'm gonna use site data. What was my instructions? I need to check my own instructions. Use static query, okay. So let's say I use static query, and I'm gonna use static query inside of here, data equals, sorry I'm talking too much, but okay. And then I'm just gonna render it out over here. I do need to wrap in a GraphQL tag, good spot. Yeah. Okay, so let's see what's going on in my site. Localhost 8000, invalid regular expressions flag. There you go. Okay, cool. So I can now use GraphQL inside of my page to request something at the site level. Request I've consumed all that JSON information into my GraphQL. I request it, pass it into index.js, because I'm using that GraphQL, as a GraphQL query as a static query, and it's starting to feed into my statically rendered site. So I did this on my index.js. I want you to do it on the layout, follow the instructions inside the markdown file over here. I think I've been very explicit about what to do. So yeah, we'll just do this for the next half hour, and then I'll start back up at 2.30, okay? All right, and just mess around, and there's extra homework if you want at the bottom. The exercises, as well as the SEO component. How's that? I just talked for one hour. If you need water, just water at the back. Yeah. I was just wondering, I didn't catch fully what your experience was earlier. You said that you tried out Gatsby. You had some reservations about it. Is there anything I can answer for you? Like the behavior? Yeah, basically anything relying on window methods and all that? Yeah, that, but also, for some reason, I get component did not, when it shouldn't be called. Okay, we thought regular React habit wouldn't be called twice. Instead, component did update should have been called. For some reason, Gatsby, some things like that sometimes happens. Maybe it's something to development, maybe it's something to production. I have no idea. That's the thing, I'm not quite sure. There's a lot of things going on behind that, Gatsby. There's so many things that it's hard to tell. What is the source of the problem? Yeah. And this is the problem that they get with Gatsby, and they have similar problems with our next JS, or with Gatsby, if you want to have dynamic routes, not static ones, let's say you have dynamically loaded content, something like WordPress, for example, if you write blog posts and stuff like that, and you want it to be, you don't want to have a static page for all your tutorials, you want it to be dynamically generated. If you want to have something non-static in your website, it's a problem to have with Gatsby. Yeah. I don't know how to do that. I haven't run into this life cycle thing. The main reason I run into problems is anything relying on window methods, so it just needs to make sure to wrap that. If I have that, then I always export it into a dedicated module, I check if windows exists, it's not that I do like a different kind of handling. But there are stuff like with routes and the life cycle, like weird stuff that I don't know why. That was just my opinion. All right, you know, file issues, all that. Yeah. It is early-stage tech, in sense that, like. Gatsby exists for quite a while, I think. Three years. Or, I think they got a lot of money to work on that, so I'm quite surprised. Actually, not that much. How much do you think they got? A few million dollars. Three million, and they hired 35 people. It's not a lot. Okay. I don't represent them. I'm just... 35 people for one friend. Well, they're building like a preview platform and other enterprise services. So it's not all developers. That's everything, okay? Yeah. Okay, that's our timer. If you ever need a timer, just Google calm down timer, and Google build it right in for you. It's pretty nice. And the music station is free, cool cam radio. Okay, cool. Sorry about that. So again, I don't expect everyone to have done everything, but at least you get your hands dirty writing your own Gatsby stuff. And we're just gonna plow right on. We don't have that much time. I'm a little bit behind, but I think I'm okay. So just so you're aware of where we are, I'm inside the repo, and we're in part three now, Gatsby plugins. Okay. I think that Gatsby plugins, so it's possible to use Gatsby based on the starters that you choose. You can use a whole bunch of starters. Here's the starter library. It's gatsbyjs.org slash starters. You can get started just by cloning any single one of these things. You click the GitHub. You've already been through the process. Cloning down to your repo, change a few files, all done for you. 200 starters, some of them are not so high quality. So just, so fun fact, I actually made this showcase, and I was very insistent on the fact that I could filter by use case. So for example, if I wanna search for e-commerce stutter, this shows me how to use Gatsby with Shopify and Stripe. If I want authentication, this has Firebase authentication, AWS Amplify authentication. This is my personal one, Jamstack hackathon starter. Basically, look through the use cases. There's a lot of different things. It's as flexible as JavaScript can be. But starters are just repos that you clone. And then once you clone it, it's you're on your own, right? No one's gonna maintain your stuff for you. Plugins are a pre-bundled set of capabilities. And that's where the plugins library is. It's gasbgs.org slash plugins. You have a whole bunch of them. A lot of them are, it's not very clear why you would use them. I think there's one problem in our industry in general is that we don't write enough documentation. So if you can help with the docs, it's always a good idea. I also made this thing, is link C starters using this. So you can link back to the starter page and filter by starters that use that thing. So you can, if even if you don't have documentation, you can see working examples that use it, which is kind of good enough. Okay, so there's a lot of different plugins. All of them do vaguely different things based on the APIs that are available to Gatsby. So the main one that we're gonna start dealing with is Gatsby source file system. Gatsby source file system looks through your folder that you give it and ingests everything inside it as a node. It's very dumb. That's it. It has no idea, maybe knows based on the extension what file type it is. That's it. It's not gonna say, it's gonna take in a markdown file and it's just gonna say, this node is of type markdown. But it's not gonna convert it to HTML for you. You have to do that on your own. It's not gonna convert to like JS or whatever. It's not gonna process the images for you. It's just gonna say, all right, I have a path to that image. That's it. So I have the source plugin. There'll be a lot of, remember what I said about the API economy?  There's a lot of plugins. There's 990 something, 908 plugins. And I think this is actually a big source of power for Gatsby because every plugin that someone else writes is immediately code that you can use. It's a network effect of all the different data sources that can come into your app. So whatever it is, you're then gonna wanna transform them. So there's the source plugin and then there's the transform. And there's other smaller types of plugins. And fun fact, plugins can have plugins. So even inside of this plugin, I can have my little children plugins. And that's just because of how big Markdown is. So imagine writing a Markdown folder and you put in a URL of a tweet and it just generates that tweet component for you. That's a plugin. That's the OM-Bin plugin. And all sorts of things. So basically, the main area you search is here. The naming syntax is not enforced. So some of them can be named something else but they're actually doing that job. I've complained to them about that. I think that they should fix that. But basically, let's just kinda go through the plugin material. So yeah, so earlier we already, I'm just gonna go in here. So earlier we're already familiarized ourselves with the site metadata. It's just a JSON blob that we can request our title from, our site title from. But now we're gonna concern ourselves with the plugins array inside of here. Right now it's empty, I think. Yeah, I've just left it empty as a comment field. We're going to start using Gatsby source file system. So the syntax of plugins, if you're using it without options, it's just a string. Here I have Gatsby plugin here. It doesn't really matter. So that's very simple and it's nice to see a whole bunch of strings. But once you need to start to apply, once you need to supply options, that's where you get to start this pretty ugly syntax where it's like resolve and then the plugin name and then options and then it's an arbitrary JSON again of whatever you want to pass in. This looks ugly but it's very expressive because you can use JavaScript to create the object however way you like. You can combine it in different ways. You can fetch data from somewhere else and pull it in. It's really up to you how you want to create these options. So it's maximum expressiveness. So what I'm going to do and demo for you here is to implement the Gatsby source file system plugin. We've already MPM installed it. Most Gatsby setups will have it installed but just double check in case you get an unrecognized error. So over here I have a Gatsby source file system. I'm teaching it to consume one of the folders, right? Here I have some sample content inside of source slash inside of slash content. I have my first post. This is marked down. This thing at the top is front matter. That's metadata for your post. That's data about your post. That's my second post. So I wanted to consume stuff. So I'm going to get it to consume it. I'm going to give it a name like content. I'm going to give it a path. I don't need this path.join because I can just use Durname. And I'm going to say content. Durname is a Node.js concept. I think a lot of people know but I wasn't that clear. So Durname is just the current working directory of the folder that you are running this process from. So my current working directory is jamstack.jum.start slash site. That's my current working directory. So when I say Durname, I have Durname slash content. That is going to be site slash content. And then everything inside this folder is going to be marked down files that is consumed, right? So I have that set up. And that's our first plugin. And if I want to get on and start again, which is Gatsby develop underdivided. We're going to see in our graphical, we're going to see in our graphical new nodes. Remember what I said about nodes? These are all nodes. In this case, it's a file. That's what the source plugin adds for you. It has an ID but it also has absolute path. Let's just do the path, relative path, whatever. So you can see over here that now Gatsby has a sense of what my files are. I can add in a third post. Let's just really bang it over the head with this one. Because I think this is where people start to trip up because it's no longer just JS. It's understanding the APIs of Gatsby. I don't know if it hot reloads. I hope so. Yay, hot reloads. OK, so pretty clear, right? So now we have to take this and then we have to transform it. So that's the next part of my thing. Styling, same thing. You need to do server-side rendering. It takes advantage of other stuff. We're just going to skip that because I don't have time. But definitely try to practice it because that avoids the flash of unstyled content that you get with CSS and JS, right? If you want to use something CSS and JS like style components, you want to definitely server-side render that styling. So we explained source plugins already. This gives you an idea of what else source plugins you can get. I just went through this exercise. I'm sorry. OK, so now we're going to transform the source, the markdown files. Like here we know they're markdown files. We're going to transform them with Gatsby transformer remark. That's the where the hell is my? So we don't need options. We're just going to stick it in there. So it's going to be in just in here. Order does matter. So you want to place the thing that works on the previous thing after the thing. You know what I mean? Um, remark itself has extra plugins and options. Definitely go read those things because it's very, very useful for your content writing. Especially if you're writing pretty dynamic content. My personal project is I want to embed YouTube. I want to put a YouTube link and it just inflates into a nice YouTube logo inside of my markdown, which is pretty cool. The less JS I write, the better. The JS should only be for dynamic custom stuff. But if it's just straight content, let's just leave it all to markdown. So I have Gatsby transformer remark. And now I have to do the thing where I say, OK, everything's in graphical. I'm going to show that later. But now I have to do the thing where I say I have a template for all the markdown and I'm going to programmatically generate for each file, markdown, markdown, markdown, run it through the template and generate that HTML every time. Let's actually show you the markdown. So look here. There's only all directory, all file, all site page. It's very small so you can't see it. So no mention of our markdown, right? When I kill it and refresh it, it should. Because now I have the plugins. I need to reinstall it. What? It's name. OK, well you're going to have to reinstall it as well because I didn't include it. I thought I did. OK, my bad. Yeah, you have to install the dependency Gatsby transformer remark. That's just because I left it out. OK, so if I refresh this, now you can see inside of my graphical, I have this new thing called all markdown remark, which is not a super intuitive name, but it's good enough where we can start seeing the content that we added in. So here first post, second post, third post. Now it's not just the file path, right? Now I'm reading the file and parsing it into these things, which guess what? I can query from GraphQL inside of my React components. You've already started to do that a little bit on the site level. Now we are doing it on the content level. So what we need to do is we need to basically do this query, do this all markdown remark query, get this array of nodes, and then for each node, we'll pass this into our template as props. The props will do whatever you want with them, right? We just render a JSX, and then that will be your generated page.  My computer died. No, I might. OK, this is showing, but OK, all right. Sorry. So to do that, I'm going to walk you through it. I'm being extra careful with this because this is where people really screw up. So I'm just going to use this default template that I put in my own nodes. It's pretty much going to be exactly the same. Actually, I think I already provided it source templates. Oh, no, I don't have it. So I'm going to make a page template.js in here, and I'm going to paste it in there. It should be pretty much, yeah, exactly that, OK? So that's inside my source slash templates folder. Just be very aware what folder we're working in. We had some people with issues earlier. So inside of gathlinode.js, we're going to create pages programmatically. I'll copy and paste this in, and then I'll explain what the code does. So what I copied from our nodes should be the only thing that is in gathlinode.js, even though I left some comments in there for future stuff. OK, so what does it do? This uses, here we're using the node API. Remember, we're doing server-side rendering in node. That's why you have this weird exports.mon syntax. We're saying create pages. Gathlin is going to pass to us their redux actions. Gathlin internally has all of its operations done via redux, as well as a GraphQL helper to transform GraphQL requests. Then we're going to get the page template, the one that we just created. That's just pure JS React component. Then we're going to return a promise. The promise is a GraphQL query. It's exactly what we just queried just now on Markdown Remark. It has some optional fields. The fields don't really matter. Probably the one that does matter is that you want to sort by date. So it's all defined here. You can play around with, if you're not sure what it is, right? You can go over here, and you can say date. Sorry, all Markdown Remark sort fields. Where's the date? Date. Order ascending. So what GraphQL is, right, is a way for you to prototype this exact query. And you literally just copy and paste into here. Make sense? OK, so if you need anything else, if you need any other changes, just study that. Understand the API. If you need docs, it's over here. This is standard GraphQL stuff. Again, I don't have time to cover that. And this is probably overkill because it's all auto-generated. But there's something in there that's going to be pretty helpful. Personally, I like to learn by just seeing what other people do. So I just study other source codes. But it is very, very expressive and powerful, because the amount that you have to code is just very minimal. You're just using tools, which is very nice. I think as codeers, we should try to do as little coding as we want, as we can. So then the last part is very simple, right? We dot then on the promise. So now we get all the results of the GraphQL query, right? Assuming it has no errors, we're going to say result.data.allmarkedownedges.forEach. That's the forEach that we wanted, right? So for each node, each node is this thing, right? For each node, we have frontMeter.date, frontMeter.slug, frontMeter.tags. We're just going to pass that in as a slug, for example. And actually, I should pass in more information than that. Yeah, I might regret this. But anyway, so then we'll specify page template. That's the thing that we resolved earlier in Node.js. With the net result that we're passing in everything to page template, and we have this prop called data. So now we've generated each page, and each page will be called firstPost, secondPost, thirdPost. And all we need has been the path, the slug of these things. Inside the page, we'll do another query. This is inside pageTemplate.js. We do another query. This is a page query. You export const page query. That's a static. Typically, in a page, you have an export default, right? That's what the page is. If you want to have a page-level query, you just export page query. That's a magic variable that Gatsby looks for. And you do whatever query that you need. So the incoming variable is the path. Like, I know my path right now. I'm going to query for all the things that match my path. And I need all this data. So what we're going to do, I hope that was right. I see some errors, so I might have some copy and paste errors. Yeah, I think I have copy and paste errors. Or I might have slug. Let's see. Yeah, OK. So I think I have a bug in here in my own code. We'll see what that is. So I guess showing debugging is helpful. So I'm going to look at this type. I'm clearly specifying something wrong on the type. So I'm just going to look for this type. And it says, title, slug, date, or tags. So I actually mean slug. I did not mean path. So the way to fix it is to see other page template. And instead of path, I'm just going to say slug. This should be also slug. I think this is also slug. Did you already fix it for me? Hey, OK, so let's look at the 404 page. My 404 page is still, OK, whatever your version. I don't know what screwed up with my 404 page. I don't have time to look to fix it. But yours should work. Let me try and refresh this and have a look. No, don't leave. I swear, I promise I'm good at this. OK, you know what? I don't care anymore. What I'm going to do is I'm going to yarn build. And I'm going to show you the build result. Ah! Oh, did I mean date? What is this? Markdown remark front-matter. I think I skipped something. 8.10. What did I do? What's that? Oh, it should be slug? All right, run the build. Yeah, this is something I don't enjoy about working this low level. You do run into a lot of debugging, and you need to know what's going on. But that makes the future a lot brighter, actually. So I think the path variable has to be named path because I named it path here. Can I read property front-matter of null? I see. So markdown remark is null. What would that be null? I'm not sure. OK, I'm not sure about this build anymore. I'm sorry. Let's just try to get it running on the dev server, and then I'll fix the production build. Cool, second post. All right, so my data is off. How I would fix this is just the console log it. Because I'm expecting something which doesn't seem to be there. So my data object has data, and it's markdown remark of null. So something in my query is not working. It's not right. So how I would debug this is I'll go in my page template, go over here. I think this is it. And in my path variable, if you just thought anything I'm doing wrong, let me know. First post. Yeah, I have my first post. OK, so right now I'm trying to debug why my markdown remark here is null. And I don't expect that to happen. Basically, because I think something is not matching correctly, therefore I need to figure this out. So if all this is correct, this query works. That means I'm not getting the path query that I want. I suspect this because I'm not getting this page. I'm so sorry, guys. Let me just ninja debug. OK, so I have my slug working. That's helpful. Anyone see it yet? I'm lost. I think this should be working. First post, second post, I'm not quite sure. OK, yeah, just give me a second while I figure this out. But in general, the plugins are the hardest part of Gatsby, which is why I should have prepped for this more. OK, slug. Because I think I changed the name of the thing from slug to post. I shouldn't have done that. I like to call it slug rather than post. Oh, never mind. Sorry, sorry, sorry. Sorry, I'm fixing and fixing. I'm just going to remove all mention of slug because it used to work before. And then I intelligently changed things at last minute. Don't do that. So still cannot read from it or no. If anyone's experience of Gatsby and see something wrong, please shout out the answer because I'm a bit lost. Yeah. Anything? Yeah, so the page query, I can get the exact thing that I want. I'm just running the query. This should be the query. It's not now. So that means that I'm getting the wrong info here. OK, so I'm going to bring up the doxford page query. Sorry, I just configured the wrong thing. Feel free to read the rest of Gatsby plugins. So I'm going to figure this out, don't worry. Let me sec. Gatsby page query. Fortunately, the docs are pretty handy. So there's a way to have the input. That means that we compile. So sorry. No, I'm still figuring it out. If anyone knows what's going on, let me know. What do you mean? Did I not do that? To be honest, I think context is for other stuff. Give me a sec. Yeah, yes, super SEO. We need to pass context? What am I passing? Context path. One line. Motherfuck. OK, well, that was super annoying. You needed to pass context into the path. So basically, inside of Gatsby node, we have that string. We need to pass this string so that it can be the source of that query for the page template to query things with TIL, right? TIL. So now we have a different error. That's progress. I think I just need to refresh. I think I already fixed it. OK, shoot. Not sure what did you already make the change. Yeah, let me just refresh to confirm that I am completely fucked, OK? Oh, OK. Oh, look at this. That's a cache error. This happens. So sometimes, the cache invalidation fails because you're making some edits that are off of Gatsby node. I need to just delete the cache and rerun again. It ended up with the cache, yeah. Yeah, that's one of the problems that people experience with Gatsby will understand. It's cache invalidation is hard. It's still not it. OK, come help me. Yeah, so what I made changed from your thing. You're using a slug one, right? Yeah, I changed it from slug. The slug. OK, so let's change it back to slug. You start from the Gatsby node. I didn't mess up anything with the empty fault. Yeah. That's my fault. OK. So from the Gatsby node, this one is needed to be a slug because if you're looking to the. Yeah, I know. I just changed it around because I thought that I didn't want to confuse the things. And then on the create page, I think I'm not really sure, but I look into the doc. You need it to send the path. You think that's it? And on the button. Oh, there's no slug here.  What can we do with the TypeScript? That's it. Thank you. Yeah, I've run into this kind of thing a lot. And it does really suck. Hey. Hey. I swear I know Gatsby, guys. But the idea is there, right? Hopefully I brought you through the process of consume, transform, and then have a template, and then you inside of Gatsby node.js programmatically run through and generate. There's a lot of glue pieces that things can go wrong. And you have to be careful. It doesn't throw an error. For example, just now, one of my mistakes. One of my mistakes, I'm going to push this as well so you can just get pulled. My commit log is just fix, fix, fix, fix. OK, you can get pulled now. But basically, one of my mistakes is I didn't have a variable called slug defined here. And I just said slug. I tried to be fancy, right? I tried to be ES6. And I just said slug. Slug is not defined. And it didn't throw an error. That's going to be fixed like they're working on the error messages. But you just have to be aware, especially because you're not working in any sort of type checking system that these kinds of things might pop up. Just be very careful what you're wiring together. Again, they're plugins. So what we're doing, right, is we're actually writing a small plugin for ourselves. Get this. Every plugin has access to the same API, the create pages API, the create node API, on create page lifecycle hook. All these things can be bundled up into a plugin. So if I wrote this plugin, I can publish it on NPM. You can install it. And it will be automatically run for you. So you don't have to code this. This is low-level custom code. That's why it's so funky and weird because you can do whatever you want, right? But the goal is to take this low-level API, build on top of it with plugins, and we plug in build on top of that with themes. So we're eventually going to go there. So I'm very behind. But yeah, so I want you to get to this stage. Have some navigation. If you want to have a blog index with all the markdown files, go ahead and do that. If you're feeling adventurous, go ahead and do the image plugin as well, the image transformation. I have a Gatsby 3a, the Gatsby image docs. I don't expect to cover this here, but definitely go try it out on your own. Just to give you an intuition of why you want to use Gatsby Image, these images are one of the big performance bottlenecks in a site. Even my company is guilty of doing this, that we will publish a super fast site, but then a 2 megabyte image that no one needs. So what Gatsby Image does is it transforms, resizes, and serves the right one based on your client. And it has these nice progressive loading features. So this is the blur-up effect. Let me refresh. You see that blur? You see that blur? So it just shows that blur in an inline SVG, and then once the image loads, it just replace it, hot swaps. I like this one, the background color one. This fades in, very nice. Trace SVG shows the trace, and then it fades in, right? These are all pre-processing stages where you have a source image file transform, create all this random crap, and then have Gatsby Image serve it for you. WebP, I don't know what that is, just whatever.  Basically, all to make your user experience fast, but it also looks nice. I think that's very impressive. I've seen it used in a bunch of e-commerce sites. I do want to give you some inspiration. So if everyone knows of Harry's, the Razor startup, they actually launched their female brand. This is the Gatsby site, and it serves. You can see this fade-in effect. That's also progressive loading. You can tell if something aside is Gatsby or not with this Chrome plugin, it just shows a purple G. Yeah. It's also a React site. It's not a Netlify site. I don't know, I have a bunch of these to sniff the headers. But you can actually look at the elements and just go like Gatsby. You can see, oh, Generator Gatsby 2.0.  Oh, I should also give you, OK, I'm really bad at this. That's why this is not my full-time job. But here's the example of sites you can build with Gatsby. I should have started with this. The React.js docs is in Gatsby. You can clone it and look at what's in there.  Airbnb's data science blog, Impossible Foods, the fake meat, the vegetarian meat thing. brawn.com is on Gatsby. There's a whole bunch of stuff. It's mostly static sites, mostly marketing sites. But increasingly, you're going to get dynamic applications as well. So let's see if there's any API sites. This is more for like SendGrid. OK, so yeah, well, we're going to get to that part in the serverless section. I just want you to go through the pain that I just went through. And we have 20 minutes for that. I'll set some timers, and then we'll reconvene at 3.30, OK? All right, thank you. Yeah, thanks. Thanks, Wei, for that. I think one of the purposes that I had you clone all those sites is I really wanted to look at the source codes for those things. And I've given you the rough framework to understand what's going on in there. It's a lot of node. It's a lot of GraphQL makes inside of node. It's a lot of like, is this undefined? Yeah, all right, let's go fix that. But just keep in mind it's low level stuff, and we'll build up over time, and we'll just start using each other's plugins and all that. In fact, I really want you to look at plugin source code as well. This is a really good exercise to understand that there's no magic. So just pick any random plugin. I'm going to pick a source plugin. Let's just call it Shopify. Gatsby source Shopify. It's an official plugin. I'm going to view plugin on GitHub. So this is maintained by the Gatsby team. Inside of here, it's got some readme. It's got some package JSON. Nothing much. It can install its own dependencies. And inside of the source code, what do you have? It's Gatsby node.js. It's the thing that you just wrote. So essentially, it's just nested Gatsby projects nesting, nesting, nesting in and off itself. Every plugin can basically just run this code for you. But when you're a user, you just use it as Gatsby source Shopify. There's a lot more APIs that we did not cover, but definitely just get a sense of what plugins are just presets of things that you could write yourself. But you only write it as a last resort. Or because people haven't written the thing that you want it to write. OK, so where are we at? Jamstack. So we should be at four Gatsby themes. OK, so this is a very short one, because it's a feature that has not been released yet. But it's the biggest thing that has ever happened to Gatsby. And I would not be doing my job right if I did not tell you about it, at least. So plugins on steroids. So plugins can implement Gatsby node.js, Gatsby browser.js, Gatsby config.js, Gatsby SSR.js. Those are all the individual APIs for different modes of rendering from the SSR side to the browser side. What Gatsby themes do is they're plugins plus presets of components. So they ship for you.  I'm just going to show you the theme that I've been working on. This is the source code for that theme. And I want you to see how little code that is. Like, I intentionally structured it this way because I want you to feel the existing pain of the low level code. And I demoed it for you myself, not on purpose. So this is a site. This is how it looks as a deployed site. And typically, you'd have to have a whole bunch of code just to make a site like this, right? Again, it's applying syntax highlighting to code. It has the emoji stuff, and it's got an overwritten component. So the source code for this is literally just Gatsby config.js. I have my site metadata, and then I have a theme. That's it. I don't have anything else. I have no page generation code, the stuff that I muddled through earlier. That's fine. That could be a plugin. What separates it from a theme is that my source slash pages, actually not the pages, let's just say components. I only have one thing, bio. That's the only component that I have, because I've overwritten this bio component. This is the bio component. Everything else comes from the theme. So let's look at the source code of the theme itself. So this is Gatsby theme dev blog demo. Let's look at Gatsby theme dev blog. So inside this theme, I have basically clones Danny Bermoud's site. And I included all the source components. It's got a whole bunch of them, right? Layout, whatever. And I said, all right, I only want to overwrite or shadow the bio component. The bio component, this is the source site. This is the bio component. Let's say I want to replace it with my own, right? So the only thing I have to specify is my own bio components, source components slash bio.js. And I can write whatever I want. I put my name in there, because I can take credit for it. But you see the theme potential that by default, I install, and I can get layout, I can get panel, I can get the SEO element. And it all just ships with my theme. So it's a plug-in on steroids. The goal for Gatsby, what the Gatsby team told me, is that the goal is for you to be able to install them side-by-side. So right now I have my Gatsby config. I have only one theme here. But what if you can install an e-commerce theme alongside your blog, alongside your marketing site? And then it just all composes together nicely. I think right now that is a pipe dream, because all these things are completely unspecified where things clash. So we're all going to have to get together as a community to decide what the standards are. Because all that Gatsby is doing is providing the underlying tools. But this is a really good open source opportunity for us to build the next WordPress by saying installable themes. And then the only thing you're responsible for is content, right? So I just want to sell you on the idea of themes. We're now going to have time to implement it. I think it's, I have some videos. They have some videos. Go through the docs and wait for the official launch. I think it's in one or two months. But that's the Gatsby themes section. Any questions about themes? Like, do you want it to do anything? No? I feel like I've hyped it up enough. OK. Yeah? So when you shadow the components, do you need to specify any directly? Yeah, so if you see how the shadowing works, to avoid... So let's say I'm shadowing this theme. I have the name of the theme that I'm shadowing, slash components. So if I have multiple themes installed, it won't clash. Yeah. And so the only thing that I'm specifying is just my content, right? So this is an extremely light blog. Like, the only thing I have one dependency. I have Gatsby. I have React, React DOM, and Gatsby theme dev blog. That's it. Four dependencies, right? So pretty bright future for Gatsby. I'm sorry about all the low level stuff. And I made you go through it because that's what we have, right? All this stuff. That's the underlying system. But if you think that this has a future, then let's build on top of it and just make life easier for everyone. OK, so we're more or less done with Gatsby. That was a whirlwind intro. One thing I'm really proud of is that I actually went through the source code of the Gatsby lifecycle method. So in detail, what each API does, what each lifecycle hook is, you have the links for this in Gatsby lifecycle.md over here. If you really want to know what APIs you can take advantage of and what opportunities there are for building cool stuff, definitely read the process of how Gatsby works internally. I just don't have time to do that here. But I'm the guy that wrote the docs, so ask me anything. It looks a little bit nicer now. It's just super wordy because we have to talk to everyone, make everyone happy. I'd rather just make myself happy. All right, so now we're going to talk about serverless. And that's pretty much all we have time for together today. So this is a slightly like Gatsby solves. What does Gatsby solve? Gatsby solves perf issues. It's data-driven documents. As much as React is a function of data, and you put data into React and it outputs an app, Gatsby lets you put in data and it outputs a site and generates all those HTML files. What it doesn't do is all the servers, the responsibilities of a server like executing code. So that's why Jamstack and serverless are very good pairs of each other because everything that Jamstack cannot do with serverless should be able to do. So we're going to go through a small presentation. This is not my presentation, but I strongly believe in it. And this will give you a pretty solid understanding of serverless, this buzzword that everyone is talking about. Mainly, don't expect it to do everything yet. But every single year, things get easier and easier and easier. We used to worry about cold start problems. We don't anymore. Anything you hear about cold start is probably wrong. Let's talk to the cloud fair workers, people. They started at 8 milliseconds, it's insane. So this is an area of intense research, and that's why we want to talk about it today. Let's see if I can pull up the slides. Slide URL is there. You have the link as well, so don't worry about it. Let's talk a little bit about why serverless. Again, talking about the lamp slash mean model, imagine you have an app where it hits the top of hacker news, and it just gets a billion points. So all people in the world come to your things, and they're just streaming in massive traffic. At some level of scale, if you have a server, you're fine, and it's a very simple programming model. With more, you start sweating a bit. And then with extreme amounts, your server starts catching fire. And at some point, it will just go down. It will get the hog of death, or the slash dotted, or whatever, or the reddit hog of death, depending on what generation you grew up in. Chrome can run out of memory. I don't know about this site. This is not my site. But the point is, web architecture is as convoluted as it is. If we're going to reconstitute this, we actually have to come up with a different architecture that's event-driven. So we're going to come to that in a bit. Service at its core, the reason you want to adopt service, auto scaling, paper execution, third-party services like third-party APIs. And you focus on business logic, not scaling up and scaling down your servers. As well as event-driven workflows. This is the key part to understand that anything that you used to do on a server, you can probably do with a webhook here and a callback to that webhook there. That's about it. That's the rough idea. Especially Chrome jobs, a lot of people don't understand that Chrome jobs are free, basically, because you can call a webtask.io, give it an endpoint, and we'll just ping it on a regular basis if it responds. OK. But like cron.io, cron.org. Basically, if you need recurring services, it's also doable without a server. You don't need a server to set an infinite loop or something. You can just literally ping an API. And you put all your business logic in that API and let it execute. OK, so in other words, you want servers to be extracted away from the developer. You're writing just the business logic. And I really like this micro-billing thing, because obviously you're not, I don't want to pay that standard $5 thing for a month. If I'm not using it, I'm not using it, and I shouldn't have to worry about it at all. It actually is there's a huge ecosystem. I think that a lot of people only talk about AWS, but actually there's IBM BlueMakes is pretty interesting. I think there's some up-and-coming names. I think Begin is a very, very interesting serverless platform for people to explore. And obviously, Netlify, the company that I work at. So there's like two competing terms, like function as a service and serverless. So it's actually the sexier term, because it's the one that pisses people off more. So people just talk about it. It's a really good talk. I like what if you didn't learn the serverful method from the beginning, and you started from serverless. And focus on the mindset that you're trying to work on business problems and not the infrastructural scaling issues that a lot of people have to deal with. So what can you do with serverless? Anything with asterisks, which is basically long-running jobs. If you have a long-running process, like a machine learning job, you probably want to stick that in a server somewhere. So functions, as of right now, functions must complete execution in under 15 minutes. That used to be five minutes. That used to be 10 seconds even earlier. It just gets longer and longer. And now with step functions in AWS Lambda, you can actually chop things up and execute them in sequence and in batches. So who is using serverless? All these guys? I like Coca-Cola, the stuff, the people that you think, New York Public Library actually, so I do a lot of mean-ups with them. And they're surprisingly advanced. Basically, they have redefined themselves to be a digital library. So they serve three times more people online than they serve in person. So they are definitely a tech company. Whatever. A lot of people, it's fine. So how do you get serverless? Choose your cloud. You pick your deployment tool. Deployment tool, most of us, this second layer, that's what they call second layer cloud providers, can compile to the first layer. So it's regarded as the first layer of cloud as the hardware layer and the second layer cloud as software layer. This can be for multiple reasons, like portability among them. There's a framework called the serverless framework, serverless.com. It's not the same as serverless in general. It's just very good SEO. So yeah, they just bought serverless.com and now they get everything. OK, so I already told you about the ecosystem. I think one skill to learn is that you should understand that instead of having a server where all the pieces of computing just came with it, like you had a hard disk, you had some memory, you had a running time. Now in a service environment, all the parts of compute are broken up. So you have functions for compute. You have storage like your file blobs and stuff. Your databases that are separate APIs. These are all separate APIs. Even the state machine, I think it's Kinesis. Anyone use Kinesis? Yeah. I don't use it, but I was surprised that you can have a state machine as a service. I don't know. I don't use it at all. So I'm just repeating other people's words for them. We even have specialized tooling to connect your Lego blocks together, the stuff that you don't have to use. And that's cloudcraft.co. That's where you get all these charts that are very common in the industry. So for example, spinning up a REST API, you can actually just model REST API as an API gateway. It results to several different lambda functions. And if you need persistence, you can stand up a DynamoDB behind them.  Your resolvers are now your lambda functions as well. So I like that a lot, especially with Apollo Federation, the new thing that they just launched, it's very easy to break up your GraphQL schemas. Webhook listeners, same thing really.  Webhooks are a way for them to call back with the completed information. And it tells you that you're completed. So again, you don't need a running instance. Authentication is a pain point for serverless, because a lot of the times you need a running session on the service side to do authentication. And a lot of people lose that model when you go serverless. Because everything has to be stateless, especially when you're trying to execute in a distributed fashion. If distributed execution is not a concern to you, which is not a concern to most people, then it's no issue at all. You can just call back to the database. But yeah, it's a lot of calling back.  So that's the difference between O of 2 and O of 1, that there's support for these kinds of workflows. Yeah, this is the kinesis thing, which I don't understand as like, all right, you can ingest a lot of things, and then so what? But apparently you can fire off different events based on the state of your... Yeah. Yeah, I have never set this up. But I think you have to be in the millions of traffic to be able to start needing this, whereas I'm more of a hackathon kind of guy. Let's see, yeah. Abusing serverless... Because you can scale up in parallel all these functions at once, and you can all send them to a single endpoint, you can actually use it as load testing, which is what Nordstrom did for themselves ahead of their big sales days. They call it serverless artillery, and you can go check it out. Which is true, right? I actually met this serverless user in LA. He told me that he has an e-commerce startup, and 95% of his traffic comes in four days of the year. So what? Yeah, there's no server, like the traditional server model doesn't really apply there. So, form handling, okay. I'm like drowning you in all these use cases to really show that people have worked out the architecture. It's new, it's alien, it's hard. But it will get easier every single year, and the fundamental simplicity and the cost model should be compelling enough for those who want to try it. For Jamstack, there's no option. You have to use serverless to execute everything else. So, I think that's the rough pitch. I actually, I personally really like serverless framework. It's a single YAML file where you can provision like a single YAML config file where you can provision like a serverless function, a database, anything that you might need as one single piece of code, and then send it and deploy it. So it has that Git commit and Git workflow with it, so you can roll back and reprovision as easily as you can.  I just really like the flexibility of serverless framework. The cost calculators, and you can model them as such. So here, one of our, one of our, my co-worker side projects has 1,000 daily active users, 20 API calls a day, it costs them $6 a month, and it scales up and down whenever he wants. So that's super nice. So, yeah, that's the overall pitch. I think that it's very, it's very raw, like in terms of like what I can present to you, because it's highly dependent on the platform and the provider. I'm trying to give a general intro for anyone who hasn't really had that introduction to serverless. So let's jump back to the slides. I really like, so if you want a real sales pitch, check out this talk by the VP of AWS Lambda at AWS re-invent, talking about all the different use cases from real folks, and just like the pace of acceleration. If you're worried about lock-in, the cost of execution only goes down in AWS land. So it's a pretty sweet stack to make projects with and eventually, if you're a serverless native company, I think that's probably a good bet long-term. Okay, examples of apps you can build with Gatsby. So Gatsby plus serverless, here are some, I don't have a lot, mainly because they're not open source, so I only focused on open source ones. A lot of these are closed source because they're actual companies. The Gatsby store, when you are a contributor to Gatsby as an open source contributor, they'll immediately send you a token and you can redeem it for swag. And it's all done on this store. It's an e-commerce store.  I can log in, right? This breaks your model of a static site. Like, this looks like an app. This looks like there's a server behind this. There's no server. It's pulling out my details. It's checking my contributions to Gatsby. It's no longer giving me any discount codes because I've claimed everything. It checks the SKUs, choose the size, it has an order card. This is dynamic AF. And, you know, thousands of people use this. They have more demos. Obviously, this is open source so you can actually check it out and you should contribute to Gatsby because now you know you have the basic knowledge to do it. But obviously, my go-to example is Shot Flamingo where they're actually trading dollars for actual products and it's a real startup. Gatsby Mail is a pretty interesting one. I don't know if I can log in. I don't think I can log in. So, this is my actual mail. So, don't hack me. Fuck. What else can I log in with? I might be able to just, jeez. I think the token for this expired. But do I have a video? No, okay. Anyway, email clients built as a Gatsby app. Just like, super serverless, okay? Like, because, and again, I wanna make that comparison. Like, a lot of some people, I really like this but it doesn't appeal to everyone. We have an existential war between the web and closed platforms. It was, and so, mobile platforms are winning because a lot of people spend their time on mobile, right? Like, they want the native app experience. If we can build rich clients that load quickly, we win a lot of that battle. And then, we're on feature parity in terms of access to APIs and executing stuff. We can do exactly the same things. So, really, we need to work on the delivery mechanism for delivering mobile clients that are just as good as, like, App Store clients, right? From the Apple App Store, Google Play Store. Just as good, but way thinner because they're websites, right? So, we don't have the 500 megabytes that Facebook app takes up. We just have 137 kilobytes. So, we need to engineer our way into that by code splitting, by doing all the performance stuff that Gatsby gets you. Okay. That's a lot of me talking.  So, if you want to go ahead, this is for people who want a massive AWS, and some of you cannot. So, you're free to massive Nellify as well, Nellify CLI. But, if you follow these instructions, this is the remainder of the workshop. You're free to go, we're running a 430 anyway. We have half an hour. But, I'm going to stay here. I'm going to help you through this. Basically, AWS Amplify is all the services of AWS put in your CLI, and it's very easy. It's just running one command to configure it. So, I have here instructions to set up AWS Amplify. For an existing project, you can amplify, add, off storage functions, API analytics, hosting, notification, interactions, and there's more coming. I think they just added video streaming the other day. So, you can do like HQ trivia. I don't know if you have that here.  That's already in your GitHub repo. And then, once you're done, always remember to amplify push. Whatever you're done configuring, new capability, always amplify push. So, we have this for serverless authentication. We have this for serverless compute with AWS Lambda. You write your Lambda functions. We have this for serverless storage if you're storing images, if you're storing file blobs and stuff like that. And at the end of this, I think that at home, you can make an Instagram clone with all of this functionality. Using Gatsby, using this material UI theme. This is all you need. You got Gatsby, you got this material UI theme. You got the serverless storage. This is gonna be super important, serverless storage of the files, and then you can display the images. Yeah, and then authentication for people who need to authenticate into their accounts. So, this is the homework. This is the, if you wanna get, if you wanna like make money with serverless, if you wanna make money with JAMstack, I think this is where to learn. It has never been easier. No one works at AWS like this. It's usually suffering through a whole bunch of walkthroughs on the site. Now it's all in the CLI, now there's a guided walkthrough, and a very dedicated dev team. And they have helper libraries. So, okay, look at how I access my authentication. You see here? They've written all the helper libraries. You don't need to do anything.  Right? And then off.current authenticated user, set user, whatever. That's it.  So, I really like this. For APIs, you literally API.get the name of the API, and that calls it, right? So, storage, okay? Storage.get. You're not even like, you're not even copying, pasting the ARN or whatever. What do we have? Is this how you do your serverless stuff as well? Sorry? If you do like serverless function, is that your API button? API, this is serverless function, API.get. They just wrap it for you so you don't access the direct URL. So that's different from Netlify. Even the serverless, if you take the patches, they'll remember. Yeah, so everyone has this. Google has something similar, Netlify has something similar, serverless. I think AWS probably is ahead by the most because they have 1,000 people on this thing. And they're dead set on making all of AWS into this new paradigm of literally run a single command to add that functionality, answer a few questions and you're done. So I encourage you to try it out. That's the remainder of this workshop. I encourage you to try out together with Gatsby. And obviously feel free to ping me on Twitter or GitHub with questions. Yeah, okay, enjoy. Thank you, thank you. Yeah, I'm gonna put on music, but I'll be around, raise your hand if you need help.