Create fast, SEO optimized frontend web apps with zero config

1. Allows to build the content on the server so the 1st thing a user or bot sees on landing is fully rendered HTML.Hence, amazing SEO
2. After that traditional CSR takes over and it works just like a regular web app Hence, amazing UX

Key concepts :

What is Client Side Rendering (CSR) ?

1. A traditional React App is rendered client side
2. Browser starts with a shell of an HTML page (empty) lacking any rendered content
3. From there, the browser fetches the app.js file containing the React code to the page and make it more interactive

What is Static Site Generation (SSG) ?

Pages are rendered at build time

FEATURES :

1. Generates HTML pages at build time.
2. HTML is rendered on the server and uploaded to a storage bucket or static host
3. Delivered with high performance over a CDN

DRAWBACKS

1. Data may become stale ⇒ need to rebuild and redploy site when server side data changes, to implement the changes
2. Hard to scale ⇒ **Difficult to render all pages if website has too many pages

APPLICATION

1. Data that doesn't change often
2. Sites that have relatively low number of total pages (eg : blog ⇒ few 100 pages that don't change on a daily bases)

What is Server Side Rendering(SSR) ?

Pages are rendered at build time

FEATURES

1. Generate each page at request time
2. Ideal for data that changes constantly as end user always gets the latest data from whatever data source it exists on

DRAWBACKS

1. Slower ⇒ Far less efficient as we gotta respond to requests instead of caching it all on a Global CDN
2. Inefficient data caching

What is Incremental Side Rendering(ISR) ?

Regenerate pages in the background

1. By simply adding a revalidate option to the SSG function (atleast in Next JS),  a page can be regenerated after a fixed time interval
2. A server rendering strategy midway between SSG and SSR.

Main features

1.  "pages" directory

A file structure that mimics the routing setup in the app

1. Directory inside a Next project
2. Each JS file defined here exports a React component that represents a route in the app
3. Next exposes its own Router to make navigation seamless
4. _app.js ⇒

• exists at highest level
• main entry point into the app
• every individual page will start from this template

1. When a user navigates to an internal route URL (specified by the PAGE_NAME.js or DIR_NAME/PAGE_NAME.js files), Next will look for the default export component in the app and render it as a component Thus, every file here must have a default export component
2. DYNAMIC ROUTING ⇒ [ PAGE_NAME.js] - " [ ] " make the route dynamic
3. useRouter( ) ⇒ hook in Next JS to access the query parameters from the URL

2. "api" directory

1. Special part of Next for setting up routes that'll act as an integrated server
2. Useful since the code written here won't increase the client side JS bundle that needs to be ultimately sent over the net
3. Useful when :

• Work is to be done on the backend
• You wanna expose on an API for your end users

3. Styling

1. globals.css ⇒ Styles apply to the whole Next app
2. *.module.css ⇒ Component specific styles
3. Import the stylesheet into a component simply as an object and call styles as if referencing properties on a JS object
4. Can write actual CSS syntax inline

4. Server Rendering Strategies

Implementing SSG

1.  getStaticProps( ) ⇒  tells Next to pre-fetch the props for the component's prerendering

2.  getStaticPaths( ) ⇒  tells Next to pre-fetch the dynamic paths for the component's prerendering

• Since we're working with dynamic routes, we gotta inform Next about the pages we gonna associate with this route/URL
• eg : To prerender (SSG), all the "id" routes associated with the "cars" route on a website ( Route - website.com/cars/paths ), we gotta inform Next about all these ids in advance

3. getServerSideProps( ) ⇒ Fetches the props for the component's rendering at request time

• Can copy all the code in a getStaticPaths( ) function and use it here. Next will implement the data handling under the hood for us
• Don't need getStaticPaths( ) here as each page is generated at request time so we don't need to inform Next in advance about any routes as there is no prerendering done

5. SEO

1. Can import Head from "next/head" and easily apply custom meta tags for each and every single page in the pages directory
2. Anything inside the Head component will be rendered at the head of the doc as title, meta-tags, etc.

Custom MetaTag component

1. Pass props to it from every single page to get next level custom SEO, for each page

import Head from 'next/head'

const Meta = ({ title, keywords, description }) => {
  return (
    <Head>
      <meta name='viewport' content='width=device-width, initial-scale=1' />
      <meta name='keywords' content={keywords} />
      <meta name='description' content={description} />
      <meta charSet='utf-8' />
      <link rel='icon' href='/favicon.ico' />
      <title>{title}</title>
    </Head>
  )
}

Meta.defaultProps = {
  title: 'WebDev Newz',
  keywords: 'web development, programming',
  description: 'Get the latest news in web dev',
}

export default Meta
va

Export a static website

1. Add a script for next export  or just integrate it into the build script
2. When we run next build it runs for production (.next folder includes our server and stuff) and when we deploy to host, we deploy everything
3. However, when we export, it just goes into a folder called out  and it is just a static website
4. When it is deployed to server, as seen in the .gitignore file, it is the out  directory is NOT deployed.

NOTE : "serve" is an NPM package to serve static sites, SPAs, static files

serve -s out -p 8080

Conclusion

Technologies embracing these performance and SEO optimizing technologies are already taking over the software development decisions by a storm and soon they'll be industry standard.
It's gonna be a exciting future of saying goodbye to slow and irrelevant clickbait webapges