So first let's know what's the knowledge base and why are we picking a knowledge base instead of a normal blog or a news website or something like this. So, a knowledge base is a self-service online library. It's a place where you put all the data and your knowledge dump, everything you have, either to help team members or customers.
So for example, if you are a company and you want to have some place where the new employee will jump in when they join and understand how the onboarding works, how the communication works or something like this, you can have a knowledge base in place. If you are a company that's providing service for customers and you want to document everything you want in some place, instead of having everyone having a question asking the customer service, you can just create a knowledge base or like a help center or a place where you double click on a page and you can put all the FAQs and articles and you can put them into categories and stuff like this or troubleshooting guides. And yeah, the customer or the team members would just join, jump in, find the right answer to the question instead of bothering you with multiple questions.
Today, we are going to build a homepage, a categories page, and a page for every category and for every category we'll have a bunch of articles that will have also a page of rich.
So first, let's talk about how websites are rendered, because the concept of static site generators are very new, or not new, but like a lot of people don't know how static site generators work. So let's go from the start. How do websites get rendered? At first, when the internet came out, there was only one way to render websites, so it was called server-side rendering. Well, there was no name because it was just the only way to do it, where you have a server and the client and the client or the user type the URL into the browser and then send an HTTP request to a server, which does the magic, generates a whole HTML page with everything you would need, and then get, like, pass it back to the browser where the browser would paste the HTML and render it in the browser.
And then every time you want to switch to another page, like you want to route, if you are in a home and you want to go to help or something, you would click on an a-link, on a-tag, that would send another HTTP request, get the whole HTML from the server and then replace everything with this new HTTP. The server uses templates to dynamically generate full HTML pages. So you have, for example, a PHP website where you send, if you send like a GET request to this page, it will be handled and then it will put all the variables or the actual data into an HTML template and then send it back to the browser.
And after a while, a new concept came out called client-side rendering. It came out usually with single-page applications or like with the generation of sending API requests. So you still have a client and the server and then you send the first API call to the server and then you get an empty HTML page with a bunch of JavaScript scripts attached to it and then the client or the browser would take it and give the JavaScript control to fetch everything you need from the server with API requests and then directly manipulate the DOM or the HTML in the page. So instead of having everything sent back like before, now you get a very placeholder HTML page that doesn't have anything meaningful, just a bunch of scripts and then these scripts take over and generate the actual HTML.
So as you see here, the client renders the empty page and JavaScript renders the content later. And if you're looking into this in some aspects like render time, the render time here is inconsistent because the client is actually the one doing the real job while with multiple clients there are multiple performance, like if you have a high-end PC it's different than having a very low-end mobile phone. And for SEO, search engine optimization, it was very bad when it came out because the crawlers before this uh like the search engine crawler and the crawlers are like a bunch of scripts that search engine used to crawl the web and archive their data so that when you search for something you would have everything there.
So the crawler would go into a link and get an empty HTML page and find no meaningful content in it and then this way you get an empty page that doesn't get archived or it would be very bad for SEO ranking for it. After a while a lot of crawlers or a lot of search engines adapted but it wasn't this fast and it wasn't like working 100 until recently I guess. the build time was super fast and caching was happening only on the client side because yeah like you don't you get only you get you get every time you get the same page so there's no caching that can happen but the client was caching the API requests on the client it depends on how you configure it of course but like normally it would cache it but it wouldn't thing and to fix this issue with the SEO mainly a new concept came out which is a mix from the first thing which is server-side rendering and the second thing clients client-side rendering so for single page applications every time you send the first API call sorry the first HTTP request instead of having a very empty HTML page sent to you you would have like that server would do the first render like it's happening on the client and then send you the full HTML page where the client would render it and then happen something called rehydrate where you will you will rehydrate the state and work as a normal single-page application.
So JavaScript would still take over but this way if a search engine crawler comes into a page like this you would get everything it needs from the first different thing. Some aspects of this is the render time was slow of course slower because the server would still generate the HTML or like render the first render on the runtime but this fixed the issue because the crawler would get the full HTML page. The build time was fast because you were yeah still the same as the other one at the client-side rendering and the caching you could do at this stage using a third party like Cloudflare and some frameworks added it later but it wasn't it's not there out of the box. And this was fine until a content-driven website were like very famous.
So what's a content-driven website? A content driven website is any website that is mostly like the most main object of it is to deliver content instead of like having a lot of tasks tasks in it. So not a dashboard or like not a social media app, not a web app, but some website that it's like it has a lot of content that's mainly like text rich text assets like images and stuff like this, like a blog and news website, a company website, marketing websites, or a knowledge base. And when the content-driven websites had the static site generators, came out.
So what's a static site generator? So we still have a client and a server. But there is something happening on the server, even before you ask for the call. You asked for the HTTP request. So what happened is that you do everything as a normal single-page application, but instead of fetching the data and rendering on the runtime, you do it on the build time. So the server-side generator, the static site generator, would take all the queries that you have and fetch them ahead of time, and generate actual HTML pages and build them on the server. So that every time you want to have an API call, sorry, an HTTP request, you would send the HTTP request to the server and server would give you that prerendered HTML page ready for you to go. And then the whole operation continues like normally, the server-side rendering. So the app would still get rehydrated and the single page application takes over. It doesn't only generate these, but it also takes care of routing, so you would be generating a bunch of JSON files that have the data for other pages. So instead of sending multiple API calls to get also the content for the other pages, you would just fetch this JSON, put it on the template, and here you go. You have the other page ready, even after the single page application starts working.
So for aspects here, render time is faster, because there is more render. Like most of the job is already done in the build time. ICO is super good because crawlers can now... Can now fetch the data faster than ever. The build time is lower, of course, because you are doing a lot of stuff and you also take more space. But if you're talking about a bunch of HTML pages, it doesn't really look like a space. And caching, of course, is supported, because the HTML pages are there, and also most of the frameworks support caching out of the box.
So, to summarize this, the client side rendering, the render time is inconsistent, ICO is bad, build time is fast, and caching will happen only on the client side, the server side rendering, render time is slow, ICO is good, build time is fast and caching you can do through a third party, like partially supported. Static site generator would have faster render time, a good ICO, a slow build time, and supported caching out of the box.
But the limitation here for static site generator would be you have to have a static site to use a static site generator, you know? It's literally in the name. So you cannot do this for a dashboard, you cannot do this for an app that has a lot of stuff that are very different like, for example, a username or a user data. You can't use this for like a profile page for all the users because you cannot generate pages for sensitive information, you know? But you can do it for a news, for a news website, for a blog website, or, yeah, in our case here, knowledge base.
And that takes us to Gatsby. Gatsby calls itself a modern site generator, not just a static site generator because they have adapted to most of the modern requirements and they can offer you everything, mostly everything you need when related to normal websites. And the very nice thing about it is that it supports most of, well, like, yeah, almost everything out of the box. It's built over React. So if you have a knowledge with React, like even familiar with React, then learning curve is very shallow for you and you can easily, like, yeah, in a couple of days you can get something working with Gatsby. It's very easy. It didn't take me a lot of time to to work with it. So it should be super easy.
And let me make something here super clear that what I'm trying to to accomplish today is that not just not show of that Gatsby or like this kind of scales, but I want to show you how easy it is to build something. And later, when we we use Contentful, I want to also show how easy and fast it is to migrate from something that's very static to something that's super dynamic. And also with the deployment, it should be easy and straightforward for you.
So that takes us to the end of the theoretical part. And now we should jump into the code. So before, before we get into this, so we have a Q&A panel that you can find in Zoom where you can ask questions that only the panelists would find and then we can answer them later, or you can just drop your question in the chat. We also have with us Matt Van Voorst, we are very happy to have him here, he's a software engineer from Contentful and he will be happy to share with us or answer any questions related to Contentful. So, yeah, that's it, let's jump right in.
Comments