 Hello everyone. Thank you for having me again. My name is Thomas and today I'm going to be speaking about Gatsby.js. So in accordance with tradition, I'll now ask who's heard of Gatsby.js. Okay, so a little less than half. So I hope if you haven't, then you'll get something useful out of this. So just a disclaimer, this is quite a, when I was thinking about exactly what to speak about, I realized that this is quite a, there's a lot to talk about. So I'm going to give a pretty high level overview, okay, and I'm not going to get too detailed. And it's going to be mostly theoretical, partly because I don't want to bore everyone, but partly also because after me, my friend Thor will be doing a practical demonstration. So without further ado, let's start. So I've subtitled my talk back to the future and you'll see why a little bit later. And by the way, you can just call it Gatsby, but I got into the habit of calling it Gatsby.js because every time I googled for help, I kept getting this guy. So that was not helpful. Okay, a little bit about me. I'm a front-end developer at DBS, React Lover and Lover of Other Things. That's my Twitter handle. There's two underscores just in case you're wondering. And my scope will be broadly these three things. So I'm going to talk a little bit about websites in general and how they've evolved over time. I will then give a quick introduction to Gatsby.js and then just do a little bit of a slightly deeper dive into two aspects, which is the data layer and graph QL. Okay, so websites once upon a time were pretty simple. You had a bunch of HTML files that corresponded to your different pages. You had CSS files. You had JavaScript files. And I know that they're basically the same now, but what you saw when you looked into the web server last time was pretty understandable. Now it's less so. So yeah, you'd have one page, one HTML page for one page, one separate URL. And the data in these sites would be, in a sense, tightly coupled to the site code. The site code is the code that you use to actually run the site. So this is like a basic HTML page. You can see that the data is kind of mixed in with the HTML, which makes sense, because that's the way you present the data. There's not really anything like a build pipeline. You pretty much just send stuff up. So that's our starting point. So once upon a time things are like that, right? Really simple. Now I'm skipping ahead a bit here and I'm going to touch on frameworks like Angular and React, which come under the umbrella of single page applications. Or rather, they are frameworks which allow you to create single page applications. So we saw a departure from what we just looked at previously, where there was a lot of tight coupling where we could start to separate concerns a bit more. And one of the things that happened was we started to do a lot more stuff in JavaScript. Everything from handling the URLs as well, that could be done in JavaScript. So that's how single page applications work. In its pure form, it has just a single HTML page. And the other pages are actually not real HTML pages. They are handled by client-side router. So basically you JS all the things. And like I mentioned, the data then it can be highly uncoupled. So you can actually have your data somewhere else and you can fetch it with a network request and you pass that data back into your UI. Your UI is not concerned. Your UI is not really concerned with the data itself. It's just expecting some usually adjacent object and it renders that when you actually run the website. So one of the things that came out of this was that SEO search engine optimization wasn't so good for various reasons, such as you don't always get an idea of what the content is based on. So I'm actually not a hundred percent sure about this because I can't find a definitive answer. Some people say that the crawlers can actually render everything. Some people say they can't. But basically there's this question about whether your website appears to have any content in it when it's visited by a crawler. And if it appears not to have any content in it then it's not very good for your page rankings. And sometimes there are performance issues as well because what's happening is you are usually downloading a fairly large JavaScript file. And even if you you can do things like code spitting and all that. But essentially if you are very concerned about things like time to first byte then you might have concerns about performance because it's kind of the the application in a way has to be bootstrapped, right? Because you're sending back an empty HTML shell which then gets stuff injected into it by the JavaScript. Okay so let's part two. Now part three what happened was that amongst other things people tried to solve these issues that we were facing. So things like the search engine optimization. React in particular has a method called render to string where you can pass a React component which could represent your entire application and it would render that to static HTML. And this basically along sorry short allows you to respond to a server request with HTML. With HTML that has data in it already. Okay so rather than sending an empty HTML structure and then later on injecting the data in you could kind of pre-render the data for that initial load send it back down to the client and then carry on as normal. So this helped with things like like I mentioned before time to first byte because you'd immediately get some useful HTML that you could you could display to the user. So that's where things like render to string came from. Yeah so this allows you to essentially run a server and every request you can you can render to string to to pass that initial HTML with relevant data for that route and then later on you can you carry on the bootstrapping process that you do normally but it's kind of partially done already. So just to illustrate exactly what that looks like you would pass something like app into render string and it would give you out it would it would output something like what you see on the right. So as you can see on the left there's a lot of dynamic data there the user is dynamic data items and so on and what it allows you to do is kind of like at a moment in time get a representation in HTML of what all the data is okay. Alright so part 4 is kind of an extension it's it's it's an extension of render to string in particular it's how a certain class of tools used tools like render to string to combine what we saw originally which was websites which have multiple HTML pages with the developer experience of building a react application using something like create react app and I will refer to these as static site generators and these are not necessarily new I'm speaking about them specifically in the context of I guess I guess react for for Gatsby. So the developer experience is like single page applications you get all that you can still do all your uncoupled data and UI but the UX and when I say UX I mean the visitors experience is like the good old websites where every every URL you visit has a has a HTML structure which you can get immediately there's no like empty HTML which you have to wait to get bootstrapped with data and things like that. So how does it do that it actually generates content during build time so you can think of it as having like a you have a react application that we know and love a single page application when you build this react application it will it will determine all your different URLs and it will build a page a HTML page for each of these. So what you get from the output is actually something that looks very similar to part one right which is multiple HTML pages for each for each location as well as all your CSS and and other JavaScript files. So what the benefit of this is that if you have data which changes fairly often but not that often you can actually you can generate that and in a sense hard coded into your HTML. So let's say you have a blog which you update say once a week. So once a week you have a entry which might be like a new page right so blog slash ID. If you're building a react application to serve this you'd have a component which which renders blog content right generically and when a user visits your website this page will fetch the relevant blog data from your CMS and display it. What a static site generator allows you to do is move that step forward to the to build time and allows you to build separate pages for all your content and then serve those up in your in your web server. So it's more performant right because you you don't have this empty HTML lying around you have actually fully fully rendered HTML but once your app is running you get all the benefits of a single page application framework like React. So yeah it's kind of a middle ground. Okay on to Gatsby itself so Gatsby is an example of a static site generator. What it allows you to do is create websites using React. So if you love React then you can use Gatsby for your projects. They espouse this concept of bring your own data which means that your data can actually live anywhere. So you can put your data on a content management service like Contentful or your own backend service or what else basically anywhere okay I've got a picture later. And what it would do is it will output static web assets like React does normally but like I said it does this in a way that matches the structure of your actual website and with that you can deploy that to your normal document storage like S3, Netlify, GitHub Pages static files. So unlike what we had with Render to String which normally you would have to run a server you don't have to do that here. So what's happening is this Render to String or some method like Render to String is happening during the build process and it's giving you all these separate pages which you can serve. Okay here's a picture. So I've taken this from the Gatsby website and as you can see at the top you have the data sources which can be anything. The next step is you build and what you get out is HTML, CSS and React and then you can deploy it on the... Now I'm reaching the end already but I just wanted to touch on this data layer because I mentioned bring your own data. So there's a question here which is okay I've got my data let's say it's in Contentful and now I need to put that into my React application somehow. So what Gatsby has is this thing called a data layer. So what you do is you define where your data is from and you define how to extract that from where it is and put it into Gatsby and most of the time you can use the plugin. So Gatsby has a pretty rich ecosystem of plugins. There's currently... So I took this yesterday the 748 but there's always new ones being added and plugins do one of three things. They source data which means they put it into the data layer. They transform data which means they take data that's already been put into the data layer and transform it somehow and finally plugins can also work on other plugins so if you really like plugins then you can put a plugin on your plugin. Now if you're... So this is an example of what a plugin might look like but also if there's a plugin which doesn't suit your needs then you can specify your own ways of source data. So this is just an example. So exports.source nodes is part of the Gatsby API. So this is a specific function which you will use and it gets called with a bunch of things and what you do is in here you can fetch your data. So for example if your data is residing at mydata.com, excuse the typo, then you can fetch that data and let's say you get a JSON object with your blog content. You then do a little bit of transformation to get it in a format that is suitable for the Gatsby data layer and then finally at the bottom you call create node with all this data. So as you can see there's a couple of things there like ID, parent, children and so on but my data itself is also going in there so what you end up with is you end up putting your data into the data layer. So once it's in the data layer you need a way to actually access that data in your React applications and the way that Gatsby lets you do that is it exposes a GraphQL interface. So you can think of the data layer now as like it's your virtual backend I guess. You've specified that you want some data to be in there and then the next thing you're going to do is you're going to access that data from your components. So the way you do that is I'm not going to go into GraphQL itself because I think that would be that's kind of a separate topic but you write a query that looks something like this. You specify the type of your node which if you look down here you specify a type here and that corresponds to the type that you access here and then you kind of have to traverse a few layers of standard interface so edges and node and then you finally get to the data that you have put into the data layer. So once you get to this point you have this is essentially what you've got what you've fetched here. So that's how you access it and the rest of this is GraphQL syntax so that's if you're familiar with that then this should look very normal to you and basically you get this data passed to your component as a prop. So specifically in Gatsby the way you do this is in a single file you'll specify a single component and a single query and it will do a little bit of magic and give you the output of that query as a data prop. So data dot all my node type and it's an array so then you can access that in your component. There's a couple of other ways of doing it as well. Those of you familiar will know about like static query and stuff like that same principle. So that's basically it. I don't want to get too in-depth I think it's probably easier if you see stuff happening so I will defer that to the next speaker but I just wanted to give everyone like a super high-level overview of what Gatsby is. A little touch on the data layer as well because I was confused by that myself when I first started and yes I'll take any questions. So the question is how does Gatsby differ from other static site generators. I've only used one other one which is react static and I can't remember how that one works so I'm afraid I can't really give a good answer to that. I like to open it up to the floor though if anybody has like done a static site generator show off a show down sorry. Okay so I think that was a response to your question which was basically that a paraphrase let me know if I'm wrong that Gatsby is a lot more flexible in terms of how you get data into your site. So something like Jackal you use a markdown but with Gatsby you can you can get content from markdown so you can write markdown files in your project and then source them and transform them into HTML or you can get them from basically anywhere else so from from files on the file system remote resources across the network anything you can think of. I think the cool thing is that you can use GraphQL to access all the different data sources so you have this unified data layer to access markdown files you know REST APIs, other GraphQL APIs, strike you know whatever you want. So the question is if I have a website which has some parts of it that are protected by authentication does the data layer allow authentication. So let me answer a separate question first which is that you can you can mix you can have a hybrid solution in terms of the pages so the pages themselves can be protected by authentication you don't have to you don't have to have one HTML page per URL root that you want so you can put you can put a section of your app can behave exactly like a traditional traditional React single-page application in terms of the data layer itself though I don't know because the data layer because at runtime the data is already there the data is already loaded into the data layer the data layer itself is kind of not it's gone at runtime right it's just existed like develop and build time so I'm not sure about that actually I suspect that if you wanted to do that you'd have to keep that data outside and host it or protect it like you normally would in a in a dynamic web application sorry yeah yeah I think what we generally do is you can use the whole off it was kind of a third-party off provider like off zero and you would then have the content in an API and you would perform authentication only if you know if the user is authenticated they would be able to access the content from the API at that point it wouldn't be static though yep wow you got me there man I really don't know let me let me think I've no internet so I don't know I don't know that one anyone know that it's a big party of all the different I believe it okay okay what do you mean exactly so sorry the question is so the question is can you still access the GraphQL after it's built so I believe the short answer is no because once it the whole point of GraphQL is as you're developing it's just a way for you to declare what data you need in your components so once it's built there is no GraphQL server running anywhere the GraphQL server is just running as you're developing while it builds to to kind of keep that data there and then once it's built the data is in in your HTML or your JS or whatever and then and then there's no more GraphQL server but whilst you're developing you can run a graphical server to kind of debug or check what data you have is Gatsby highly dependent on GraphQL I believe it is I believe that's an opinionated decision that that is the tool that the the authors of Gatsby have decided to expose for for users of Gatsby as far as I'm aware there's no well okay as far as I'm aware there's no alternative to GraphQL but you GraphQL is the way you interface with the data layer right so how much data you need in the data layer is dependent on your project so so you could have a project which doesn't get any data from the data layer which does which gets it all like through an Xios request or something at at runtime let's say maybe your data is changing very frequently or it needs to be protected behind authentication then you would not put your data in the data layer to be built into the output so it's it's not possible it's not it's not mandatory to kind of if you're against GraphQL it's not saying that you have to use it to to work with Gatsby but it is a big part but but the data layer itself is a big part of Gatsby and the way you interface with that is through GraphQL yeah so so the Gatsby documentation is actually pretty good it doesn't assume any knowledge of GraphQL or even React there's a section there's actually a couple of sections on React itself so it's it's pretty good