Forem: Abhijit Hota

Poor man's CI/CD with GitHub Webhooks

Abhijit Hota — Wed, 05 Oct 2022 05:02:17 +0000

Background

In my 5th semester of college (mid 2021), I was in-charge of the Web Operations team at E-Cell IITM. Our responsibility was to make web applications for events, workshops and competitions. The tech stack was primarily Node.js with Express, React and MongoDB for the database. If you're a full-stack developer, you might know this as the MERN stack.

The environment was fast-paced. We were building a lot of things and breaking more of them in the process. It was like a startup. The highest number of users for an application was only 6.5k. And that's the reason we could experiment a lot of stuff. Following best practices was something we tried a lot to inculcate by adding tools like linters, formatters, pre-commit hooks, etc. but again, we were all freshers; making and breaking things and somewhere down the line we would just push something with just a commit message of fix stuff.

We have an in-premise server in the institute cluster for hosting the MERN applications. It is just an Ubuntu box with pm2 installed for running Node.js apps. A lot of our time was spent in deploying very, very minor changes. Fix-a-typo-in-a-static-page-level minor. The process was generally this:

Connect to institute's VPN if you're not in Insti's network
SSH into the server
git pull
npm run build if it's a React application
pm2 restart frontend-server

Easy and simple. Manual and boring. Perfect characteristics of something that needs to be automated. Automation is the mother of invention when it comes to software development and so I went looking for answers.

Self-hosted GitHub Actions

The first and the most obvious solution was to use GitHub Actions. I've never used them before and was pretty excited to learn and use it. My excitement was soon doubled when I got to know that you can self-host them. I was able to learn it and setup it for our backend Node.js monolith in a day. But something felt off.

It required installing a lot of stuff to a rather humble machine. It also demanded a lot of memory relative to what our applications were using. To give you an idea, our main backend service uses 105 MB at maximum whereas the runner used around 1 GB in average.
The action was such that it checked out the whole repository every time. The repository was, in a way, large.¹
All our applications stayed in the home directory ($HOME). I could not figure out how to checkout the repository in the same place where it was and got around it by adding post-job scripts.
We weren't looking at a lot of scale so this level of sophistication felt overkill.

All we wanted to do was to run a few scripts on a git push. Surely, there was a minimal way of doing this?

The hack which seemed like the solution

Webhooks are an elegant way to communicate from server to client. They are one of the simpler ways to implement event-driven architecture. Think of webhooks as a third-party server sending an HTTP POST request to your own server. This doesn't require you to keep asking that server for data or keep an open connection. GitHub offers Webhooks for a lot of repository and organisation level events.

Here's how they work:

You provide a URL and a secret to GitHub. GitHub stores the hash of that secret.
You choose the events you want a webhook for.
Whenever that event happens, GitHub sends a JSON or XML payload via a HTTP POST request to the URL you provided in step 1. It also sends the signature which is derived from the secret you provided.
In your server, you check the signature with your original signature. If it's correct, you handle the payload however you want to.

The payload being talked about contains a lot of information related to the event.

And there was it. A simple HTTP POST containing relevant data. The idea was to commit and push with a commit message starting with deploy. The commit message, committer, files changed, etc. would be included in the payload for the push event. And here's how it panned out in our case:

Provide a URL like https://ecell.iitm.ac.in/api/gh-webhook
Choose to send the webhook only on push events.
When we receive a webhook, check if the commit message starts with deploy, the committer is one of the admins and some code is changed.
Run a simple script:

   git pull
   npm run build
   pm2 restart

Step by step instructions

Let's try to replicate this with an example repository and localhost as the server. Find the repository here: webhook-example.

Adding the webhook to the repository

Choose a repository you want to work on. You can fork the example repository. Make sure to rename .template.env to .env and change the secret string if you want to.
Go to Settings > Webhooks > Add webhook. Or just visit https://github.com/<username>/<repo-name>/settings/hooks/new.
We will start the server and expose it via a tunnel. I'm using cloudflared but you can use anything else if you want to.
As you can see, we have chosen application/json as the content type cause we want the payload in JSON. For the secret, you can put any random string but make sure you remember/note what you put there. For the example repository you also have to update your .env file. Details in the next section. > Note about SSL: We've only disabled it because it's just a demo. Enable this without fail in your real applications.

Listening to the webhook in your server

The index.js is the entry point for our server. It's a simple static site server in Node.js which serves a React build. We mount the webhook listener in the /webhook route. Notice how we used this route in the URL we provided to GitHub in the previous step.

   // Mount the webhook listener
   app.use('/webhook', webhookRouter);

In webhook.js, we first parse the .env file which contains our secret.

   dotenv.config();
   const SECRET = process.env.GH_WEBHOOK_SECRET;

Next we add 2 middlewares. The first middleware stores the raw request buffer. We do this because parsing damages the integrity of the signature.

   bodyParser.json({
    verify: (req, res, buf) => {
    req.rawBody = buf;
        },
   })

The second middleware verifies the signature sent with our secret that only we and GitHub knows. This way we know the request is actually a valid one from GitHub. This is why SSL is so important because without that you're exposing this request to MITM attacks.

   const body = Buffer.from(req.rawBody, 'utf8');
   const ghSign = req.get('x-hub-signature-256');
   const ourSign = 'sha256=' + crypto.createHmac('sha256', SECRET).update(body).digest('hex');
   if (ghSign !== ourSign) {
      throw new Error();
   }

And finally, we listen to it in the POST handler.

   webhookRouter.post('/', async (req, res) => {
        console.debug(req.body)
   }

At this point, if you push some changes, you can see the payload in your terminal where the server is running:

   {
       "ref": "refs/heads/master",
       "repository": {
           "name": "webhook-example",
           "full_name": "abhijit-hota/webhook-example"
       },
       "pusher": {
           "name": "abhijit-hota",
           "email": "abhihota025@gmail.com"
       },
       "head_commit": {
           "id": "6c386ca6d6f3df80ea7b0abd59c3b9a8c3983726",
           "message": "chore: add comments and increase legibility",
           "timestamp": "2022-10-05T22:19:21+05:30",
           "author": {
               "name": "abhijit-hota",
               "email": "abhihota025@gmail.com",
               "username": "abhijit-hota"
           },
           "added": [],
           "removed": [],
           "modified": [
               ".template.env",
               "index.js",
               "webhook.js"
           ]
       }
   }

I've removed a lot of stuff from the payload and have just shown the relevant ones. Now all that left is to run commands based on the data we get. More on this in the next section.

Building and executing commands

We're only going to see how to solve it for Linux but it shouldn't be that hard to build queries for Windows systems in a similar way, if you're using Windows at all for deployments.

We check for the commit message and the pusher. You can of course, choose your own logic here:

   const { head_commit: commit, pusher } = req.body;

   if (!commit.message.startsWith('deploy') || pusher.name !== 'abhijit-hota') {
       return res.send('Deployment skipped.');
   }

We create an array of commands to run. And we add to it as we go over the changes. The code is pretty self-explanatory and I've added comments too.


   const commands = ["cd "];
   const changes = [...commit.modified, ...commit.added, ...commit.removed];

   const requiresReinstall = changes.any((change) => change.startsWith('package'));
   if (requiresReinstall) {
       commands.push('npm install');
   }

   const hasFrontendChanges = changes.any((change) => change.startsWith('frontend'));
   if (hasFrontendChanges) {
       commands.push('cd frontend'); 
       const requiresReinstallInFrontend = changes.any((change) => change.startsWith('frontend/package'));
       if (requiresReinstallInFrontend) {
           commands.push('npm install');
       }
       commands.push('npm run build');
   }
   commands.push('npm start');

Join the whole command string with && and run it.

   const cmd = commands.join(' && ');
   console.debug("Command to run:", cmd);
   exec(cmd); // exec from child_process

Let's put it to test! We commit with the message deploy: test and we see the message:

   Command to run: cd /home/kreta/work/misc/webhook-example && git pull --all && git checkout main && npm start

npm start in the package.json starts the server in localhost:8080. And sure enough:

It's a hack at the end of the day

The performance cost is way less than GH Action runners. We run a separate Node.js server for this which only takes up like 50 MB of RAM. I'm sure we can remove all the fluff from there and make it leaner but it works for now.
For multi-repo systems, you can create organisation-level webhooks and change the command according to the repository field in the payload.
"But Abhijit, there's no CI at all!". Just add an npm test somewhere and log the reports, email, etc. if you care about it.

Addressing the obvious thoughts in your head, yes, it can break and there's no way of knowing if the command is faulty. But you can setup logging, alerts etc. It's your system. It's code. It cannot get more IaC than this. I set this up on the actual server almost 2 years ago and it hasn't been changed ever since. As you can see, this is a setup once and forget kinda system.

But if your infra is changing a lot of times and requires really good monitoring, please don't use this. This is a hack and I'm not very fond of hacks. Except for this one. This one, I'm proud of.

First principles are good

The simplest solutions are the best ones. If we go backwards from a solution to the problem, we can find better ways of thinking. Some hacks and workarounds can sometimes go against the practice of using the right tools and can feel like reinventing the wheel. But if the trade-off is worth it, maybe it is the best solution for it after all. Remember to scale with common sense.

The repository was larger than needed because it had a whole Bootstrap theme template. ↩

Node.js Import Aliases

Abhijit Hota — Tue, 05 Jul 2022 11:39:43 +0000

Originally published on abhijithota.me

The Problem

Oftentimes, as a Node.js codebase grows, this happens:

import { UserModel } from "../../../../db/models/index.js";
import { validate } from "../../../../lib/utils.js";
import { SERVICE_API_KEY } from "../../../../lib/constants.js";

There are a few problems with this:

Sensitivity to folder structure changes: A good IDE or editor can auto-import but not all of them are without errors. Also, what if you change something outside your general IDE?
Clutter: It just simply looks bad

The Solution

A new field in package.json called imports was stabilized in Node.js v14. It was introduced earlier in Node.js v12. It follows certain rules and lets you "map" certain aliases (custom paths) to a path of your choice and also declare fallbacks.

Here's the documentation for the same.

We can solve our example problem by adding this to our package.json:

"imports": {
  "#models": "./src/db/models/index.js",
  "#utils": "./src/lib/utils.js",
  "#constants": "./src/lib/constants.js"
}

and use them in your code anywhere like this:

import { UserModel } from "#models";
import { Validate } from "#utils";
import { SERVICE_API_KEY } from "#constants";

Note

The entries in the imports field of package.json must be strings starting with # to ensure they are disambiguated from package specifiers like @.
The values should be relative paths from the root of the project. The root is where your package.json is.

In the above example, we assumed package.json was at the root and all the relevant files were inside a src directory.

You should see your application run fine but your IDE of choice may show some errors. Undesirable red and yellow squiggles are no one's favorite. It would also auto-import from the actual relative path instead of the path alias. That's no fun.

jsconfig.json to the rescue. (tsconfig.json if you're in a TypeScript project.)

In your jsconfig.json, add the following

"compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "#models": ["./src/db/models/index.js"],
      "#utils": ["./src/lib/utils.js"],
      "#constants": ["./src/lib/constants.js"]
    }
}

The above configuration tells your IDE's LSP to look for code in the given prefixes. Refer to the documentation of the property to know more.

Now we have sweet auto-imports from the desired location:

Fallback dependencies

As seen in the documentation, you can also use this property for conditionally setting up fallback packages or polyfills. From the documentation:

// package.json
{
  "imports": {
    "#dep": {
      "node": "dep-node-native",
      "default": "./dep-polyfill.js"
    }
  },
  "dependencies": {
    "dep-node-native": "^1.0.0"
  }
}
[Here, if the] import #dep does not get the resolution of the external package dep-node-native (including its exports in turn), and instead gets the local file ./dep-polyfill.js relative to the package in other environments.

Frontend projects

I haven't tried this approach with frontend applications. They generally use a bundling system like Webpack or Rollup which have their own way of resolving aliases. For example, for Vite (which uses Rollup and ESBuild), you should add this to your vite.config.js:

import path from "path";

export default defineConfig({
//   Some other config
    resolve: {
        alias: {
            "#": path.resolve(__dirname, "./src"),
        },
    },
});

and in your jsconfig.json:

{
    "compilerOptions": {
        "baseUrl": ".",
        "paths": {
            "#/*": ["src/*"]
        }
    }
}

The above configuration maps everything starting with # to immediate folders and files below src. YMMV.

A designer knows he has arrived at perfection not when there is no longer anything to add but when there is no longer anything to take away

- Jon Bentley in Programming Pearls

Nerd-sniping myself over Go range expressions

Abhijit Hota — Sat, 02 Jul 2022 11:33:48 +0000

Originally published on abhijithota.me

The background

I stumbled across a situation while writing a Golang project where I needed to loop over a slice returned by a function.
The function being strings.Split. No big deal. I wrote the following:

for _, id := range strings.Split(path, "/") {
    // Something()
}

There's another way of writing the same thing:

splitPath := strings.Split(path, "/")
for _, id := range splitPath {
    // Something()
}

To the novice-eyed, like me, it would seem the latter was an optimized version as the function is only called once before the loop and hence more performant.

I did not care about the negligible performance gain I would get as the path variable passed to the split function would be limited in length by application constraints.

But what if it wasn't?

tldr; It doesn't matter how you write it. They are both the same.
From the Golang spec,

The range expression x is evaluated once before beginning the loop, with one exception: if at most one iteration variable is present and len(x) is constant, the range expression is not evaluated.

This seems obvious once you know about it because it's such a low-hanging fruit for the compiler. It's not even compiler optimization. It's compiler duty.

From here, I'm going to write about how I nerd-sniped myself into finding the answer to this and naturally, spent around 4 hours benchmarking, trying to figure out assembly, checking the compiler optimization wiki, some trivial experimentation that confirmed my theory and one line in the spec that made it all come together.

Before we proceed into this, have some context about the original scenario. The function should split a separated string called path with / as delimiter and extract all integers into an array like this:

func ExtractInts(path string) []int {
    pathIds := []int{}
    for _, v := range strings.Split(path, "/") {
        if v != "" {
            val, _ := strconv.Atoi(v)
            pathIds = append(pathIds, val)
        }
    }
    return pathIds
}

Benchmarking the two functions

I put together a quick small project to bench the thing consisting of main.go and main_test.go:

`main.go`

package main

import (
    "strconv"
    "strings"
)

func WithOptim(path string) int {
    pathIds := []int{}
    pathIdsStr := strings.Split(path, "/")
    for _, v := range pathIdsStr {
        if v != "" {
            val, _ := strconv.Atoi(v)
            pathIds = append(pathIds, val)
        }
    }
    return len(pathIds)
}

func WithoutOptim(path string) int {
    pathIds := []int{}
    for _, v := range strings.Split(path, "/") {
        if v != "" {
            val, _ := strconv.Atoi(v)
            pathIds = append(pathIds, val)
        }
    }
    return len(pathIds)
}

`main_test.go`

package main

import (
    "strings"
    "testing"
)

var path = strings.Repeat("734/956/831/811/", 100_000)

var resultWithOptim int

func BenchmarkWithOptim(b *testing.B) {
    var r int
    for n := 0; n < b.N; n++ {
        r = WithOptim(path)
    }
    resultWithOptim = r
}

var resultWithoutOptim int

func BenchmarkWithoutOptim(b *testing.B) {
    var r int
    for n := 0; n < b.N; n++ {
        r = WithoutOptim(path)
    }
    resultWithoutOptim = r
}

The variables r, resultWithOptim and resultWithoutOptim are needed to escape compiler optimizations and get reliable benchmarks.

Check out this section from the awesome benchmarking article by Dave Cheney.

Results

I ran the benchmark a couple of times.¹

In most cases, it was neck-and-neck:

BenchmarkWithoutOptim-8     63   18067614 ns/op
BenchmarkWithOptim-8        64   17833483 ns/op
3.282s

BenchmarkWithoutOptim-8     64   17879142 ns/op
BenchmarkWithOptim-8        66   17943536 ns/op
3.287s

BenchmarkWithoutOptim-8     66   17915000 ns/op
BenchmarkWithOptim-8        66   17567501 ns/op
3.292s

BenchmarkWithoutOptim-8     56   18344452 ns/op
BenchmarkWithOptim-8        57   17649186 ns/op
2.090s

In some cases the one with optimizations performed better:

BenchmarkWithoutOptim-8     64   18446009 ns/op
BenchmarkWithOptim-8        73   18054308 ns/op
3.548s

BenchmarkWithoutOptim-8     63   18466071 ns/op
BenchmarkWithOptim-8        70   18600002 ns/op
3.422s

BenchmarkWithOptim-8        64   18917323 ns/op
BenchmarkWithoutOptim-8     58   18092279 ns/op
3.215s

But in some cases the one without any optimizations performed faster!

BenchmarkWithOptim-8        55   18848131 ns/op
BenchmarkWithoutOptim-8     68   19239865 ns/op
2.395s

BenchmarkWithOptim-8        57   18323290 ns/op
BenchmarkWithoutOptim-8     63   17598465 ns/op
2.206s

Digging into the why

The first resource I came across was the Compiler And Runtime Optimizations wiki which stated nothing about such behaviour.

I also tried converting the code into Assembly using Compiler Explorer but couldn't understand any of it.

Was the compiler calling the function only once? Are the 2 ways of writing same? I had no way of knowing. Then I thought of something so trivial I felt dumb.

The trivial experiment

Consider the following code:

func Nums() []int {
    print("Nums called\n")
    return []int{1, 2, 3, 4, 5}
}

func Loop() {
    for _, v := range Nums() {
        print(v)
    }
}

func main() {
    Loop()
}

And surely enough, Nums called is only printed once to STDOUT.
This felt so obvious once I realised it.

Eureka + Facepalm moment

Googling "go range internals" gave me this article by Robbie V which sent me to the Go language specification where I found this:

The range expression x is evaluated once before beginning the loop, with one exception: if at most one iteration variable is present and len(x) is constant, the range expression is not evaluated.

Conclusion

There's nothing much to conclude but there's a lesson to learn. In Robbie V's article, the Step 1 was to RTFM.Unlike that, I dove right into benchmarking which was like comparing two sum functions which returned a + b vs. b + a.

I discovered a lot but this shouldn't have taken so much of my time. It's a reminder on how we can take some slightly interesting things, like the one I talked about here, for granted and never realise the machinery of it.

As to which function is better to write, that would be an opinion.

Other languages

I tried the same thing in a few other languages I've coded in because I never realised this:

JavaScript

function nums() {
    console.debug('Nums called');
    return [1, 2, 3, 4, 5];
}

function loop() {
    for (const v of nums()) {
        console.debug(v);
    }
}

loop();

Python

def nums():
    print("Nums called")
    return [1,2,3,4,5]

def loop():
    for l in nums():
        print(l)

loop()

Using go test -bench=. -run=xxx ↩

Specs:
goos: linux
goarch: amd64
cpu: Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz

Order of function execution was changed a few times.

The Unofficial Dev.to CLI

Abhijit Hota — Tue, 15 Jun 2021 08:29:23 +0000

The Dev.to CLI

Hello, everyone.

A few months ago, around the first week of December 2020, I started working on this project. The project was a CLI app which used the Dev.to API to communicate with the website. I got caught up with other things and couldn't finish the project as I wanted to before making it public in front of the Dev.to community.

Today, I put the project in community's hands, seeking for reviews, help and in hopes of making it better and usable.

GitHub Repo

This project is a work in progress. Bear with the useless dependencies, ~~bad~~ no documentation and half-implemented features.

Roadmap

✅ Post a markdown file as an article with front matter validation.
✅ Get user's published and unpublished articles
✅ Get followers
✅ Get user's reading list and navigate to browser
✅ Use the Dev.to API key to authorize
❌ Get and cache user info
❌ Read articles in terminal
❌ Get podcast episodes
❌ Use OAuth to authorize
❌ Tests?
❌ Consistent API

P.S. This article is posted using the dev-to-cli

Suggest me the right Linux distro

Abhijit Hota — Sun, 15 Nov 2020 09:55:40 +0000

Hello, good people of Dev! I need some help from the Linux users out there.

I've been thinking to switch to Linux (again) after being fed up (again) with Windows' constant lagging on my PC. I'm a web developer and just want a distro which is performant, good looking and has an abundancy of all the required packages (without any workarounds).

The distros in the banner are the ones I've been considering.

Linux Mint Cinnamon: I've heard it's very good for web development. It's lightweight and performant and I've heard some good things about Cinnamon. I've used Mint in the past (like 5-6 years ago).
~~Ubuntu 20.04~~: I've used Ubuntu and have been considering it only for: familiarity and availability of a large user-base. My main pet-peeves while using Ubuntu 18.04 were the unavailability of these following features:
- In Windows, the clipboard is at my disposal when I pressed Win + v. I didn't really search for a clipboard manager that does this.
- Blue light filter. I tried using Redshift but for some reason, I couldn't get it to work.
- Hibernation
~~Manjaro~~: I don't know anything about it.
~~Peppermint OS~~: I was considering it because some people claim it to be super performant.
Pop!_OS: Super pretty! Lots of support for it on the comments below! I'll probably end up using this.

So, suggest me anything that you think will suit me!

Web Development
Kinda done with the lag-ful experience in Windows.
Will run on Dual boot alongside Windows (which I'll mainly use for Photoshop, Premiere, etc).
Wants small important features which were mentioned as pet peeves of Ubuntu above.

Laptop Specs:

1 TB HDD
Intel Core i5 8th Gen @1.60GHz
8GB RAM
Nvidia GeForce MX130

Thanks!

Edit: add laptop specs

Update

Thank you everyone for the suggestions and inputs! By far I've cut the list short to Mint Cinnamon and Pop!_OS. I looked at Fedora too but as I'm not really familiar with it, I doubt if I'll be using it.

Thanks for your inputs on Manjaro and letting me know about other cool distros like Zorin OS and Elementary OS. I'll surely try them out in the future!

P.S. I researched a bit and found out that the hibernating feature is not available out of the box in any Linux distribution(?).

Update: Aug 2021

I bought an SSD and shifted to Linux Mint and have been using it for a month.

I don't miss the hibernate feature because booting & shutting down takes less than 10 seconds
I use CopyQ for clipboard management
Yet to find a Redshift alternative that can be turned on at any time and not just during the night

Thanks everyone for the inputs!

Can open-source documentations be monetized?

Abhijit Hota — Sat, 12 Sep 2020 02:52:02 +0000

I came across an Android app called Node.js Docs by an organisation named NextLabs.cc. Here is the app in Google Play store.

And to my surprise, they have monetized the contents!

Specifically,

There are banner ads in the app.
To access the documentation of each version for one day, you need to watch a 15 second video.
You can buy the whole app for a very little amount but it's monetization nonetheless.

I don't know much about open-source licenses and monetization so I wanted to ask it here.

Is this legal?

I'd like to know more about licenses and how all these work.

MovieDex - My first React project!

Abhijit Hota — Thu, 06 Aug 2020 12:13:36 +0000

A React and Node.js app that searches for movies using the TMDB and OMDB database ⚛✨🎥. Try it out here: MovieDex

The Project

I came across this article: 9 Projects you can do to become a Frontend Master in 2020 while I was browsing around Dev and I wanted to build the first one in the list and so I did!

I made the first prototype in a single sitting. My app was able to search for movies and display them. Great!

But I wanted to amp things up!

I thought what if you even showed the movies details in form of modals?

And here you are, an app that searches movies and gives you the relevant details!

Powered by ✨

Node.js : A server for handling all the API calls to the TMDB and OMDB API. I did not implement the calls in the client side as they involved calling with secret API keys.
React : What I really focused on in this project. ⚛💙
Material-UI : Absolutely loved the components! Some of the components I've used in this project are: Card, TextField, Dialog and my personal favorite, Skeleton loaders.
The Movie Database : For searching the movies.
Open Movie Database API : For extensive data. (Ratings were not provided by TMDB API).
Logo by me. Font used: BLANKA. Some Photoshopping around and Ta-da! 😂

Some background about my React journey:

I started learning React in the beginning of July, I guess?
My learning sources included the awesome React tutorial by Codevolution on YouTube and the official React docs and some random but highly insightful blog posts by various authors.

I highly recommend the above mentioned tutorial.

I hope to make better and bigger things in the future! Continually learning and improving. If you like the project, please consider giving it a star on GitHub and sharing!😇 Any suggestions and feedback is greatly appreciated. 😄

Can you help me review my MEN stack app?

Abhijit Hota — Mon, 13 Jul 2020 14:32:34 +0000

You can find the app here.

I've been learning Node.js for the past few months and I recently deployed my first MEN stack app on Heroku. The app lacks a UI as I wanted to focus on the backend part.

The reason I'm writing this post is because I want to:

Ensure that I am following, if not all, but some of the best Node.js practices.
Know how well my approaches to the problems are and how can I improve them. Feedback on the directory structure, code modularisation, styling, etc. will be helpful.
Know what can I do to make my app more of a 'production-level' app.
Know something that I don't know I don't know!

The README file in the GitHub repository for the app provides a good overview of the app.

Any help will be appreciated 😄.

P.S. This is my first post on Dev.to