Creating A STRAPI BLOG Using STRAPI NextJs And Webhooks

# Creating A STRAPI BLOG Using STRAPI NextJs And Webhooks [Next.js](https://nextjs.org/) is one of the most important and widely-used React frameworks. Today, it has become a consolidated framework for building amazing web applications. Many advantages can be listed when using Next.js. Performance, SEO, rich developer experience, TypeScript support, smart bundling, and route pre-fetching are just a few examples. Besides all of the amazing features that Next.js has to offer, there’s one in particular that is very powerful and amazing: the ability to use different pre-rendering techniques. We can work with Client-Side Rendering, server-side rendering (SSR) and static site generation (SSG) in the same Next.js application. We can also have our server-side rendered application and still have some generated pages inside. - with next js we can render our react application on the server or we can render it on build time, it actually gives us three different architecure models for rendering our application, we can do csr, ssr, ssg and we have to pick each one on a per route basis , it could be pretty complex but we are going to walk thru it. In this article, we will be looking at the advantage of each rendering method provided to us by `Next.js`, Then we are going to build and deploy a Next.JS SSG application to Vercel using, then how we can set up a `webhook` using a Strapi headless CMS for our backend, The Strapi webhook we help us immediately update, rebuild and redeploy our next js SSG application data when new content are added. Using Next.js SSG our Strapi server is not being hit on every request, this can save on cost. ## Prerequisites You'll need a basic understanding of the following to proceed - Basic knowledge of JavaScript for `Node.js` - Basic understanding of `Next.Js`. - Basic understanding of strapi. [click to know more](https://docs.strapi.io/developer-docs/latest/getting-started/introduction.html) - Git and GitHub - Vercel account ## Next.Js Rendering Method and Usescases ### **Client-Side Rendering** - Client-side rendering is great for logged-in experiences and single-page applications. If you need to authenticate a user on every interaction, CSR is the way to go. - How does it actually work? In Client-side rendering majority of the work is done by the browser and on-demand basis as requested by the user. 1. The client(browser) requests a page by entering a URL. 2. The server responds to the browser with a blank page, with references to the javascript files attached. 3. These are downloaded and run by the browser and used to build a page. 4. Data is mainly fetched by API calls on the client-side. **Implementation** Let’s take a look at the implementation of a client-side rendered page in Next.js. Although we don’t have any particular function in NextJs to make use of it we’ll call an API using a hook like `**useEffect**` In this case, the server isn’t doing any of the work. The client will receive this code, make the request itself and build the page. In next js In some application we might want to stall rendering until when we get to the client, - Ecommercer app cart - checkout page Client-Side Rendering, this is the usual kind of data fetching using `useEffect`, it will fetch the data from the API every single page request on the **client-side** (after the page is rendered, then the function will run) ## **Server-Side Rendering** - Server-side rendering is ideal for creating pages for slow connections and greatly helps in SEO. How does it actually work? Server side rendering is done on the server so all the work is finished before the site reaches the browser. 1. The client(browser) requests a page by entering a URL. 2. The server receives the request and runs the attached javascript and then the DOM is constructed. 3. The server requests the data and feeds the data to the component as props. 4. The server builds the HTML and sends the complete page in the response to the client. **Implementation** Let’s take a look at the implementation of a server-side rendered page in Next.js Exporting this NextJS function `[getServerSideProps](https://nextjs.org/docs/basic-features/data-fetching/get-server-side-props)` will instruct the application to retrieve its data before leaving the server, and feed that to the component as props. The HTML is then rendered and shipped to the client. Modern JavaScript frameworks have made our lives as developers much easier. We can create powerful, rich web applications using many different rendering techniques. You have probably heard of single page applications before. A single page application is an application that is rendered at the client side, even if the data might be fetched from the server. Server-side rendering (SSR) is the exact opposite of this. SSR describes the process of pre-rendering the page on the server, which is then generated upon each user request. When the pre-rendered page reaches the browser, JavaScript code is run to make the page interactive. This whole process makes the load speed faster. It also makes it easier and preferable to use server-side rendering for applications that depend on SEO. Next.js does this work out of the box. By default, it will try to detect which pre-rendering technique your application is using and fetch your data. Years ago, before JavaScript became so mature and powerful, developers usually returned HTML files based on HTTP calls. It was a very common technique to process the response on the server side using a server-side language (usually PHP) and returning a static HTML file. - SSR - Server-Side Rendering, will run a **special function** to fetch data from API every page request on the **server-side** (before the page is loaded, that special function will run first, creating a delay, then after that, it will serve the page)**.** ## **Static Site Generation** - Static site generation can be of great use in case your website does not depend on any outside data and serves static pages which hardly change. - How does it actually work? Static-site generation compiles and renders the website at build time. The output is a bunch of static files including the HTML file itself and assets like javascript and CSS. 1. When the browser receives the page, it’s usually a simple HTML without a lot of content. This then loads the scripts to pull the content into the page, a process also known as hydration. 2. With Static Generation, it tries to render that page mostly like it would in the browser but at compile time 3. This gives us the ability to serve the entire content on the first load. The scripts still hydrate the page during this process, but ideally with fewer changes or no changes at all. **Implementation** Next.js provides [different APIs to fetch data](https://nextjs.org/docs/basic-features/data-fetching/overview) . If you only use `getStaticProps` to fetch data, Next.js will fetch that data at build time, leaving you with a completely static page. Just like `getServerSideProps`, we feed the data into our components as props at build time, and the page gets generated into a static page to be served on request to the client. If you want to create dynamic routes you can use `[getStaticPaths](https://nextjs.org/docs/basic-features/data-fetching/get-static-paths)` Next.js will statically pre-render all the paths specified by `getStaticPaths` Just like `getServerSideProps`, we feed the data into our components as props at build time, and the page gets generated into a static page to be served on request to the client. If you want to create dynamic routes you can use `[getStaticPaths](https://nextjs.org/docs/basic-features/data-fetching/get-static-paths)` Next.js will statically pre-render all the paths specified by `getStaticPaths` Static-generated websites are nothing new for developers. We have been building them since the beginning of the web. Building rich web experiences can be hard, but with Next.js we can do so easily. Next.js has introduced us to a better way of building static-generated websites with more dynamic performance. SSG describes the process of building websites that render at build time. The output is an HTML file, assets such as JavaScript and CSS, and a few other static files. When using SSG with Next.js, the page is pre-rendered at compile time. That means that the user won’t have to wait for the page to load at the browser; the page will simply be rendered. For data fetching, Next.js provides three different functions: - `getStaticProps` : The page will be pre-rendered at build time - `getServerSideProps`: The page will be pre-rendered at runtime - `getStaticPaths` : This function generates a list of pages that will be pre-rendered at build time The biggest disadvantage of using SSG is that the build time can get very long. You won’t have a problem when you have only a few statically-generated pages, but as your application grows, the build time will increase. The worst case scenario is when you have hundreds of statically-generated pages. The build time will take a long time, and if you have dynamic content on those pages, you can end up with too many builds. - SSG - Static Site Generation, will run a **special function** to fetch data **once** when that page builds. ## Why SSG Application? Static site generators **reduce site complexity**. That, in turn, improves speed and reliability, and smooths the developer experience. SSG exists to serve a specific use case, serving dynamic pages built in React as HTML. What's the benefit you ask? - **SEO**, search engine optimisation is one of the top benefits of doing SSG as it make indexing the pages easy for the crawlers. - **Speed**: As you can guess, serving an HTML page is much faster for the end-user because the browser doesn't have to do much processing upfront. The pre-rendering makes it easy for the browser to fetch the HTML and render it straight up. - **Caching with CDNs**: Building HTML pages opens the possibility for CDN caching to show its charm. The pages are stored closer to the user globally and hence can be accessed much faster. Every request doesn't have to wait for the server to render the page, it just receives the page from CDN, saving us compute resources and money. ### [](https://dev.to/anshuman_bhardwaj/what-the-heck-is-ssg-static-site-generation-explained-with-nextjs-5cja#use-case)Use case While you can use SSG in any scenario as long as the page can be rendered at the build time, here are some popular use case patterns for SSG - Marketing websites - Blogs and documentation, like my own [blog](https://theanshuman.dev/articles) - Portfolio websites > Tip: An easy way to know if you should use SSG is by answering: "Can you pre-render the page ahead of a user's request?" If the answer is yes, then you should choose Static Generation. ### How to create a Next.js SSG app Getting started is as simple as running a single line in the terminal. Open up the directory you’d like to create your project in and run: ``` npx create-next-app my-static-nextjs-app ``` After the installation is complete, you can navigate to your new project directory: ``` cd my-static-nextjs-app ``` Once there, start your development server: ``` npm run dev ``` And once the server is ready, you can open up [http://localhost:3000](http://localhost:3000/) in your browser where you can now see your new Next.js app! Next.js makes it really easy for us to pick the correct pre-rendering technique for each page. Remember, we learned that Next.js does static site generation by default. It simply works out of the box. However, it will try to detect which pre-rendering method you’re using for each page. Building Static pages with Next.js is simple. It works pretty similarly to building any other page i.e by creating a new file in the `pages` directory. Strapi comes with a full featured [Command Line Interface](https://docs.strapi.io/developer-docs/latest/developer-resources/cli/CLI.html) (CLI) which lets you scaffold and manage your project in seconds. The next js now has statis site generaation and in this article we are going to be exploring how that wrks The thing with ssg it is great when you have a lotof different page on your sitem, which are basically the same thing you have kinda of like a template, that you want to reuse, but you want to put different data in it, and this data you want it avaliable to you at build time, you want to generate this pages ahead of time and put on our website, a great use case of this is a blog. We are build ing a simple blog all wwe have is two post In a ssg you need to have basically two things, you need to have your emplate and yoou need to have thhe data you need to pump to your pages If we want dynamic pages we want dynamic routes, so the way we do this in next js is to use brackets in our file name, inside of it we give the dynamic file and param name we are going to use slug This is how we do things in cnext js we create a component and export it then next js creates a routes for us based on that Next js introduce two new functions we can use for static site generation the first one we be using is the `getStaticPath` In this function we are going to return an object a path property which is an array, and fallback we are setting it to false which means build every thing at build time The `path` to tell nextjs what how different paths are `getStaticProps` this function is used to fetch the content of out posts Deploying Now we have this whole system setup we can create blog post and auto generate pages for us, one last thing we have to look at ssg is how to go about deploying themm - Run yarn build This will create an output of a genrated next js project - To make it static we will add a script called ecport and a command called next export This will take the build next js code and generate a static site from it The cool thing about this is when we run yarn build we can see the pages we have created seeing what kind of pages they are we can see we have two pages and they are ssg we can see that we have to pages the blog page and the index page both ssg generated, next js auto generate 404 page sfor us after this we yarn export What this will do is generate the static site - SSG SSR SS CSR Usecase SSR - search - query SSG - Homepage - When you dont want to run the server - Product details page. - It generates static pages files for every one of our post, It takes a while to build and slower, SSG How get fresh data into our ssg sys we have to options using revalidate: `time` It went off and got new data, this is really nice when you have a high traffic page where the serious content dont change that often, eg ecommerce applications review page, comments, product detail page, homepage, The give you the ability to revalidatin a page but throttle aat the level you want. The revalidate this # Setting Up Strapi - Creating Model - Open Model FOr Use - Setting Up Next Js Application - Deploy Strapi To Host Of Choice - Deploy Next Js On Vercel - Setting Strapi Web Hook For Our SSG ## Conclusion Next.js has become one of the most important React frameworks in the web community. It brought to developers so many features for helping to build more complex and rich websites. Using a framework like Next.js allows us to use different pre-rendering techniques on our applications. We can use static site generation for something more simple and non dynamic. We can use server-side rendering for dynamic content and more complex pages. With these tools, building rich web applications has become easier and more fun. We learned that we can use Next.js and the concept of Static Generation to statically compile an app. Tools like Next.js can do this by compiling our code, similar to what we might see in a browser, so that by the time our app hits the browser, it’s all ready to go. With a simple command, we can also build and compile our app, as well as export it into static files. We can deploy those static files to any static storage service like Vercel or AWS S3. This provides us with an easy way to craft dynamic web apps that are fast and cheap. Learn more about how Next.js leverages its different APIs to provide both static and dynamic experiences by [visiting the Next.js docs](https://nextjs.org/docs/basic-features/data-fetching).