
## Analog Networks and Phone Calls (0G-1G)

The first cellular network (MTA, Mobiltelefonisystem A) was introduces in Sweden in 1956. In practice, the phones were so large that they were really only installed into cars but the cell towers still communicated wirelessly with these car phones. Although it was possible to move around within the range of the cell tower, the connection was lost if the phone needed to connect to a different tower. The network had approximately 125 users in Stockholm and Gothenburg.

The so called first generation cellular networks (1G) transferred sound as an analogue signal using a modulated carry wave. For example, if we wanted to send a simple 100 Hz wave, we could combine it with a considerably higher frequency 850 MHz carry wave. Combining the waves was done with amplitude modulation (AM) or frequency modulation (FM).

When using amplitude modulation, the amplitude of the carry wave is changed based on the transferred data. Frequency modulation is similar but we change the frequency of the carry wave instead.

<img src="/images/posts/how-cellular-networks-like-5g-4g-are-different/AM_FM.gif" alt="Animation of modulation types" />

Connecting phone calls with this technology required a specific frequency band which is defined by the lowest and highest used frequencies. If someone is on the phone on some frequency band, everyone else has to use a different band or the the signals could interfere with each other. The more frequencies a cell tower uses, the more people can make phone calls simultaneously. This is called bandwidth.

As the amount of users rose, the network was constantly put under a test. One option to fix the issue could be introducing more frequency bands to widen the bandwidth but this approach is problematic. All radio and TV stations, military systems, GPS and other systems utilizing electromagnetic waves need their own frequency bands which makes it extremely expensive for network providers to reserve new frequency bands for cell towers. Yet, network providers have used this approach at every stage of the development of the network

However, over the years, a lot of work has also been done to ensure that as much data as possible can be transmitted in each frequency band. The simples approach is to build more cell towers. Instead of using a single powerful tower to cover entire cities, multiple less powerful towers can be used. This makes it possible to use the same frequency bands for different users because the signal of these lower powered cell towers won’t reach far enough to interfere with each other.

This made it possible to increase the amount of users but the speed of data transfer still remained low. The best 1G networks were able to transmit data at the speed of 2,4 kbps.

## Digital Networks and Text Messaging (2G)

The 2G network was eventually developed and it took full advantage of the digital system and ushered in the actual era of mobile phones, replacing the era of car phones. If you’re my age or older, the 2G era is likely when you got your first mobile phone. My first phone was the magnificent Nokia 5110. It sure allowed me to make phone calls but it also came with a completely new way of communication, text messaging.

<img src="/images/posts/how-cellular-networks-like-5g-4g-are-different/nokia_5110.jpg" alt="Nokia 5110 mobile phone" />

When 2G was introduced, it was able to transmit data at the speed of 9.6 kbps and text messaging worked smoothly. Before 3G, the speed of 2G was already 200 kbps, thanks to a new technology called GPRS (General Packet Radio Switching) which is sometimes referred to as 2.5G.

## Wireless internet (3G)

The next generation of mobile networks, 3G, further utilized new frequency bands. It’s been estimated that European network providers spent more than 100 billion euros during this time period to reserve new frequencies for their networks.

Additionally, 3G made very efficient use of packet switching technology that GPRS had previously utilized. It allowed thousands of people use the same frequency bands more efficiently by splitting the data into small data packets that could be sent via different frequency bands as small chunks. Instead of having to wait for a frequency band to become completely vacant, it was now possible to send small chunks of data whenever a frequency band had any space on it. This made data transfer speeds much larger and allowed more concurrent users to use the network.

In 2005, yet another new technology, HSPA (High Speed Packet Access) was introduced. You may have seen H+ text on your phone, indicating that using this technology HSPA. This technology is sometimes called 3.5G and it already allowed a speed of 42 Mbps (42 000 kbps).

## High Definition Streaming (4G)

The next generation brought along yet another new technology, LTE (Long Term Evolution), which utilized new 700 MHz frequency bands that were previously used by analog TV broadcasts. In addition, a new technology, OFDM (Orthogonal Frequency Division Multiplexing), was introduced to transmit even more data in a single frequency range using some sort of black magic (math that goes way beyond my engineering degree).

When you really think about it, isn’t it absolutely amazing that we can stream HD videos with our phones without a single cable. Yet, the quality of these videos keeps getting better while simultaneously more and more devices from televisions to industrial robots are connected into the wireless internet. Even the current technologies don’t seem to be able to transmit enough data and network providers are forced to start using frequency bands nobody wants to use: high frequency millimeter waves.

## Internet of Things (5G)

Nobody has previously wanted to use high frequency millimeter waves on the cellphone networks because they are very poor at penetrating pretty much anything including things like rain. This is why network providers have to build and install a large number of new cell towers which seems scary to many consumers.

Adding more towers helps with congestion of frequency bands but 5G also utilizes a new technology called massive MIMO (multiple-input, multiple-output). It allows sending signals directly towards the receiver a bit like a light beam instead of sending it everywhere. 5G will allow us to reach speeds of up to 1000 Mbps (1 000 000 kbps).

5G will increase the speed of data transfer and minimize congestion on the networks. This is essential for new technologies like self driving cars and internet of things.

### Finally: 5G is not dangerous

At the extreme end of electromagnetic radiation is gamma radiation, which has a huge frequency. Larger frequency means more energy and gamma radiation is known for causing cancer. Even a bit lower frequency radiation can cause radiation if it’s ionizing meaning it has enough energy to rip electrons off of our cells.

However, the frequencies 5G utilizes are nowhere near ionizing. In fact, the frequencies are lower than the frequency of normal visible light. So, before you start worrying about 5G radiation, you should probably worry about ceiling lamps that are everywhere around us because they are emitting radiation with an even higher frequency than that of 5G networks!


What's the difference between different cellular networks like 4G and 5G?


Many things we've been taught at school are simplified to make them easier to understand. In reality, electrons don't orbit the nucleus like planets orbit the sun:

<picture>
  <source srcset="/images/posts/atoms-empty-space-why-things-look-feel-solid/atom.webp" type="image/webp"  />
  <source srcset="/images/posts/atoms-empty-space-why-things-look-feel-solid/atom.jpg" type="image/jpeg" />
  <img src="/images/posts/atoms-empty-space-why-things-look-feel-solid/atom.jpg" alt="Portrait" style="max-width: calc(100vw - 4em)" loading="lazy"/>
</picture>

It's better to think of electrons as a flock of insects where you can't distinguish a single insect but you can see the entire flock.

<picture>
  <source srcset="/images/posts/atoms-empty-space-why-things-look-feel-solid/electronCloud.webp" type="image/webp"  />
  <source srcset="/images/posts/atoms-empty-space-why-things-look-feel-solid/electronCloud.jpg" type="image/jpeg" />
  <img src="/images/posts/atoms-empty-space-why-things-look-feel-solid/electronCloud.jpg" alt="Portrait" style="max-width: calc(100vw - 4em)" loading="lazy" />
</picture>

The paths of different electrons vary. Some move faster and some slower. The path of each electron remains mostly the same but can sometimes change as long as no electron moves on the same path as an another one. According to [Pauli exclusion principle](https://en.wikipedia.org/wiki/Pauli_exclusion_principle), two or more identical fermions cannot occupy the same quantum state within a quantum system simultaneously or, simplified in layman's terms, electrons can't "move on the same path".

Even though electrons move indefinitely, they need energy to move to a higher energy path. Respectively, an electron releases energy when it moves to a lower energy path. For example, when an electron is hit with light, it might move to a higher energy path.

Now, if we shine light on a table, the light won't reach very far because the electrons "like" to take their part of the light's energy. This energy is almost instantly released and we see this as light reflecting from the table. This is why things look solid.

If you decide to touch the table with your hand, the electrons on your hand move very close to the electrons of the table. When the electrons of an atom move close to an another atom, the electrons' paths change. This is because the electrons can't move on the same path next to each other. Thus, the electrons of the atoms must move to a higher energy path. This requires energy which doesn't come from light but the force used to move the atoms closer.

Moving two atoms close to each other requires energy since the electrons need to "make space" by moving to higher energy paths. In the case of a hand and a table, there is a massive amount of atoms and pushing them close to each other requires enough energy to stop our hand. This is why things feel solid.


If atoms are mostly empty space, why do things look and feel solid?


We all know that the electricity in the regular outlets of our homes easily enough to be fatal. Yet, birds have no problem sitting on power lines that carry electricity at a 1000 times higher voltages. How is this possible?

Firstly, this is difficult topic to explain. Personally, I only really understood it two years into my electrical automation engineering studies, so if you don't have a solid understanding of how electricity works, try not to rush through this post and take your time instead. I'll do my best to explain everything in layman's terms.

Electric current describes the amount of electrons flowing through a point in space. If you compare electricity to a river, electric current is like the water current or, in other words, the speed of the flowing water.

When we want to move electrons, we need a path from high potential to low potential. This potential difference is called voltage. If we use the river analogy again, voltage is like the height difference between an upper and lower reach of the river. The higher the upper reach is compared to the lower reach, the more water flows. Similarly, a higher voltage, will cause a higher electric current.

Now, it's important to realize that high potential alone doesn't make electrons move. If there's a dam in a river, water won't flow no matter how high the water level is. Just like water in a river, electricity needs a path to flow through.

When a bird sits on a power line, its entire body is in the same, very high potential as the power line. However, since the bird doesn't touch anything else, the electricity doesn't have a path to a lower potential through the bird, so the bird is fine. If the bird were able to connect two separate lines, or a line and the ground, with its body, the electricity would flow through its body which would probably instantly vaporize.

That's why birds can safely sit on power lines. If I failed to explain this topic clear enough, don't hesitate to send me a follow up question on social media.


How can birds safely sit on power lines?


If you have a static Next.js website, you might think there's no way for you to create a notification system for new content since you don't have your own backend server. Luckily, this is not true. Creating an RSS feed for your content allows your users to use any of the free RSS subscription services to subscribe to your content and get notifications for each new post by email or even push notifications.

In this tutorial, I'm going to explain how you can set up your static Next.js website to automatically generate an RSS feed after each build.

## What we need to do

Here are the steps we need to take to generate an RSS feed with Next.js:

1. **Get all the data for the content.** Whether you store your content in a database, text files in your git repository or some other place, we need to have access to them with our post build script.
2. **Convert the content into XML.** Your content most likely is not stored as RSS-valid XML, so we need to process it.
3. **Write the RSS feed into an XML file.** After you have processed your content into XML, you need to write it into a file which will ship with your code.
4. **Make the script run after each build.** To do all the above steps automatically, we need to make our code run automatically whenever we build our website.

## Getting the data

Let's create a new file for the script. I decided to put my code to `<root>/utils/generateRss.js` when I added an RSS feed for this website.

The exact way to get your content depends on where you store it. Wherever your content is, the goal here is to get the title, URL, date and description for each item you plan to add into your RSS script. In my case, I write blog posts in markdown files in a `/posts` directory and here's how I get all the necessary data for my posts:

```javascript
const fs = require('fs');
const path = require('path');
const matter = require('gray-matter');

const getAllPosts = () => {
  // Read the posts directory and get blog posts' filenames
  const filenames = fs.readdirSync(path.join('posts'));

  // Go through all filenames
  const posts = filenames.map((filename) => {
    // Full path to the file from project root
    const filepath = path.join('posts', filename);
    // Read the content of the file
    const markdownWithMeta = fs.readFileSync(filepath, 'utf-8');
    // Get all data from the frontmatter
    const { data } = matter(markdownWithMeta);
    // Return everything we need for the RSS feed
    return {
      title: data.title,
      date: data.date,
      excerpt: data.excerpt,
      link: 'https://joonasjokinen.fi/blog/' + filename.replace('.md', ''),
    };
  });
  // Sort the blogposts by date
  return posts.sort((a, b) => new Date(b.date) - new Date(a.date));
};
```

Since your code will probably look a lot different, I won't be going through the above code in detail but I commented everything hoping it's easy to understand.

## Converting to XML

Once we've got the data, it's time to start processing it into XML for the RSS feed. I created a function which receives the blog posts as a parameter and maps each of them into an XML item.

```javascript
const getXmlItems = (blogPosts) => {
  return blogPosts
    .map((post) => {
      return `<item>
            <title>${post.title}</title>
            <link>${post.link}</link>
            <guid>${post.link}</guid>
            <pubDate>${new Date(post.date).toUTCString()}</pubDate>
            <description>${post.excerpt}</description>
            <dc:creator>Joonas Jokinen</dc:creator>
        </item>
        `;
    })
    .join(''); // Join the array of items into a single long string
};
```

The above code should be quite straightforward. We take the `blogPosts` array and map each post to a string containing an XML item about the post. If the XML syntax is completely new to you, the w3 schools [documentation](https://www.w3schools.com/xml/xml_rss.asp) is my favorite resource for understanding it. In short, here's a summary about the tags I used:

- **item:** A piece of content like a blog post, podcast episode or a video
- **title:** The title of the item.
- **link:** The URL leading to the item.
- **guid:** A unique identifier for the item. I used the URL for the post here but you can also use some other kind of identifier.
- **pubDate:** The publication date of the item. Should be in RFC 822 compliant format, which can be achieved with the `.toUTCString()` method of JavaScript dates.
- **description:** A phrase or sentence that describes the item.
- **dc:creator:** The author of the item. I hard coded my name here because I'm the only person writing for my blog.

We're now able to get the XML for all the pieces of content but we still need to write some "global" XML which describes the entire feed:

```javascript
const getRssXml = (xmlItems, latestPostDate) => {
  return `<?xml version="1.0" ?>
  <rss
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:content="http://purl.org/rss/1.0/modules/content/"
    xmlns:atom="http://www.w3.org/2005/Atom"
    version="2.0"
  >
    <channel>
        <title>Joonas Jokinen's blog</title>
        <link>https://joonasjokinen.fi</link>
        <description>The blog of an engineer with a childlike curiosity focusing mostly on web development and occasionally random interesting facts></description>
        <language>en</language>
        <lastBuildDate>${new Date(latestPostDate).toUTCString()}</lastBuildDate>
        ${xmlItems}
    </channel>
  </rss>`;
};
```

Here, I just hard coded most of the XML since I know it's unlikely to change any time soon. I got the `latestPostDate` by grabbing the `date` parameter of first element of `postData` (which is sorted by date).

I also placed the previously processed `xmlItems` after all the other tags.

The names of the XML tags here are also mostly self evident but here's a brief summary of what they mean:

- **title:** The title of the entire RSS feed
- **link:** The URL of the main page of the content
- **description:** A phrase or sentence that describes the feed.
- **language:** The language code, e.g. en, es, or fi
- **lastBuildDate** The last time there changes happened to the feed, e.g. a new blog post was published

## Writing the file

We've now made three functions that 1) Get all the data for each post 2) process the blog post data into XML items and 3) combine the items into a complete XML string. It's now time to call those functions and write the resulting XML into a file:

```javascript
const postData = getAllPosts();
const xmlItems = getXmlItems(postData);
const rssXml = getRssXml(xmlItems, postData[0].date);

fs.writeFile(path.join('public', 'rss.xml'), rssXml, (err) => {
  if (err) {
    console.log(err);
  } else {
    console.log('RSS feed written successfully');
  }
});
```

Here's I use the `fs` module to write a `rss.xml` file to `<root>/public/` which will then be shipped together with our app. It's time to test it. Let's add a post build script to our website's `package.json`:

```json
...
"postbuild": "node ./utils/generateRss.js",
...
```

Calling a script "postbuild" will make it automatically run after "build" has ran. So let's try it:

```bash
npm run build
```

It seemed to work since we got "RSS feed written succesfully" and a file called `rss.xml` appeared in `/public`. Now, to make sure the file is a valid RSS feed, we can copy and paste its contents to [W3 Schools Feed Validation Service](https://validator.w3.org/feed/#validate_by_input).

If everything worked as expected, the validator should congratulate you for having a valid RSS feed.

There you have it. Next time you publish your code, the RSS feed should now become accessible at `yourdomain.com/rss.xml`.


How to generate an RSS feed for static Next.js website?


If you have done any web development, you have probably used a ton of npm packages. In this tutorial, I will teach how you can create one of your own and publish it for other people to use. I will explain everything you need to do to publish your first package.

## Table of Contents

1. [Writing the Code](#writing-the-code)
2. [Handling Errors](#handling-errors)
3. [Local Testing](#local-testing)
4. [Preparing for publishing](#preparing-for-publishing)

## Writing the Code

There's no way for me to know what the package you're going to publish will do, so I won't be talking about what the code inside the package does. I will only be going through the requirements.

There are really two main types of npm packages; Those that allow users to import something they can use in their project and those that are used from the command line (or the script tag in `package.json`)

Make a directory for your project and run `npm init` to set it up for npm. The `main` parameter in `package.json` defines the entry point file in your app (`index.js` by default). This is where you will write your code. You can create other files too, of course, but all the code you plan to ship to the end users needs to be exported or executed in the entry point file. In a complex project, you can write all your code in other files and simply import them into the entry point file.

Let's look at a simplified example of how the entry point file could look like:

```javascript
const { someFunction, otherFunction } = require('./utils');

const defaultFunction = (params) => {
  const value = someFunction(params.someParam);
  return otherFunction(value);
};

const namedFunction1 = (params) => {
  // some code here
};

const namedFunction2 = (params) => {
  // some code here
};

const myModule = (module.exports = defaultFunction);
myModule.namedFunction1 = namedFunction1;
myModule.namedFunction2 = namedFunction2;
```

Now, the end user could import our functions like so:

```javascript
import defaultFunction from 'my-module';
import { namedFunction1, namedFunction2 } from 'my-module';
```

If we're making a package that should be used from the command line, we don't have to export anything:

```javascript
#!/usr/bin/env node

const { handleutilityFunction, someAsyncFunction } = require('./utils');

(async () => {
  const config = handleCMDArguments();
  const someValue = utilityFunction(config);
  const asyncResult = await someAsyncFunction(someValue);
})();
```

The first line in the example is very important. It's called a [shebang line](<https://en.wikipedia.org/wiki/Shebang_(Unix)>) and it tells Unix-like platforms that this file should be executed with node. Windows ignores this line and uses the filename extension instead.

If you find the use of parentheses in the example confusing, look into _immediately invoked functions in JavaScript_. They are not required for many CLI packages to work but it's a handy way to use async/await without having to write a named function only to immediately call it like so:

```javascript
#!/usr/bin/env node

const { handleutilityFunction, someAsyncFunction } = require('./utils');

const mainFunction = async () => {
  const config = handleCMDArguments();
  const someValue = utilityFunction(config);
  const asyncResult = await someAsyncFunction(someValue);
};
mainFunction();
```

Now, for our end user to be able to run our code from the command line, we need to add a "bin" parameter into our `package.json`.

```json
"bin": {
    "my-module": "index.js",
  },
```

This would allow the end user to run our index.js file from the command line like so:

```bash
myModule
```

Or by adding the following script in their `package.json`

```json
"scripts": {
    "some-command": "my-module"
  },
```

## Handling Errors

If you're going to put your code online for other people to use, you should aim to make it unbreakable and add descriptive error messages that help users understand what they are doing wrong. For example, if your function expects a certain parameter to be a `string`, check for it's type and handle situations when the user provides a non-string parameter:

```javascript
const getFirstAndLastCharacters = (str) => {
  if (typeof str !== 'string') {
    console.error(
      `[myModule]: myFunction expected a string but it got "${typeof str}"`
    );
    return;
  }
  const first = str.charAt(0);
  const last = str.charAt(str.length - 1);
  return { first, last };
};
```

It's a lot easier for the end user to understand what they did wrong if they get an error message like this:

```bash
[myModule]: myFunction expected a string but it got "number"
```

Instead of something like this:

```bash
TypeError: str.charAt is not a function
```

## Local Testing

To test how our package behaves as it's installed and used by a user, we can package our code locally using `npm pack` which will create a tarball in the root of your project directory. It should have a filename similar to `my-module-1.0.0.tgz`

Now we need to create a test project. The type of project you need for testing depends highly on the type of package you're creating, so I won't be going into a lot of detail. Whatever your test project may look like, you need to reference the tarball you just created in package.json:

```json
"dependencies": {
    "my-module": "../my-module/my-module-1.0.0.tgz"
  }
```

And then install it like a normal npm package:

```bash
npm install
```

If your package doesn't work as you expect, fix the error in your code, run `npm pack` again, and reinstall the package to your test project. You may need to delete the directory from node_modules:

```bash
rm -rf ./node_modules/my-module
```

Once you've tested your package and found that it works as expected and properly handles all possible user errors, it's time to prepare the package for publishing.

## Preparing for publishing

Every good project needs proper documentation, so be sure to write a good README file. You can take a look at some popular packages for reference. Usually a README file includes at least an introduction, installation and usage instructions, contributing instructions and a license. [Yes, you really should license your code!](https://choosealicense.com/no-permission/)

Next, you need to [create an npm account](https://www.npmjs.com/signup) if you don't have one already and login:

```bash
npm login
```

Follow the prompts and until you get a message similar to this:

```bash
Logged in as yourUsername on https://registry.npmjs.org/.
```

We're almost ready to publish but we still need to modify our `package.json` with some useful information. You can take a look at the [npm documentation](https://docs.npmjs.com/cli/v7/configuring-npm/package-json) for more fields but here are the most important ones I believe every package should have:

```json
{
  "name": "my-awesome-package",
  "version": "0.0.1",
  "description": "Does awesome things",
  "license": "MIT",
  "repository": "username/name-of-repository",
  "main": "index.js",
  "keywords": ["awesomeness", "otherkeyword"]
}
```

- name: The official name of your package.
- version: Version number. I like to keep it as 0.0.1 until I publish the first version.
- description: A short but informative description of your package.
- license: Abbreviation of your license. See npm documentation for more information.
- repository: The URL of your git repository, can also be provided as username/repository for GitHub repositories.
- main: The entry point file to your package
- keywords: A list of keywords that will help your package be discovered in npm search.

When you're ready to publish, run the following command to set the version number to `1.0.0`, the first major release of your package.

```bash
npm version major

Output: v1.0.0
```

You can then publish your package with the following command:

```bash
npm publish

Output: + my-awesome-package@1.0.0
```

That's it! Your package is now on the npm registry and it's available for anyone to use!


How to make and publish your own npm package?


While React apps are nice and snappy, their initial page load time is usually not good. This negatively impacts user experience, especially for users who use a slower internet connection. Slower page loading increases the chance of the user leaving your app. Website performance is also among the top factors search engines use to decide which websites they show in their search results.

In this tutorial, we will be using [compress-create-react-app](https://www.npmjs.com/package/compress-create-react-app) to significantly reduce the size of our website. This tutorial works for apps built with [create-react-app](https://reactjs.org/docs/create-a-new-react-app.html). The examples will use a Node/Express backend.

## Prerequisites

1. This is not a programming tutorial. I will only be focusing on the compression and **you need to know how to make the React app yourself.**
2. To use compression, you need to tell your server to serve the compressed files to the visitors. **If you can't access the server, you can't use compression.**

## What is Compression?

Compression algorithms condense make the website files a server sends to the client smaller. There are many different compression algorithms but they all work by finding repeating text within a document and replacing them with temporary strings with the same placeholder. The most efficient algorithm at the time of writing this tutorial is called **Brotli**. However, it is not supported by all browsers so we will be using an another algorithm called **gzip** as well as Brotli. We will then set up our server to send files compressed with Brotli when the client's browser supports it and gzip when Brotli is not supported.

## Using post-build compression

Due to the way create-react-apps work, the easiest way to set up compression is by using post-build compression which will automatically compress our build files after we build our app. Fortunately, an npm package called compress-create-react-app makes this easy.

Let's first install the package as a developer dependency:

```bash
npm install compress-create-react-app --save-dev
```

All we need to do to use the package is to modify our build script in `package.json`:

```diff
  "scripts": {
    "start": "react-scripts start",
-   "build": "react-scripts build",
+   "build": "react-scripts build && compress-cra",
    "test": "react-scripts test",
    "eject": "react-scripts eject"
  }
```

Now we can build our app just like we normally would:

```bash
npm run build
```

This will compress your build and create .br and .gz files into your build folder.

## Serving compressed files

The exact way our server needs to be set up to serve the compressed files depends on how you've configured your server. For Express servers, there's a nice package called [express-static-gzip](https://www.npmjs.com/package/express-static-gzip) which will do all the difficult parts for us.

Install the package

```bash
npm i express-static-gzip
```

Edit your main server file:

```javascript
const express = require('express');
const path = require('path');
const app = express();
const PORT = process.env.PORT || 5000;
const expressStaticGzip = require('express-static-gzip'); // Require the package

app.use(express.json({ extended: false }));

// Normal API paths
app.use('/api/example1', require('./routes/example1'));
app.use('/api/example2', require('./routes/example2'));

// Serve the build files
const buildPath = path.join(__dirname, '..', 'build');
app.use(
  '/',
  expressStaticGzip(buildPath, {
    enableBrotli: true, // Tell express-static-gzip to use brotli when the client supports it
    orderPreference: ['br', 'gz'],
  })
);

// Fallback to index.html when something that doesn't exist is requested
app.get('/*', (req, res) => {
  res.sendFile(path.join(__dirname, '..', 'build', 'index.html'), (err) => {
    if (err) {
      res.status(500).send(err);
    }
  });
});

app.listen(PORT, () => console.log(`Server started on port ${PORT}`));
```

That's it. Your app is now serving compressed files. Let me know if you have trouble making compression work for your app or if this tutorial helped you by contacting me through the social links on the bottom of the page.


Latest posts

What's the difference between different cellular networks like 4G and 5G?

Read more

If atoms are mostly empty space, why do things look and feel solid?

Read more

How can birds safely sit on power lines?

Read more

How to generate an RSS feed for static Next.js website?

Read more

How to make and publish your own npm package?

Read more