Server side rendering

Your Responsive Ads code (Google Ads)

Table of Content

• What is server-side rendering? 
• Why SSR?
  • Highly Secure Application
  • Compatible Websites
  • SEO friendly Websites
• Drawbacks of SSR 
  • More Server Load
  • Latency on Response
• Hydration, what in the world is this thing? 😵
• Why is hydration needed?
• Server-side rendering in NextJs

What is server-side rendering? 

Server-side rendering is basically web pages being rendered by the server and sent to client's machine in the form of HTML. 

An example would be great.

Imagine nothing but YouTube. The video Thumbnails you see in YouTube when you use it are all server rendered contents meaning they are all processed by server alone and shown directly to you. The client's machine processes nothing before the content is loaded. 

Once the content has been loaded, server hydrates the client's device by making necessary JavaScript files available to the client's machine and executing it. After the process of hydration is complete, the client's machine can interact with the content using its own resource without the need of refreshing the page or any kind of glitch. We will be talking about hydration later in this blog.

SSR working mechanism, by Sushant Jung Thapa

Why SSR?

There are great advantages of server-side rendering aka SSR. Some of them are listed below:

Highly Secure Application

Server-side rendering makes server manage all the cookies needed for the website. 
Also, private API calls happens solely in the server.
It also handles the data validation which is a bulky process. 
This means our private data is never exposed to the client.

Compatible Websites

Server-rendered web pages can be loaded in old browsers without any hassle because the content is already processed by the server and disabling JavaScript will also have no effect which ultimately means browsers without any JavaScript can also run the pages just as the other browser.

SEO friendly Websites

Server-rendered pages are sent to the client's machine as soon as the rendering process is finished. So, search-engine bots and web-crawlers get the page instantly which makes pages more SEO friendly. But in case of Client-side rendering aka CSR, search-engine bots and web-crawlers have to wait for some time for client to render the page completely which decreases the Search Engine Optimization.  

Thanks to SSR, we get very cool features for making our pages more secure, compatible and SEO friendly, but these features come at the cost which are mentioned below:

Drawbacks of SSR 

More Server Load

Needless to say, the server faces a certain amount of server load in each request on the server as it needs to render the HTML page and executes function at the server only.

Latency on Response

It is as clear as crystal that there is delayed response on each request because of the same reason mentioned above that is sever needs some time to execute the content and function defined in the page.

Hydration, what in the world is this thing? 😵

The thing called hydration is nothing but making a static HTML page received either from SSR or SSG (Static Site Generation) dynamic by attaching event listeners and handlers from client-side JavaScript injected by either of the process, SSR or SSG.

Why is hydration needed?

As we have already discussed above, the main use of hydration is to make the HTML content dynamic by adding event listeners and event handlers using injected JavaScript. It's basically used for DOM manipulation using JavaScript.

Server-side rendering in NextJs

We can start by looking into below example. By the way I'm using Typescript, If you don't know about Typescript, you can check out their official handbook. 

import { GetServerSideProps, InferGetServerSidePropsType, NextPage } from 'next';
import Head from 'next/head'

interface User {
  id: number;
  name:string;
  username:string;
  email:string;
}

export const getServerSideProps: GetServerSideProps = async (context) => {
  const res = await fetch('https://jsonplaceholder.typicode.com/users')
  const userData:User = await res.json()
  return {
    props: {
      user : userData
    }
  };
};


export default function Home({ user }: InferGetServerSidePropsType<typeof getServerSideProps>) {
  return (
    <>
      <Head>
        <title>Tech Backward</title>
        <meta name="description" content="Generated by create next app" />
        <meta name="viewport" content="width=device-width, initial-scale=1" />
        <link rel="icon" href="/favicon.ico" />
      </Head>
     <main>
      {user.map((user:User)=> (
        <div key={user.id}>my name is {user.name}</div>
      ))}
     </main>
    </>
  )
} 

In the above example I've used a async function called which is getServerSideProps which is provided by NextJs itself. NextJs will look for this function during the build time and make the content dynamic by rendering it in server only. Every line of code written within the scope of this function is rendered in server.

An object returning a property called props is passed inside the getServerSideProps  which is a must while using this function as the props property is required to be passed into the page component so that our page can use it.

After we run this code, NextJs always render this page dynamically. If the data from the source is mutated, the page content is also mutated.

NextJs always renders the entire page content on the server which do not disclose certain API such as window and browser. Here comes Client-side Rendering (CSR).

Learn the 123 of Client-side Rendering with us.😜