Kumar Abhirup Essays

> The cover image of this essay is from [Unsplash](https://images.unsplash.com/photo-1504540790158-a8126030896a?ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&ixlib=rb-1.2.1&auto=format&fit=crop&w=1700&q=80).

A lot of startups are "launched" every year.

**Startups run** (in the initial days) **only if founders want to run it.**

What keeps founders motivated?

What demotivates them?

What makes some founders quit early?

There are various reasons why some founders give up early, and some give up late, and some just don't give up.

---

# The Boulder Up the Hill Analogy

Running a Startup in the beginning could feel like you are pushing a boulder up the hill.

![Pushing Boulder Up The Hill](https://i.ibb.co/RNHXSrB/Pushing-Boulder-Up-The-Hill.jpg)
Image Credits: <https://medium.com/the-ascent/when-to-stop-pushing-and-start-living-acec3f20c1b>

Building a Startup initially gets you into a lot. Finding those first set of paying customers would seem like an uphill battle (for most of the startups). **It would feel like you are pushing this huge boulder up the hill.**

When Startups reach [Product Market Fit](https://review.firstround.com/how-superhuman-built-an-engine-to-find-product-market-fit), the boulder is at mountain's peak and then founders don't have to push the boulder up, but gotta chase it down. **Every Startup dreams this moment.**

Founders usually lack motivation while they are pushing up the boulder for too long with least incremental gains. Founders mostly quit in these circumstances. (Usually a good decision).

When founders reach PMF and are "chasing the boulder down the hill", this is the time founders are the busiest and will always have things to do. This is the PRIME time for founders to feel excited and are motivated to keep working on the startup.

---

# What keeps founders motivated?

I would boil it down to these four things.

- Core Belief in Idea
- Traction / Growth / Hype
- Money
- Being "Busy" with the Startup

# Core Belief in Idea

It’s easy to be motivated and enthusiastic when things are going well. The true test of a founder is how the founder reacts when things **aren’t going well.**

For example, you just lost your biggest customer. Or maybe your funding went wrong at the last possible moment. Or you are gaining NO traction since many months.

**If at such times you still remain motivated,** it probably means **that your belief in the startup**, its idea and its vision **is strong.**

However, Core Belief in Idea isn't always here to stay. Depending on the traction or other factors, it can erode with time. **Erosion of belief in the vision of the startup leads to founders quitting** and calling it a day.

Founders who learn to decouple their "trust in the original idea" from external factors (like money and traction) are usually motivated regardless the circumstances.

# Traction / Growth / Hype

If people know what you are building, are talking about it, are excited about it, **you have hype.**

If people actually use your product or are paying for it, **you have traction.**

Initially when you are planning out or building the idea, you wouldn't have any of that. But when you are building for years with no traction YET, you would lose some motivation. (Obviously lol)

When people are interested in what you are building and are looking forward to whatever it is that you are building, then you would feel an innate obligation to finish the project, run it and make it successful.

**Traction is one main factor why founders remain motivated.**

# Money

**If the startup is well funded by investors,** founders will usually compensate themselves. That compensation becomes an incentive for founders to stay motivated and work even during bad times, or during times when there is no traction or hype.

**If the startup isn't funded by investors,** and if founders have enough money already that they can live on, without having to do another job for a long time, it would prevent founders from quitting early. It's not a motivation, but definitely provides them relief in demotivating times.

If the startup is generating you enough money, you would be motivated enough to keep working on it, usually.

# Being "Busy" with the Startup

If you have a lot of things to do with your startup, **if you find yourself busy with the project, this usually means it's going well as it should.**

Customers are calling, Social Media is flooded with a lot of feedback, you got many calls booked, product design meetings, and what not. This happens when you are on the other side of the mountain chasing down the boulder. **This "busyness" keeps founders motivated.**

**Failing startups seem to have one thing in common for founders, there's not much left to do**, or it doesn't seem like there's anything meaningful left. That demotivates founders, eventually leading them to quit.

---

# Hmm, so?

**If you are a founder and if you have marked all the above listed things as safe**, you would probably never quit. **Those four things** or **some of those four things** would always **keep you motivated**.

**If you have none of them, you'd definitely quit**, AND IT WOULD MAKE SENSE IF YOU DO SO.

## When to quit?

Ask yourself this question. If you could somehow go back in time and build your startup again, would you choose the same idea? If yes, don't quit. Else, think of quitting maybe?

What keeps Founders Motivated

> The featured image of this article is from [Unsplash](https://images.unsplash.com/photo-1517697063925-d82f8da41135?ixid=MXwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHw%3D&ixlib=rb-1.2.1&auto=format&fit=crop&w=2378&q=80).

This won't be a long tutorial, but a small, very self explanatory code snippet, that you can easily read and learn by yourself.

![Rate Limit your Express API Endpoints](https://i.ibb.co/b10C3rz/rate-limit-your-endpoints.png)

# 🚶‍♂️ Quick Walkthrough

### Step 1

Install `express`, `express-limiter` and also install Redis to [set up a Redis Client](https://docs.redislabs.com/latest/rs/references/client_references/client_ioredis/). Redis Client will be created using `ioredis`.

Why do you need Redis? Here's why 👇

<blockquote class="twitter-tweet">✅ What is 𝑹edis? I started using it many months ago, when implementing PubSub, but it is used for many more things. It... 👇 - is an In-memory data structure store - is Used as a database, or cache store - Provides simple data structures such as strings &amp; arrays&mdash; Kumar Abhirup (@kumar_abhirup) <a href="https://twitter.com/kumar_abhirup/status/1350010149725868032?ref_src=twsrc%5Etfw">January 15, 2021</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

 

### Step 2

Import express and create an express app instance. Now, create a limiter instance. We will use `express-limiter` for this.

```js
const limiter = expressLimiter(app, redisClient)
```

Make sure you spawned a Redis Client, [read how to do that here](https://docs.redislabs.com/latest/rs/references/client_references/client_ioredis/).

This limiter instance will now help us create a `limiterForApi` to define Rate Limit rules to use it for your routes as a middleware.

### Step 3

Define the rules. Create the middleware.

```js
const limiterForApi = limiter({
 onRateLimited(_req, res) {
 return res.status(429).send({ error: { message: "Rate limit exceeded" } })
 },

 total: 200,
 expire: 1000 * 60 * 60,
 lookup: ["headers.data.user._id"]
})
```

The above middleware sets the API rate limit at 200 requests per hour per User ID. If you want to rate limit per IP Address, you can add the IP Address header name in the `lookup` array.

### Step 4

Use the middleware!

## Here's the complete code snippet

If you read the code comments, you will get a fair idea of how things work!

![Rate Limit your Express API Endpoints](https://i.ibb.co/b10C3rz/rate-limit-your-endpoints.png)

For more details and complexities, take a look at the [`express-limiter` documentation](http://npmjs.com/package/express-limiter). It's very neat.

How to Rate Limit your Express API Endpoints

> The thumbnail of this article is from [Google reCAPTCHA's official landing page](https://www.google.com/recaptcha/intro/v3.html).

In this tutorial, we will learn how to use reCAPTCHA v2 with React and Node.

Most of the tutorials online only cover the frontend part of this technology. The truth is, **your captcha solution can only be useful, if it validates the input on backend.**

Let's begin with how you can show the captcha checkbox on React Frontend by first setting up the Google reCAPTCHA console.

# Setup Google reCAPTCHA Admin

- Go to [this URL](https://www.google.com/recaptcha/admin/create) to create a reCAPTCHA app.

- Give the reCAPTCHA a label.

- Select `reCAPTCHA v2`.

- Add the domain name of where this captcha checkbox will be used. To test this checkbox on your development server, add `localhost` as your domain name.

- Click Submit.

Now that you have created the app, you can get your reCAPTCHA keys.

> Note that these keys are extremely important. The `SITE KEY` can be used in the client, but the `SECRET KEY` should be never used in the client. It should only be used in the backend.

![Get your Google reCAPTCHA Credentials](https://i.ibb.co/7WFsKWr/Site-Key-Secret-Key-Google-re-CAPTCHA-Screenshot.jpg)

---

# Setup React Frontend

Install the `react-google-recaptcha` React Component. It will simplify this terrific process.

```bash
yarn add react-google-recaptcha
```

After you install the component, here's how you can display the reCAPTCHA checkbox on the frontend.

```jsx
import ReCAPTCHA from "react-google-recaptcha"

function onChange(value) {
 console.log("Captcha value:", value)
}

export default function App() {
 return <ReCAPTCHA sitekey="YOUR_CLIENT_SITE_KEY" onChange={onChange} />
}
```

Make sure you replace `YOUR_CLIENT_SITE_KEY` with the real client site key that you got from the Google reCAPTCHA Console.

With the correct usage of the above code, you should see something like this in the browser.

![Google reCAPTCHA GIF](https://www.cmnty.com/support/wp-content/uploads/2017/07/nocaptcha.gif)

Now, if you check your console, you will see the `Captcha value: some_value` logged on the console. That same value, will be sent to the backend to verify if the user is really not a robot.

---

# Backend Verification

To verify the value that the backend gets, after the user checks the box, you will have to make a POST request to Google reCAPTCHA API.

```bash
POST https://www.google.com/recaptcha/api/siteverify
```

Here's how you do it in Node.js 👇

```js
// Install 'es6-promise' and 'isomorphic-fetch' from NPM or Yarn.
require("es6-promise").polyfill()
require("isomorphic-fetch")

const RECAPTCHA_SERVER_KEY = process.env.RECAPTCHA_SERVER_KEY

const humanKey = "value_that_we_got_from_the_frontend"

// Validate Human
const isHuman = await fetch(`https://www.google.com/recaptcha/api/siteverify`, {
 method: "post",
 headers: {
 Accept: "application/json",
 "Content-Type": "application/x-www-form-urlencoded; charset=utf-8"
 },
 body: `secret=${RECAPTCHA_SERVER_KEY}&response=${humanKey}`
})
 .then(res => res.json())
 .then(json => json.success)
 .catch(err => {
 throw new Error(`Error in Google Siteverify API. ${err.message}`)
 })

if (humanKey === null || !isHuman) {
 throw new Error(`YOU ARE NOT A HUMAN.`)
}

// The code below will run only after the reCAPTCHA is succesfully validated.
console.log("SUCCESS!")
```

> **Note:** This article does not tell you how to communicate between frontend and backend, this article only tells you what logic to use in backend, to verify the reCAPTCHA string value you get from the frontend.

To understand the above code, we first need to understand what `fetch()` function results.

```js
await fetch(`https://www.google.com/recaptcha/api/siteverify`, {
 method: "post",
 headers: {
 Accept: "application/json",
 "Content-Type": "application/x-www-form-urlencoded; charset=utf-8"
 },
 body: `secret=${RECAPTCHA_SERVER_KEY}&response=${humanKey}`
})
```

The above snippet makes a POST request to the Google reCAPTCHA API route to get a response (to know if the humanKey we got from the frontend is correct or not).

We also supply `RECAPTCHA_SERVER_KEY` and the `humanKey` in the request body. Remember that the `RECAPTCHA_SERVER_KEY` should be kept secret. Do not push it in GitHub Open Source. [Use Environment Variables](https://www.freecodecamp.org/news/heres-how-you-can-actually-use-node-environment-variables-8fdf98f53a0a/#:~:text=env%20files%20allow%20you%20to,in%20there%20on%20different%20lines.&text=To%20read%20these%20values%2C%20there,the%20dotenv%20package%20from%20npm.).

Here's a Sample Response that the API gives us.

```json
{
 "success": true,
 "challenge_ts": "ISODateString", // timestamp of the challenge load (ISO format yyyy-MM-dd'T'HH:mm:ssZZ)
 "hostname": "string" // the hostname of the site where the reCAPTCHA was solved
}
```

The `success: true` is enough for us to understand that the user is not a robot. If `success: false`, then the `humanKey` we got was probably a wrong one or the user tried to hack in.

---

# Aftermath

Once you get `success: true`, you would probably want to send your frontend a response that the reCAPTCHA was not botched and the user was not a robot.

You must be using some kind of an Express/Koa API Route, or a GraphQL backend where you can get API requests from the frontend to give it some response.

If you want to see it in practise, I have hosted my code here 🔥

- [Frontend reCAPTCHA](https://github.com/KumarAbhirup/kumarabhirup/blob/0f883462652afc521d4938e1f06f0128f233e29f/src/components/mobirise/Contact.js#L270)
- [Backend reCAPTCHA Validation](https://github.com/KumarAbhirup/kumarabhirup-backend/blob/d0b9daa97e724c428ebdf3728f475d35ee7370de/src/resolvers/Mutation.js#L44)

I hope this tutorial gave you decent information on how you can validate your reCAPTCHA input on backend using Node.js and React.

Peace ✌️

Implementing Google reCAPTCHA with React and Node.js

Many developers use command-line apps on a daily basis.

From git to yarn, we use many CLI (Command Line Interface) apps. Not everyone likes CLI over GUI, but many geeks love using CLIs.

Today, we will learn how to create Command-Line Apps in Node.js

Command-Line apps can be written in many languages. If you write them in Node.js, you can serve your app to the NPM/Yarn users.

# Assumptions

- You know how to install NPM packages.
- You know the basics of Node.js
- You know basic terminal commands like `cd`, `pwd`, `ll`, `ls`.

# Get Started

- `cd` to the repository where you store all your code.

- Do the following...

```bash
mkdir demo-cli && cd demo-cli
touch index.js
npm init -y
```

- Open the `demo-cli` folder in your favorite code editor.

## index.js

CLI apps are all about input and output. In this Starter Guide, we won't go deep into creating a CLI that does something important.

For now, we will only make use of `chalk` and `figlet` to do make some creative output.

Run the following command to install needed packages...

```bash
npm i chalk figlet clear -s
```

And then, just paste the following snippet in your `index.js`.

```js
#!/usr/bin/env node

const clear = require("clear")
const chalk = require("chalk")
const figlet = require("figlet")

clear()

console.log(
 chalk.yellow.bold(
 figlet.textSync("CLI!", {
 horizontalLayout: "full"
 })
 )
)
```

The `#!/usr/bin/env node` line needs to be at the top for a Command Line App to work.

## package.json

Add a Start Script in your `package.json`...

```json
{
 "scripts": {
 "start": "node index.js"
 }
}
```

Also, add a `bin` script. That script decides what command will user need to type to see the output.

```json
{
 "bin": {
 "thisDemoCli": "index.js"
 }
}
```

# See the output

Run `npm start` to see how the output looks like. Isn't it just like running a Node app?

Okay, now, do this...

```bash
pwd # Copy the output you get
npm i -g <PASTE_THE_OUTPUT_OF_PREV_COMMAND>
```

**And now try running `thisDemoCli` in the terminal, and you should see the same output!**

Output...

```
 / ___| | | |_ _| | |
 | | | | | | | |
 | |___ | |___ | | |_|
 \____| |_____| |___| (_)
```

# Publish to NPM

To publish to NPM so that you can serve your apps to users, give your package a unique name, and provide it a version.

And then run...

```bash
npm publish
```

**That is it!**

# 🦄 More info

This tutorial only helps you create a naive command-line app. Real command-line apps have a lot going on. Like [the one I created](https://github.com/KumarAbhirup/bulk-mail-cli).

Make use of the `commander` NPM module to make the CLI do different tasks on different flags like `--help`, `--version`, etc.

Here's the [Part Two of the Series - Creating a command-line app in Node.js: Argument Parsing](https://dev.to/kumar_abhirup/a-starter-guide-to-creating-a-command-line-app-in-node-js-part-2-3ln3).

A starter guide to create a command-line app in Node.js


There are many magic scripts available for use by the Node Package Manager ecosystem, that beginners yet don't use.

When I wanted to publish a package, I would manually bump the version, build the project, and then run `npm publish` to ship the package. Which by itself took a lot of time.

But then, I read [this documentation](https://docs.npmjs.com/misc/scripts) by npm and realized that all the processes can be automated and can be done in just one command.

The documentation has a lot going on, so in this DEV post, I'll try to
demystify the 5 most important package.json scripts using the documentation as a reference.

# Let us begin

## 1. prepublish

```json
"scripts": {
  "prepublish": "minify or build your code here",
}
```

_This command is run BEFORE the package is packed and published. This command also runs when user runs `npm i` locally without any parameters and arguments._

**From the NPM Docs:**

> If you need to perform operations on your package before it is used, in a way that is not dependent on the operating system or architecture of the target system, use a prepublish script.

Prepublish script includes tasks such as:

- Compiling CoffeeScript source code into JavaScript.
- Creating minified versions of JavaScript source code.
- Fetching remote resources that your package will use.

The advantage of doing these things at prepublish time is that they can be done once, in a single place, thus reducing complexity and variability.

Additionally, this means that:

- You can depend on `coffee-script` as a `devDependency`, and thus your users don’t need to have it installed.
- You don’t need to include minifiers in your package, reducing the size for your users.
- You don’t need to rely on your users having `curl` or `wget` or other system tools on the target machines.

## 2. prepare

There is a little difference between `prepare` and `prepublish`...

_`prepare` script runs when `git` dependencies are being installed. This script runs after `prepublish` and before `prepublishOnly`._

Example 👇

```json
"scripts": {
   "build": "rollup -c",
   "prepare": "npm run build"
}
```

Building the project could be the best thing you can execute in the `prepare` script.

## 3. prepublishOnly

This command serves the same purpose as `prepublish` and `prepare` but runs only on `npm publish`! 🔥

## 4. postpublish

As the name suggests, the command runs after `npm publish`...

## 5. Custom `pre`ing and `post`ing of scripts

Take a look at the below scripts.

```
"scripts": {
  "predeploy": "cd example && npm install && npm run build",
  "deploy": "gh-pages -d example/build"
}
```

To execute `deploy` completely, you don't need to `npm run predeploy && npm run deploy`, just running `npm run deploy` will do the `pre` and `post` task.

You can add the `pre` and `post` prefixes to any script and have it run chronologically.

# And there's much more

- preinstall
- postinstall
- preuninstall
- postuninstall
- preversion
- postversion
- prestart
- poststart

The names are pretty self-explanatory.

To read more about these, you can refer the [NPM Docs](https://docs.npmjs.com/misc/scripts) about `npm-scripts`.

# Conclusion

The NPM Magic Scripts can prove useful to anyone and everyone. I regret not using it for my past projects. 😅


5 package.json magic scripts that you don't use!


🔥 Learn async/await (very basics) here 👇

When you learn async/await in JavaScript, you quickly fall into words like

- Synchronous & Asynchronous code
- Event Loops
- Promises

These things aren't easy to understand in one go.
**Complex theories gatekeep beginners.**
So, we will only learn about practical stuff.

---

Let us first learn about "Promises"

In the below snippet, what we are intending is to
output `Done First`
and then output `Done Last`.

But the below snippet outputs "Done Last" first.

That is now JavaScript behaves. It does not wait by default.

![Code Snippet](https://i.ibb.co/d0Nc65D/1.png)

---

To make JavaScript wait for a second

to output `Done First`

and then print `Done Last`...

We use `Promise` constructor.

It accepts a function as the only argument.

The function receives few params. 2 of them being `resolve` and `reject`.

![Code Snippet](https://i.ibb.co/4p2VXw9/2.png)

`resolve` accepts arguments.

These arguments later become the params in the .then() function.

So, the .then() function runs only after the promise is resolved.

Well, don't create a Promise just for a "console.log after setTimeout".

**This was just for explanation.** 🙂

---

Now, here's the async/await part.

```js
promise.then(() => console.log("Done Last."))
```

can also be written as

```js
await promise
console.log("Done Last.")
```

Just like in the below snippet. It just works!

Await tells JavaScript, "Wait until this is finished, then move to the next line".

Wondering what's the `async` part in the below snippet?

![Code Snippet](https://i.ibb.co/zs8X16s/3.png)

---

The await keyword only happens to work inside an async function.

An async function tells the compiler ahead of time that the function will be returning a Promise and will not have a value resolved right away.

![Code Snippet](https://i.ibb.co/8D39DNp/4.png)

---

# Links

- [Mozilla Promise Documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise)
- [What is a Promise?](https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-promise-27fc71e77261)

I hope that gives a basic idea about what async/await is and what it does. :)


async/await Crash Course

Hey all! 🙌

I am very thrilled to announce the side-project I have been working on since last week...

I named it **[pkgreview.dev](https://pkgreview.dev)**! The complete product was born out of one tweet.

<center><blockquote class="twitter-tweet">🔥⚡ Question Time ⚡🔥 Is there a Star Rating/Review website for <a href="https://twitter.com/hashtag/NPM?src=hash&amp;ref_src=twsrc%5Etfw">#NPM</a> packages... where people could look at reviews before using a library? Is it a good idea to build such a website? ⏳⌛⏳⌛⏳⌛⏳&mdash; Kumar Abhirup (@kumar_abhirup) <a href="https://twitter.com/kumar_abhirup/status/1218860389833723905?ref_src=twsrc%5Etfw">January 19, 2020</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></center>

---

# 🎊 pkgreview.dev

A lot of people find it very difficult to decide what NPM Package to use.

There comes pkgreview.dev to your rescue!

📦 0.3 Million NPM Packages with GitHub Stats listed!

🎉 Helps analyze NPM Packages

🚨 Write & Read Reviews

⭐️ Star Ratings like _rottentomatoes_!

![React @ pkgreview.dev](https://ph-files.imgix.net/7dc59a54-0d54-4804-8c9d-301482cafb0a?auto=format&auto=compress&codec=mozjpeg&cs=strip&w=582.330383480826&h=380&fit=max&dpr=2)

---

# 🕹 The idea

A lot of people find it very difficult to decide what NPM Package, React Component, Module or Library to use.

**They end up checking on GitHub** to see how active the community is. GitHub does not tell you a clear picture. It is just a part of the picture.

**What people often miss**, is the first-hand experience of the users who have used the library.

`pkgreview.dev` displays all sorts of important metadata of a package (_reviews, ratings, last updated, stargazers, etc._) and also shows `other developers' opinion` about them.

And you can **contribute by posting your review** about the NPM Package. 🎉

# 🔥 Building a Community

The app that you are currently seeing is in its MVP phase.

**To be useful to the masses, we need more reviews.** You, as a developer, can contribute a lot in this process by just posting a review to any useful package.

This project needs the support of the **JavaScript Community**.

**[Login with GitHub (takes two seconds) and write your first review!](https://pkgreview.dev/npm/react)**

---

**This is my first fast-shipped side project. Please do give me feedback on it! 🙌** This is just a start.

# In my Todolist

- Add support for other package managers like PHP Composer, Docker Hub for Images, PIP for Python, and much more!

- Give maintainers of the package special permissions like replying to the review or reporting it.

- Use AI for creating reviews by reading about the package on the web (eg. GitHub issues, Blogposts, etc.)

- Make UI better and less gimmicky.

---

I will be able to achieve the goals in the todo list only by your support.

I love positive as well as critical feedback 🙌

pkgreview.dev - The Ratings and Review Website for NPM Packages 🎉

React developers use similar component code day in and day out. But not all of them streamline the React Component building and publishing workflow.
Before we discuss the building and publishing workflow, here's why we need to have it.

# Before we discuss the building and publishing workflow, here's why we need to have it

- **Reason 1:** Most of our React code is reusable and there's a high chance that we need the same React Component in another project.
- **Reason 2:** To keep a code uniformity among all of our React Projects.
- **Reason 3:** An opportunity to contribute to the open-source. We can publish the component, and have others use it as well!

You know how NPM packages are built. Yet, when it comes to publishing the React Component we use in a project, we hesitate.

# Reasons why you hesitate

- Building a new React Component that is publishable on NPM takes a lot of efforts.
- You feel it is not worthy to waste time installing and updating the published package in your project.
- You want your component in your components folder, and when component code is changed, you want your project to "live reload".

# When I was a novice, I used to publish a React Component like this…

I used to create a new Git Repository.

Then setup all the babel and webpack stuff.

Then I would write the React Component code.

Then I would compile it manually and publish it to npm using `npm publish`.

To test the React Component, I would manually install the component in my project directory using `npm i -S that-react-component`. That had no "Live Reload"…

I had to update the package in the Component Repository and Update the module back in my project.

> How shitty that procedure was. I knew it was shitty. So, I stopped open sourcing React Components. I let them lie in my Project Directories. If I would need a component, I copy-pasted the component files to another project. And that went on. Until I learned about…

`create-react-library` and `npm link`!

I was just strolling through the GitHub search box typing weird stuff, and then I found `create-react-library`.

![React Workflow](https://cdn-images-1.medium.com/max/2560/1*tt-8-gpw-xLZu0heaMZ57g.png)

# Here's the much better way of doing it

## Step 1

So, every time you know you are building a component for the ongoing project, think…

- If you might need the component for other projects.
- If the component can be useful for other devs out there.
- If your component logic and use-case is not very project-specific.
- Or for the sanity sake, you want your project files to be less cluttered.

**If you see any of those reasons valid, you should consider building the component as a reusable component that is packaged as a module.**

If yes, then move to Step 2.

## Step 2

Visit the master folder where you store all your projects via terminal and run the following 👇

```bash
npx create-react-library <COMPONENT_NAME> # then answer few basic prompts
cd <COMPONENT_NAME> # enter in that directory
```

**And voila! You got your React Component Boilerplate Code setup.**

## Step 3

Do the following in the terminal 👇

```bash
npm i # this will install your component modules
cd example && npm i # install CRA modules
npm start
```

Running above commands will install the modules that your React Component and Create React App Example will need.

## Step 4

Let us browse the file structure of the project.

```
project
│ README.md
│ package.json
| ...
│
└───example
│ │ package.json
│ │ ...
│
└───src
 │ package.json
 │ ...
```

Now, anytime you make a change to your library in `src/` or to the example app's `example/src`, `create-react-app` will live-reload your local dev server so you can iterate on your component in real-time!

## Step 5

Well, what if **you want the component to work live with your ongoing project** without having to update and publish on npm?

Here, `npm link` comes for the rescue!

In your the root of your component directory, run `$ npm link`. That makes your component available globally to all projects!

## Step 6

Now via terminal, reach the ongoing project directory, and run
`$ npm link <COMPONENT_NAME>`.

That is it. You have connected both the worlds!

**Let both of your component directory and ongoing project watch and compile the code live.**

## Step 7

It's time to use the component in your project!
You can import and use the component in a normal way.

```javascript
import ThatAwesomeComponent from "<COMPONENT_NAME>"
```

Now when you update your component code and refresh your project in the browser, you'll see things come alive!

**Go! Try that yourself!**

---

# Publishing your React Component

Now that you want to publish/deploy/ship your React Component…

- **Make sure you have good documentation supporting your code.**
- Also, check your version number. If you feel it's all right and working, it's time to publish!

```bash
npm publish
```

That is it. Your files will be built and published on NPM Registry!

**If you want your build to be less bloated, publish the component with the following `.npmignore` file.**

```bash
# it is also configured for TypeScript Components
src
example
.vscode
.eslintrc
.prettierrc
package-lock.json
tsconfig.json
tsconfig.test.json
.gitignore
node_modules
.travis.yml
rollup.config.js
```

## You forgot one thing

Do not forget to `npm unlink` the component from your ongoing project directory so that you can use the "real" and "published" component. When do develop the component, you may link it again.

To unlink, do `$ npm unlink <COMPONENT_NAME>` from the project directory.

---

# Links

- [create-react-library](https://github.com/transitive-bullshit/create-react-library)
- [how-to-use-npm-link](https://codurance.com/2016/12/21/how-to-use-npm-link)

# Conclusion

React components can be more awesome if built and published the right way.

This is how you should build and publish a Modern React Component!


This week while starting to build a huge SaaS product, I had to make many decisions. The biggest decision I made was to build that SaaS product with the Microservices architecture.

Thankfully, [Lucas Chen](https://dev.to/bettercodingacademy) had [this amazing series](https://dev.to/bettercodingacademy/i-m-a-professional-react-developer-and-here-s-how-i-set-up-react-node-js-microservices-using-docker-and-graphql-20gk) that explained the React + GraphQL + Docker Microservices architecture. In his series, the backends were microservices but React was not hosted on Docker. I wanted it all on Docker, so I had to research a lot, about integrating React (especially Next.js) with Docker.

After a few days of research and setting up a Containerized Next.js App, I am here to share with you how to do it.

Hope you like it :)

---

# 🦋 Getting Started

Setting up a Next.js shouldn't be hard.

```bash
yarn create next-app
```

**Wait! We are not doing it all from scratch.**

Instead, I would recommend you to clone [this repo](https://github.com/KumarAbhirup/dockerized). We will learn about containerized Next.js from there. In this way, you will be able to compare your progress to that repository so that you can ensure you don't get lost in a long tutorial.

[Click here](https://github.com/KumarAbhirup/dockerized) to access the GitHub repository.

The above repository includes...

- A setup that is scalable. You may append your dockerized backends to it later.
- ESLint + Prettier setup included.
- It's TypeScript. :)

# 🔰 Things you need

- Docker Installed on your machine
- Some basic knowledge of Next.js

# 🚀 Clone and Setup the repository

- Run the below command

```bash
git clone https://github.com/KumarAbhirup/dockerized dockerized

cd dockerized
```

- Rename all the `.env.example` to `.env`. You'll find it in `packages/landingpage`

- Create a `.env` file in the root of the directory.

As you cloned the project, the Next.js App is ready to run.

Just run the below command to fire up the development environment for the Next.js project.

```bash
docker-compose up
```

---

# 👁 But Kumar, how does this thing even work

You might be wondering where your Next.js project is staying.

It is in the `packages/landingpage`...

![Next.js Project Folder Structure](https://i.ibb.co/yqX1wSC/Screenshot-2020-03-27-at-5-18-48-PM.jpg)

You might be wondering why that Next.js project is kept deep inside the file system.

I did it because no one dockerizes Next.js when they are only using Next.js...

Dockerizing makes sense when you have a huge container architecture that connects your React frontends to the Containerized backends.

So, the repository would not just contain a Next.js project but would have backends kept in the same `packages` folder.

---

# 📦 How to containerize Next.js

To use Docker to containerize any code, we need to have a `Dockerfile` in the package. Every container has its own `Dockerfile`.

Next.js too, will have its own Dockerfile. Let us take a look at it.

[**`packages/landingpage/Dockerfile`**](https://github.com/KumarAbhirup/dockerized/blob/master/packages/landingpage/Dockerfile)

```docker
FROM node:12

ENV PORT 3000

# Create app directory
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

# Installing dependencies
COPY package*.json /usr/src/app/
RUN npm install

# Copying source files
COPY . /usr/src/app

# Building app
RUN npm run build
EXPOSE 3000

# Running the app
CMD "npm" "run" "dev"
```

Let me explain what's happening here. Here, by `FROM node:12`, we are telling Docker to work with the Node.js image.

`ENV PORT 3000` just exposes the environment variable `PORT=3000`.

The below code snippet tells docker to create directories, namely `/usr/src/app`. We also tell Docker to use that directory as its primary workspace (for carrying out processes) hereafter.

```
RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app
```

The below code snippet copies `package.json` and `package-lock.json` from your local cloned repository to the Docker Container and then runs `npm install` on it. I recommend you to take a look at [**`package.json`**](https://github.com/KumarAbhirup/dockerized/blob/master/packages/landingpage/package.json) of the Next.js container so you get the idea.

```
COPY package*.json /usr/src/app/
RUN npm install
```

Now that we have all the `node_modules` ready, below code will copy our code from our local computer directory and will put it into the Docker Container Directory.

```
# Copying source files
COPY . /usr/src/app
```

Then the `Dockerfile` builds the Next.js app, exposes port 3000 (where Next.js works by default), and runs the command `npm run dev`.

```
# Building app
RUN npm run build
EXPOSE 3000

# Running the app
CMD "npm" "run" "dev"
```

I hope you understood all that is happening due to the Dockerfile.

---

> Now, we have successfully containerized the application with Next.js! But we are not yet done.

For hot-reloading to work with Next.js and Docker, you need to have the below code snippet added to the `packages/landingpage/next.config.js`.

```javascript
module.exports = {
  webpackDevMiddleware: config => {
    config.watchOptions = {
      poll: 1000,
      aggregateTimeout: 300
    }

    return config
  }
}
```

---

We are still not done!

To run all our containers (in this case only one) together successfully, we will need a `docker-compose.yml` file in the root of the project.

Check out the [**`docker-compose.yml`**](https://github.com/KumarAbhirup/dockerized/blob/master/docker-compose.yml) in your folder structure.

```docker
version: "3.3"

services:
  nextjs:
    ports:
      - 3000:3000
    build:
      context: packages/landingpage
      dockerfile: Dockerfile
    volumes:
      - ./packages/landingpage:/usr/src/app
      - /usr/src/app/node_modules
      - /usr/src/app/.next
    env_file:
      - .env
```

The above code snippet makes sure that port 3000 is exposed. The `docker-compose.yml` file also tells Docker what services to build and which `Dockerfile` to use.

The `env_file` tells the composer to use a `.env` file which if you have not yet made in your project, please add it for it to work.

The `volumes` part is very important here. Without it, your Next.js will work, but the \_Hot Reloading Developmental Feature` would not work.

---

# 🔥 Hurray

If you surf through the repository carefully, you will understand how to containerize Next.js with Docker.

**We are done!**

To run the Dockerized Next.js app...

Run **`docker-compose up`** and open `http://localhost:3000` in your browser.

To make changes in code, make changes to `packages/landingpage/pages/index.tsx` file to see your website development experience come alive.

---

# 🚀 For production

When deploying to production, just make sure that you make a small change in your `packages/landingpage/Dockerfile`.

Change the last line (`CMD "npm" "run" "dev"`) to **`CMD "npm" "start"`**.

---

# 💚 Links

- [Source Code](https://github.com/KumarAbhirup/dockerized/)
- [Docker + Next.js Tutorial](https://www.codemochi.com/blog/2019-08-27-nextjs-hmr/)


Next.js + Docker. Made easy.


My old portfolio website looked like this 👇

![Kumar's Old Website](https://camo.githubusercontent.com/8754a779546e3c97109c4d15b0c2ca0fcf42a537/68747470733a2f2f692e6962622e636f2f6d53536b64674b2f4b756d61722d416268697275702e6a7067)

Yea, I see it looks nice and cool, but I had to change it all.

That website was bloated with a combination of jQuery and React 😂 Can you believe it?

Also, it didn't have a blog. I tried adding it there, but it was a failed attempt.

I faced weird bugs like background image not loading and stuff.

> **Confession:** The previous website's code was created using mbrise page builder. I just took the code and React-ified it. And so, fixing stuff was hard. I didn't even know jQuery.

I didn't have the time to rebuild my portfolio website. I was creating a side-project.

I was looking for open source code already available.

# One fine day

[Telmo](http://telmo.online/) open sourced his awesome website. I am really thankful he did it.

He used the below stack.

- Next.js
- Markdown

That's it. It was easy, minimal, supported dark-mode, and was more content focused. Exactly what I wanted.

I used that open source project in my website. You'll see many similarities in his and my website.

---

# Final Thoughts

From now on, I am gonna post my content on this fine good-looking website.

If you like what I tweet, you'll surely like what I email you. So, make sure you subscribe for updates [here](https://tinyletter.com/kumar_abhirup/subscribe).


Essays & Writings