briefcase (1).svg

AppUnite

github (1).svg

PatrykBuniX

instagram (1).svg

@patrykbunix

bookmark.svg

large_profilep-small.jpg

medium_profilep-small.jpg

small_profilep-small.jpg

thumbnail_profilep-small.jpg

profilep-small.jpg

## The Goal

I'm one of developers who were responsible for creating a website you are reading this article on. We wanted to create a separate blog page for each AppUniter to streamline the article writing process and create a sort of private space where they could publish all their posts. The goal seemed pretty simple:

- create a web app,
- make it accessible on wildcard domain (`[author-slug].appunite.com`),
- serve author's data and posts based on url's subdomain `author-slug`

### Technology stack

**[Docker](https://www.docker.com/) + [Kubernetes](https://kubernetes.io/)** - We used container orchestration system for automating deployment, scaling and load balancing. We had to configure ingress controller to make our app available at `[author-slug].appunite.com` domain.

**[Strapi](https://strapi.io/)** - fully customisable headless CMS - each author is able to create an account, specify an `author-slug` (the subdomain on which their blog will be available at), fill in their personal info (like bio, avatar and social media links), specify sections they want to display on home or subpages and publish posts. We can access all this data by hitting Strapi's endpoint with author's blog `author-slug`.

**[Next.js](https://nextjs.org/)** - React framework with hybrid static and server side rendering, TypeScript support, API routes, optimised builds and more. With such a framework all we had to do was to:

- create views for pages (home and subpages) and for posts,
- get posts and author's info from Strapi based on author's `author-slug`
- hydrate the page with fetched data

## The first solution

As mentioned above Next.js has the ability to pre-generate all the pages on build time and even revalidate pages with stale data ([Incremental Static Regeneration](https://nextjs.org/docs/basic-features/data-fetching/incremental-static-regeneration)). Next's static pages are well cached and very fast by default, so the solution was clear: Let's **pre-generate all the pages and posts**! But...

<img style={{maxWidth: "300px"}} src="https://c.tenor.com/QSFMj0VddAQAAAAC/hold-on-wait-a-minute.gif" alt="Something ain't right gif" />

It's not possible to pre-render a page for each author and make all of them accessible on a root path (`/`), that's not how static site rendering works! Every page must have specified path: strictly defined (like `/about`) or dynamic (eg. `/post/[slug]`), so we have to find a way to generate static pages for each author at `/[author-slug]` path and make their content available at `[author-slug].appunite.com/` using **ngnix location redirecting**.

After a 3-day battle (a lot of `500` and `404` errors or infinite `301` redirects) with ingress and nginx configuration, with a lot of help from one of AppUnite's devops (thank you so much Michał!). We were able to achieve the desired effect using this configuration:

```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: blogs-authors-ingress
  namespace: appunite
  annotations:
    kubernetes.io/ingress.class: nginx
    ingress.kubernetes.io/ssl-redirect: "true"
    ingress.kubernetes.io/secure-backends: "true"
    ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/server-snippet: |

      server_name ~^(?<author-slug>.+)\\.appunite\\.com$;

      set $proxy_upstream_name "appunite-blogs-80";
      set $proxy_host $proxy_upstream_name;

      location = / {
      	proxy_pass http://upstream_balancer/$author-slug?$query_string;
      	proxy_redirect off;
      }

      location ~* "^/" {
        proxy_pass http://upstream_balancer/$author-slug$uri?$query_string;
        proxy_redirect off;
      }

spec:
  rules:
    - http:
        paths:
          - path: /
            backend:
              serviceName: blogs
              servicePort: 80
  tls:
  - hosts:
    - "*.appunite.com"

```

What's happening here?

We declare the name of a domain whose requests we want to redirect. Using **regular expression** (`(?<author-slug>.+)`) we can access matched author's slug to map it later to the `/[author-slug]` path.

- All the requests to the root path (`<author-slug>.appunite.com/`) gets redirected to `/[author-slug]` page.
- Requests to the rest of subpages (eg. `<author-slug>.appunite.com/post/[slug]`) are redirected to `/[author-slug]/post/[slug]` (path remains the same thanks to nginx `$uri` and `$query_string` variables).

It did work! We were able to access the page at `[author-slug].appunite.com`, but the page was... ugh... empty!

Nginx was redirecting all the requests to `/[author-slug]` path and our app was not able to access any resources statically hosted by Next.js in `/static` or `_next` directories (which of course do not exist under `/[author-slug]` directory). 

We had too define two extra locations to nginx configuration:

```yaml
location ~* "^/static/(.+)" {
  proxy_pass http://upstream_balancer/static/$1?$query_string;
}

location ~* "^/_next/(.+)" {
  proxy_pass http://upstream_balancer/_next/$1?$query_string;
}
```

From now all the request to `/static` and `/_next` paths (and all the subdirectories and files) were no longer redirected under `/[author-slug]` path. Unfortunately we were not able to use Next’s Image component (because of redirects, `next-image` couldn't properly generate optimised images), so we had to use native `<img/>` tag, loosing a little bit of load performance. Besides that, all the styles, images and other assets were fetched successfully!

We’ve published the app with test author account and asked our colleagues to test the product and provide feedback. It didn’t take too much time until Karol did spot a bug in website’s routing. 

Next’s client side routing was adding `/[author-slug]` part to each path. We’ve tried to solve this issue by moving out of client-side routing and making all the links “external” by reading current website’s host name and constructing links this way:`<author-slug>.appunite.com/(subpath without [author-slug])`, but for some reason the links were working properly only when we’ve refreshed the page after navigating to it.

<img style={{maxWidth: "300px"}} src="https://c.tenor.com/1pyHGO_OgjkAAAAC/back-up.gif" alt="Back up gif" />

It was time to take a step back and rethink the solution. In our case, static site generation, instead of performance provided a couple of bugs and so much frustration:

- we couldn’t use Next Image
- no client-side routing
- complicated ingress config
- possible navigation bugs in the future

After intensive google’ing, talking with [Adam](https://asiekierski.appunite.com/) and reading [this awesome article](https://www.smashingmagazine.com/2021/11/nextjs-wildcard-subdomains/) we’ve come up with a better solution!

## Server side rendering with wildcard domain

Next.js has an option to render a page on the server ([Server Side Rendering](https://nextjs.org/docs/basic-features/pages#server-side-rendering)). Using `getServerSideProps` function we are able to access `request` object and read values as cookies, parameters and headers like Content-Type and **Hostname**!

Then, based on hostname (`<author-slug>`) we are able to fetch all the author’s content from the CMS and pass it to the page via props! We have to repeat the same process for all the subpages and blog posts, and voila!

```tsx
export async function getServerSideProps(ctx: GetServerSidePropsContext) {
  const wildcard = ctx.req.headers.host?.split('.')[0];

  if (!wildcard) {
    return {
      notFound: true,
    };
  }

	try {
		//fetching content by wildcard (author-slug)
    return {
      props: { blog: { ...blog, posts, pages }, footer },
    };
  } catch {
    return {
      notFound: true,
    };
  }

}
```

Remember this long ingress configuration from the first solution? We don’t need that any more!

```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: blogs-ingress
  namespace: appunite
  annotations:
    kubernetes.io/ingress.class: nginx
    ingress.kubernetes.io/ssl-redirect: "true"

spec:
  rules:
  - host: '*.appunite.com'
    http:
      paths:
      - path: /
        backend:
          serviceName: blogs
          servicePort: 80

  tls:
  - hosts:
    - '*.appunite.com' 
```

Thanks to SSR solution:

- there were **no bugs** with navigation
- we were able to use Next.js features like **Image component** and **client-side routing**
- no more complicated nginx config
- content changes visible instantly
- architecture became much simpler

Maybe it’s not as fast as if it was static generated, but in our case most of the content is just text and a couple of images, so the performance is not only not bad, but it’s actually pretty good!

<img style={{maxWidth: "400px"}} src="https://strapi-appunite.s3.eu-central-1.amazonaws.com/Screenshot_2022_02_20_at_14_34_52_76d0d2f50c.png" alt="Pretty heigh lighthouse score" />

## Is that possible to achieve the same result with SSG?

Next.js `12.0.0` introduced a feature called [Middlewares](https://nextjs.org/docs/middleware) (beta), which lets us run code before a page request is completed. Based on the user's incoming request, we can modify the response by **rewriting**, redirecting, adding headers, or even streaming HTML. So it turns out, that we can pre-generate all the pages on build time and then rewrite incoming request to matching page based on its **Host** header.

For now we are happy with server-rendered pages, but we might want to use this cool feature in the future and switch to SSG. If you'd like to learn more about this implemenation, here is very cool example shared by vercel: https://github.com/vercel/examples/tree/main/edge-functions/hostname-rewrites

## Mission completed

No more bugs and our app is live!

Do I regret time lost on configuring nginx and fighting with redirects? Not a bit! I’ve learned a lot about k8s, ingress, nginx, web requests, redirecting, proxing and wildcard domains. I wouldn’t have learned that much if we had jumped straight to server-side rendering. 

It seems that the **first solution is not always the best**. Sometimes we have to take a **step back** and consider other available solutions to move forward! Thanks for reading! Keep learning!

large_IMG_6618.jpeg

medium_IMG_6618.jpeg

small_IMG_6618.jpeg

thumbnail_IMG_6618.jpeg

IMG_6618.jpeg

The process and problems I encountered when creating a blogging platform with Next.js, Strapi CMS and Ingress configuration and why SSR proved to be the best solution in this case.

Wildcard domain and SSR to the rescue!

<aside style={{backgroundColor: "#f7f7f7", padding: "24px 32px", borderLeft: "16px solid #2a294e"}}>

### Read me!

Some time ago I've created a simple *[interactive demo](https://debounce-vs-throttle.vercel.app/)* which you can play with to see a difference between debouncing and throttling a function call. This project was a main reason for creating the blog post, so I highly encourage you to play with it before reading this article! Thanks and enjoy reading!

</aside>

## Introduction

If you are a software developer, you probably know that one of the most important things in developing a new product is performance. You are doing your best to make sure your app loads fast, each functionality is clear and simple to use and there are no bugs. You want the user to quickly and easily interact with it. It's clear that the fewer functions and request are called, the faster your app is.

In this article, I will shortly describe two techniques you might use to reduce the number of your function calls caused by a user interacting with your page. Using them might make you calling heavy calculation functions or API requests less often. Let's dive into **debounce** and **throttle**!

## Debounce

```ts
function debounce<T extends (...args: any[]) => any>(
  func: T,
  delay: number
) {
  let debouncedTimeoutId: ReturnType<typeof setTimeout>;

  return function (...args: Parameters<T>) {
    clearTimeout(debouncedTimeoutId);
    debouncedTimeoutId = setTimeout(func.bind(null, ...args), delay);
  };
}
```
[Gist link](https://gist.github.com/PatrykBuniX/cfbe02014469053d7a3680cead84604e)

Let your **user stop interacting** with the interface and then **call the function** - this is how I would describe debouncing a function in a single sentence.

A practical use case of debounce is waiting until the user stops typing in input. This way you are not disturbing the user in typing and for example not displaying results the user doesn't want to see (If he wanted to see it, he would stop typing). It will reduce a number of unnecessary, heavy calculations or API requests.

This is only one of many examples you can use debounce in - basically you will use it in event handlers that run frequently (keyboard and mouse events, window resizing, etc.).

Let's check what's happening in the code.

We declare a `debounce` function which takes two arguments:

- `func` - a function to debounce
- `delay` - time (in ms) after the function can be called

We declare a `debouncedTimeoutId` variable, with initial value of undefined, which is "closed" in debounce function (this way we are making sure it cannot be accessed from the outside - [more about closure](https://javascript.info/closure)). We will assign a value returned from `setTimeout` (id number) to it.

We return an anonymous function which will call our callback with the same arguments. Returned function clears the timeout with id of `debouncedTimeoutId` and sets another timeout storing its id in the same variable - this way our callback will run only if we stop calling debounced function for a given amount of time (`delay`). It won't be executed while we are spamming, because each time the event is fired, the timeout gets cleared.

You can use the function this way:

```ts
window.addEventListener('resize', debounce(() => console.log('debounced!'), 1000));
```

## Throttle

```ts
function throttle<T extends any[]>(
  func: (...args: T) => void,
  delay: number
) {
  let throttleTimeoutId: ReturnType<typeof setTimeout> | undefined;

  return function (...args: T) {
    if (throttleTimeoutId) return;

    throttleTimeoutId = setTimeout(() => {
      func(...args);
      throttleTimeoutId = undefined;
    }, delay);
  };
}

```
[Gist link](https://gist.github.com/PatrykBuniX/0f4d5fb348e4de620662d25cd727a82c)

Let's start with single sentence again: While the user is interacting with the interface, **call the function once in a given period of time**.

Throttle is about blocking a function from running for a specified time - some time has to elapse before it can be executed again. So, when the user is typing for a while, the function will run only if it's not blocked.

With throttle, you can listen for continuous events (like scrolling or window resizing) and run your function less frequently.

This one might seem a bit more complicated, so let's dive into the code again:

We declare a `throttle` function which takes two arguments:

- `func` - a function to throttle
- `delay` - time (in ms) after the function will be called

We declare a `throttleTimeoutId` variable.

We return a function which will call our callback with the same arguments. But before actually running a function, we are checking whether it's already waiting to be called. If it's waiting, do nothing and let it execute first before being called again. After given time (`delay`) run the function again.

Use it:

```ts
window.addEventListener('resize', throttle(() => console.log('throttled!'), 1000));
```

## Wrap it up!
I wanted to keep this article as short and simple as possible (I think that playing around with demo and reading implementation code is enough to understand these two techniques). Keep in mind that it's **my implementation** and you might find better code and explanation. I'm glad if it helped you understand/implement throttle or debounce. Thank you for reading this article, keep learning!

Play more with the demo: *https://debounce-vs-throttle.vercel.app*

large_Group 2.png

medium_Group 2.png

small_Group 2.png

thumbnail_Group 2.png

Group 2.png

Two techniques you might use to reduce the number of your function calls caused by a user interacting with your page. Using them might make you calling heavy calculation functions or API requests less often.

Debounce vs Throttle

Debounce vs Throttle in JavaScript

Patryk Górka

Patryk Górka

👋 About

Wildcard domain and SSR to the rescue!

Debounce vs Throttle in JavaScript