DEV Community: Amartya Chowdhury

Demystifying QR Codes

Amartya Chowdhury — Fri, 21 Aug 2026 16:37:29 +0000

We have all used QR codes at some point of our life. UPI payments in stores, scanning QRs on posters to register for an event, sometimes even restaurants where the entire menu is stored on a QR code. But have you ever wondered how it works? If your answer is no, don't worry. I was the same lol. But I suddenly felt like going into this rabbithole, and it was a crazy experience to say the least.

Let's start from the beginning. QR stands for Quick Response. It was first created back in 1994 at a Japanese automobile company to track the types and numbers of different parts. But with the advent of the 2000s and the Internet, people soon found the potential of QR codes left untouched, and now its become a common part in many systems.

A QR code can seem random at first, but every black and white pixel carries a meaning. It contains some static patterns, like the three 7x7 squares at the top-left, top-right, and bottom-left corners, which are used by a scanner to determine the extent of the code to be scanned. There are predefined rules to placing information on the grid, and we will discuss them as we progress further in this blog.

Phase 1: Encoding text into bytes

A QR code is a bunch of black and white pixels. Every dark pixel is 1 and every light pixel is 0. So, the input text must be encoded into binary bytes so that it can be engraved into the grid.

There are a few different modes of encoding, but the ones we will talk about are the following three:

Numeric mode: It is the most efficient mode to encode text containing only numeric values. It uses 10 bits to store 3 digits (2^10 = 1024 > 999), 7 bits to store 2 digits (2^7 = 128 > 99), and 4 bits to store 1 digit (2^4 = 16 > 9).
Alphanumeric mode: This mode has a character set of 45 elements, including uppercase characters A-Z, digits 0-9, space, $, %, *, +, -, ., /, :. It uses 11 bits to store 2 characters ((45 x first_char) + second_char), and 6 bits to store 1 character (2^6 = 64 > 45).
Byte mode: This mode stores every character as a single byte, according to ISO 8859-1 character set, or if supported, UTF-8. Here, every character is stored with 8 bits (1 byte).

We would write the code in a way so that it can automatically determine the best encoding mode to use, as per the characters present in the input text.

It is time to construct the message data bytes. The first four bits represent the encoding mode, as follows:

1. Numeric mode: 0001

2. Alphanumeric mode: 0010

3. Byte mode: 0100

Next would be to encode the number of characters in the input (i.e. character count of input text). Different versions of QR code specify the number of bits the character count must be represented it. I highly recommend readers to go through Thonky's QR Code Tutorial for detailed information.

After the character count, its time to finally push the encoded bytes of input text. At the end of these bytes, terminator bits are added, which are 4 0s. If however, there isn't enough space left for 4 0s, the spec says to add only the number of 0s that are available.

After adding the terminator bits, if the number of filled bits is not a multiple of 8, add more 0s to pad it up to the next nearest multiple. Following that, we add bytes 236 and 11 alternatively until the full allocated message data bytes are full.

Phase 2: The Math (and correcting errors)

This is where the math starts. We start with Galois Field. A Galois Field GF(p) is just a set of numbers that follow all general properties (closure, associative, etc) of all operations like addition, subtraction, multiplication, division. In a field GF(p), every operation is mod p.

For example, let's take GF(5). The set of numbers would be {0, 1, 2, 3, 4}. Addition: a + b (mod 5). For instance, adding 1 and 3 would be 1 + 3 = 4 mod 5 = 4. For numbers greater than 4: 2 + 7 = 9 mod 5 = 4. This follows for all operations, wrapping every operation result into the set of numbers provided.

In our case, we use GF(2^8) since we are working with bytes, so the possible values are 0 to 255, decimal values possible in 8 bits (1 byte).

Multiplication in GF(2^8)

In regular arithmetic, multiplying two 8-bit numbers can go up to 65025. To fit all results within 0 to 255, numbers in GF(2^8) are treated as polynomials where (n+1)th bit is the coefficient of x^n (e.g. 8th bit - x^7, 3rd bit - x^2, 1st bit - x^0 (constant term)). For example, 13 in binary is 00001101, represented as a polynomial as follows:

1.x^3 + 1.x^2 + 0.x + 1 = x^3 + x^2 + 1

To keep multiplication bounded within 0-255 (8 bits), we multiply these polynomials using standard algebra and take the remainder after dividing by a primitive polynomial (an irreducible polynomial that acts as the prime number for field restriction).

For QR codes, the standard primitive polynomial specified by ISO/IEC 18004 is x^8 + x^4 + x^3 + x^2 + 1 (represented as hex 0x11D or decimal 285).

NOTE: Addition and subtraction in GF(2^8) are both equivalent to XORing the two numbers.

Fast way: Log and Antilog Tables

Doing full polynomial long divison for every single multiplication during Reed-Solomon generation would destroy performance. Instead we use a property: a primitive element g (generator) can generate every non-zero element in the field through exponentiation. For QR codes, we use g = 2.

By pre-computing two 256-element lookup tables (an exponential (antilog) table and a log table), we can convert heavy polynomial multiplication into simple integer addition:

a x b = exp((log(a) + log(b)) mod 255)

Error Correction Levels

Before moving on to actually error correction, we need to discuss the different error correction levels. QR codes have four different levels, each having a different number of error correction bytes to be added depending on the version of QR code. The four levels are:

L (Low): 7% error correction
M (Medium): 15% error correction
Q (Quartile): 25% error correction
H (High): 30% error correction

Generating Error Correction Bytes (Reed Solomon Codes)

This is the error correction method we will be using for QR codes. Reed Solomon error correction works by taking your message bytes, treating them as coefficients of a high-degree message polynomial M(x), and finding the remainder when divided by generator polynomial G(x). The remainder R(x) contains the actual error correction bytes to be appended to the original message bytes.

1. Generator Polynomial G(x)

A generator polynomial for k error correction codewords is created by expanding the factors (x-2^0)(x-2^1)...(x-2^(k-1)) using GF(2^8) arithmetic. For example, for k=7 error correction bytes:

G(x) = (x-2^0)(x-2^1)...(x-2^6)

Expanding this gives a polynomial with 8 terms whose coefficients are elements in GF(2^8).

2. Polynomial Synthetic Division

To compute the remainder, we perform synthetic division of M(x).x^k by G(x) inside our field:

Shift the message polynomial left by k positions (multiplying by x^k) to leave k zero bytes at the end for error correction bytes.
Step through each byte of the message:
1. Take the first byte of the current remainder buffer as a multiplier scale factor S.
2. If S != 0, multiply each coefficient of G(x) by S using our log/exp lookup tables.
3. XOR the scaled generator polynomial into the remainder buffer.
4. Shift the remainder buffer left by 1 position.
Once all message bytes are processed, values remaining in the remainder buffer are the exact Reed Solomon Error Correction Bytes.

And we are done! We now have the error correction bytes, and we append it to the end of the message bytes we had previously.

For implementation details, you can refer to my QR code generator in Rust, linked in a later section.

Phase 3: Masks and Format String

We are almost at the end. The last phase is to choose a mask and create the format string. A mask is essentially a formula which decides which pixels on the grid should be XORed. The main reason of using a mask is to reduce unnecessary concentration of same-color pixels and other factors that can affect the ability of scanners to properly scan a QR code.

There are 8 different masks, ranging from 0 to 7 (000 to 111). I will not be going through all the formulae here, but again, I recommend you to go through Thonky's guide for details on this.

Choosing a mask: Penalty Rules

All the 8 masks are applied on to the grid, each is checked against four penalty rules, and the mask with the least penalty score is finalized. The beauty of masks is that they are their own negatives, i.e. XORing a mask onto a grid masks it, XORing it again gives us back the original data grid.

The four penalty rules are as follows:

Continuous runs of same-color modules of length 5 or more, in a row or a column.

Score: 3 + (n - 5) per run of length n >= 5.
2x2 blocks of same-color modules.

Score: 3 points per 2x2 block.
Patterns matching 1011101 surrounded by 4 light modules (finder-like false positives).

Score: 40 points per occurrence.
Proportion of dark vs light modules deviating from 50%.

Score: 10 x floor(abs(dark_percent - 50) / 5).

Format String

Once a mask is selected, we need to encode metadata directly into the QR code so that a scanner knows which error correction level and mask was used.

The format string is 15-bits long, with 5 data bits and 10 error correction bits. Out of the 5 data bits, 2 bits represent error correction level, and 3 bits represent the mask used (000-111). For error correction level:

L -> 01
M -> 00
Q -> 11
H -> 10

The 10 error correction bits are generated with the help of BCH codes.

BCH Error Correction

Because the format string is critical for decoding the entire QR code, it gets its own error correction using a BCH (Bose-Chaudhuri-Hocquenghem) (15, 5) code. To generate the 10 error correction bits:

Shift the 5-bit value left by 10 bits.
Perform polynomial division modulo 2 using generator polynomial G(x) = x^10 + x^8 + x^5 + x^4 + x^2 + x + 1 (which is 0x537 or 10100110111).
The 10-bit remainder is appended to the original 5 bits to form a 15-bit codeword.

Masking the format string

To ensure that format strings don't accidentally contain long runs of all zeros or all ones which could confuse scanners, the final 15-bit string is XORed with a fixed mask: 101010000010010 or 0x5412.

The 15-bit format string is written into two redundant locations on the QR code to survive physical damage or corruption:

Around the top-left finder pattern
Divided between top-right and bottom-left finder patterns

NOTE: Remember to skip the dark module at coordinate (4 * version + 9, 8) which always remains dark (as per QR code specification).

Implementing Everything: The Battle Wounds I Have

Writing qred, my own implementation of a QR code generator, wasn't a smooth ride in the slightest. I faced quite a few brain-frying bugs:

Bit placement order: The issue wasn't in error correction math or matrix generation. Everything was working perfectly, but turns out I was writing the bits of the format string in reverse order. Bit 14 in the place of bit 0, bit 13 at bit 1, and so on. That alone took one day for me to find, and I couldn't even find it alone (massive Claude W).
The Math: I'm surprised I even managed to finish this project. Given my background of not liking math (or so I thought), I expected face much more trouble. Thankfully, after the first weird bug found at the remainder generation of Reed Solomon, I started writing unit tests for every file, ensuring the code of the current phase is fully functional before moving on to the next phase with a broken foundation.

I implemented it in Rust BTW (I use Arch BTW)

Benchmarks

I didn't leave it after just writing everything. I wanted to see the fruits of my labor. So for the first time in any of my Rust projects (don't bully me, I'm pretty new to this field), I downloaded criterion, set up benchmark functions, and started measuring performance. Here's the results, analyze them and judge whether they're good or bad, because I'm leaving absolutely no comments here:

Operation	Output	Execution Time
Matrix Generation Only	Pure Bit Matrix	179.92 µs
Default Image Save	Standard PNG Export	237.19 µs
Single Custom Color	Custom Foreground	274.65 µs
Dual Custom Colors	Custom Fore & Background	281.26 µs

What I Left Out

Of course, I didn't touch every little detail in this small blog. I have left out some parts, like:

Static patterns like finder patterns, timing patterns, alignment patterns, etc.
Exact locations of format strings, message and error correction bytes.
The order of reading the data bytes.

Next Steps

To dive deeper into this rabbit hole, I recommend these sources as I used them myself:

Like me?

Well then, you're not alone (I like myself too)! Check out more about me:

LinkedIn: https://linkedin.com/in/amartya-chowdhury
GitHub: https://github.com/aether-flux
qred Crates.io: https://crates.io/crates/qred

A bonus flex: Wanna see my implementation in practice? Scan this QR generated by qred to get to my portfolio:

You Don't Have to Grind LeetCode

Amartya Chowdhury — Wed, 17 Sep 2025 15:23:57 +0000

Yes, you read it right. Everyone says "you should do 500 problems on LeetCode at least". And sure, to some extent, it is helpful. But it's not everything. You don't need to follow the same path if you see a bunch of people on Twitter/Linkedin doing a "100 days of code" challenge.

Are you inconsistent, no matter how hard you try?

Have you ever felt like no matter how much you try to be consistent, try to do at least one LeetCode problem a day, you just can't keep it up for more than a week? Do you have to force yourself just to be consistent?

So let's look at it from a different perspective. Let's say, like me, you are someone who hates the subject of biology. I have always hated that subject, to the point that I couldn't bring myself to keep my eyes open for 2 minutes without trying to force myself awake again. And I was a student who never slept in study sessions. No matter how much I forced myself to study biology, I could never do it well.

Sounds similar? Because it is. Maybe underneath all of the Twitter/Linkedin posts and flexes of LeetCode grinds and coding challenges, it has never even crossed your mind that maybe this LeetCode grind is just not what you love.

No LeetCode? Then what?

It is very much possible that you are the kind of person who just isn't built for LeetCode grinds. And that isn't necessarily a bad thing; it's just a different style. Maybe you are built for LeetCode grinds, or maybe you are someone who likes to see immediate results, someone who prefers building a website or an app to see their work in action, someone who likes to handle domains and manage servers, maybe even someone who's just a complete nerd that likes Linux and Vim (don't worry, I'm with you 😔).

Everybody has a different thing they love. Taking myself as an example again, I was never someone who liked solving LeetCode problems. That was primarily because I couldn't see any effects of my code immediately. I had always preferred building websites where I can see the fruits of my action. Even now, I am very development-oriented, although I don't really like frontend dev (sorry fellow frontend devs 😔). I currently build backend systems and infra/devtools, but the concept is still the same: building something actually useful and not just blindly solving random problems.

So, is LeetCode (or any problem solving) useless?

This is where most people misunderstand. I am not saying that LeetCode grind, or any kind of problem solving, is useless. It's the most important, in fact. DSA is a major factor in you becoming a better developer.

However, it's not essential that you learn DSA through just LeetCode problems. DSA shines the most when it's applied in real-life products. For example, build something yourself, maybe a backend or some library, and experiment about how to make it more efficient. Maybe learn about which algorithms would be better and more efficient, or just design one yourself. Maybe use a linked list instead of an array in some cases. That is where DSA shines. That is where real problem-solving takes place.

I'll put a little flex of myself again. I was working on my backend framework (Rensa), and my first draft of the routing system used plain arrays to store routes and route handlers. As a result, whenever a user would hit a route on the server, it would take O(n) time to search for the route (n is the number of routes) and it's handler and call it. Very inefficient for good backend servers. So, I researched a bit and stumbled upon Tries. Implemented route storage with that, and boom, the time complexity reduced to O(l), where l is the length of route. It doesn't depend on the number of routes registered, which is better as a server increases in size. Then a sudden enlightenment hit me all of a sudden, and I implemented a hybrid Trie+HashMap for storing routes. Now, although theoretically the time complexity was still O(l), but for completely static routes (like /home/dashboard, unlike /user/:userId), it practically worked in O(1) (constant) time, thanks to the newly introduced HashMap. (Read more about the entire approach here).

As you can see, you can start something small with just as much knowledge as you have right now, and with time and research you can keep on improving your solutions bit-by-bit.

Conclusion?

The conclusion is just that you don't need to feel guilty if you can't stay consistent, you just need to change your ways. Sure, LeetCode problems are definitely not useless and they do teach you about how many commonly encountered problems can be solved. But it's not everything, because ultimately, you will be having to build systems and not be only solving problems all your career.

So, the next time you feel demotivated because of inconsistency, just remember this:

If you have to force yourself to do something, it probably isn't for you. Time to change your ways.
Consistency will automatically follow you if you're doing something you truly love.

Time for some personal promotion, so before you leave, make sure to follow me on Twitter and LinkedIn.

Building Profig - A Config Framework

Amartya Chowdhury — Thu, 07 Aug 2025 15:33:37 +0000

I've worked with config files for a long time. Be it for my own tools/projects or for using it for other purposes, I have needed to manage configs manually for a long time. Until I discovered that there exist literal config managers, and that I had been wasting my efforts for absolutely no reason.

I found that there were a bunch of good options available for config managers in JavaScript (NPM). However, the same is not the case for Rust. Here, there are limited options, popular ones being config, config-manager and figment. And so I set out to work on a new project, and here it is:

What is Profig?

Introducing Profig, a config framework, that removes the Con in Config. This is still in very early development stages, and I've only released just v0.1, but I think it's still usable in small and maybe even medium sized projects.

Features

Profig is currently v0.1, and it has the following features:

Macros like #[derive(Profig)] and #[profig(...)] to define config schema structs
Enforce only certain file formats to be allowed to load data from, using #[profig(format="json,toml")]
Every field of the struct will have its own metadata, defined via #[profig(min="..", max="..", default="..", regex=r"..", doc="..")]
Data can be loaded from any file using AppConfig::load("filename.ext") (assuming AppConfig is the name of the struct defined), and it returns an object of type AppConfig
It validates every field data according to the metadata (min, max, regex etc.) and fills a field with the default value if applicable
Sample config files can be generated via AppConfig::sample_config("sample.yaml") using the data available in the metadata of the fields (defined using #[profig(...)])
Documentation can be generated automatically using AppConfig::generate_docs("docs.md") which generates a markdown file using the doc metadata of every field
Multiple formats: JSON, TOML, YAML (all as their own features)

Usage

All these features can seem confusing and overwhelming at first, even though they aim to greatly enhance DX. So, let's do a bit of practical.

Let's imagine a situation where we need the user to define a config file which contains some data like host name, port number, user email, and the number of worker threads. The user may have a JSON or a YAML file as a config file. Using this data, our Rust code is supposed to authenticate/validate the details and then start a server or do something else, as required. Suppose that we are to build a CLI, and we need the details from a config file, as mentioned. Let's see how simple it is to achieve with Profig.

Before anything else, let us first add the crate to our project. Since we need JSON and YAML configs, we will enable those features while installing.

cargo add profig --features "json,yaml"

First, we define a schema for the config file. To define the schema, we use the attributes provided by Profig as follows:

#[derive(Profig)]
#[profig(format="json, yaml")]
struct HostConfig {
  #[profig(min="4", max="10", doc="Number of worker threads")]
  threads: u32,

  #[profig(default="localhost", doc="Name of the host")]
  hostname: Option<String>,

  #[profig(min="1", max="65536", doc="Port number to listen to")]
  port: u32,

  #[profig(regex=r"^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,4}$", doc="Email address of the user")]
  email: String
}

This is all we need to do in order to define the schema/format of the config files. We specified formats as json and yaml as those are the only ones allowed. Now to read data from a file, say config.yaml, we can do so as follows:

fn main() -> Result<(), Box<dyn std::error::Error>> {
  let confData = HostConfig::load("config.yaml")?;
  // All data can now be accessed as confData.email, confData.host etc
  // because this returns an object of type HostConfig.
  // You can use this data for any further logic implementation
}

And voila! You have successfully loaded and used data from config files!

Sample Config

You can also generate a sample config file in a single line, using the following function:

HostConfig::sample_config("sample.json")?;

This will create the following type of sample file (JSON here):

{
  "threads": 4,
  "hostname": "localhost",
  "port": 1,
  "email": "REQUIRED; must match ^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,4}$"
}

Documentation Generation

That's not all. You can also generate a documentation for your defined config structure in a single line! Just call the following method:

HostConfig::generate_doc("docs.md")?;

And it will generate you a markdown file filled with data like field name, field data type, and a field help/doc line if provided (via the doc="..." value in the field-level metadata).

🛠 Tech Dive

For the bit more nerdy humans like myself, let's talk a bit about the tech. This project uses Rust (no s**t Sherlock), along with:

Serde, serde_json for storing and validating the data
serde_json, serde_yaml and toml crates to load data from different config file types
Procedural macros to make the #[derive(Profig)] and #[profig(...)] attributes to make DX smoother
Feature flags for every file format to avoid unnecessarily bloating the crate

This is an architecture/design of the entire working or flow:

️

Final Notes

All in all, Profig is a config framework that I plan to keep building and improving as time sees. It is in very early stages right now, being just v0.1, so there will be quite some changes before even Profig v1 is launched.

In the meanwhile, I would love any and all feedbacks and advice.

Please do try it for yourself if possible:
🦀 Crates.io
💻 GitHub

For more updates, follow me on:
LINKEDIN
TWITTER

Building Profig - A Config Framework

Amartya Chowdhury — Thu, 07 Aug 2025 15:33:37 +0000

What is Profig?

Features

Profig is currently v0.1, and it has the following features:

Macros like #[derive(Profig)] and #[profig(...)] to define config schema structs
Enforce only certain file formats to be allowed to load data from, using #[profig(format="json,toml")]
Every field of the struct will have its own metadata, defined via #[profig(min="..", max="..", default="..", regex=r"..", doc="..")]
Data can be loaded from any file using AppConfig::load("filename.ext") (assuming AppConfig is the name of the struct defined), and it returns an object of type AppConfig
It validates every field data according to the metadata (min, max, regex etc.) and fills a field with the default value if applicable
Sample config files can be generated via AppConfig::sample_config("sample.yaml") using the data available in the metadata of the fields (defined using #[profig(...)])
Documentation can be generated automatically using AppConfig::generate_docs("docs.md") which generates a markdown file using the doc metadata of every field
Multiple formats: JSON, TOML, YAML (all as their own features)

Usage

All these features can seem confusing and overwhelming at first, even though they aim to greatly enhance DX. So, let's do a bit of practical.

Before anything else, let us first add the crate to our project. Since we need JSON and YAML configs, we will enable those features while installing.

cargo add profig --features "json,yaml"

First, we define a schema for the config file. To define the schema, we use the attributes provided by Profig as follows:

#[derive(Profig)]
#[profig(format="json, yaml")]
struct HostConfig {
  #[profig(min="4", max="10", doc="Number of worker threads")]
  threads: u32,

  #[profig(default="localhost", doc="Name of the host")]
  hostname: Option<String>,

  #[profig(min="1", max="65536", doc="Port number to listen to")]
  port: u32,

  #[profig(regex=r"^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,4}$", doc="Email address of the user")]
  email: String
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
  let confData = HostConfig::load("config.yaml")?;
  // All data can now be accessed as confData.email, confData.host etc
  // because this returns an object of type HostConfig.
  // You can use this data for any further logic implementation
}

And voila! You have successfully loaded and used data from config files!

Sample Config

You can also generate a sample config file in a single line, using the following function:

HostConfig::sample_config("sample.json")?;

This will create the following type of sample file (JSON here):

{
  "threads": 4,
  "hostname": "localhost",
  "port": 1,
  "email": "REQUIRED; must match ^[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,4}$"
}

Documentation Generation

That's not all. You can also generate a documentation for your defined config structure in a single line! Just call the following method:

HostConfig::generate_doc("docs.md")?;

And it will generate you a markdown file filled with data like field name, field data type, and a field help/doc line if provided (via the doc="..." value in the field-level metadata).

🛠 Tech Dive

For the bit more nerdy humans like myself, let's talk a bit about the tech. This project uses Rust (no s**t Sherlock), along with:

Serde, serde_json for storing and validating the data
serde_json, serde_yaml and toml crates to load data from different config file types
Procedural macros to make the #[derive(Profig)] and #[profig(...)] attributes to make DX smoother
Feature flags for every file format to avoid unnecessarily bloating the crate

This is an architecture/design of the entire working or flow:

️

Final Notes

In the meanwhile, I would love any and all feedbacks and advice.

Please do try it for yourself if possible:
🦀 Crates.io
💻 GitHub

For more updates, follow me on:
LINKEDIN
TWITTER

I Got Tired of Repeating the Same Commands, so I Built Jido - a Workflow Automation CLI

Amartya Chowdhury — Fri, 16 May 2025 18:51:44 +0000

As a developer, you may have had moments where you find yourself running the same bunch of commands repeatedly. For example, bumping package.json version, pushing to git, and publishing to NPM, whenever you wanna ship a new version of your NPM package.

I was facing the same issue. And given how lazy my brain is, I wanted to make this easier and simpler. So, I built Jido.

What is Jido?

Jido is a workflow automation CLI, where you can define your workflows (called flows) in a config file, and run them using npx jido flow <flowname>.

The config file is a jido.config.js in the project root. So, custom JS logic is also applicable, unlike Bash scripts.

Get started with jido by running:

npm install --save-dev jido

The Config File

The jido.config.js file call the jido() function and export it by default. It takes in an object as argument, which has the key flows that holds an array of objects, each object defining a flow.

Every flow has:

name: Name of the flow
description (Optional): A short description about the flow
steps: Array of objects, each object defining what each step would do

Each step is of the following form:

run: The command to be run at this step (eg, 'npm run dev' or 'git push' etc).
onStart, onSuccess, onFailure: Optional hooks. These are functions that will be called on start, success and failure of the step.
plugins: An array of objects, where each object is a plugin. We'll talk more about this in a while.

To scaffold a basic config file, run npx jido init. It'll generate the following config file:

import { jido } from "jido";

/*
* Define your workflows here.
* Each flow is a series of steps with commands to run and optional hooks (onStart, onSuccess, etc) to execute.
*/

const config = {
  flows: [
    {
      name: "run",
      description: "Run the project",
      steps: [
        {
          run: "npm install",
          onStart: () => console.log("Installing dependencies..."),
          onSuccess: () => console.log("Dependencies installed!"),
          plugins: []  // Any plugins go here
        },
        {
          run: "npm run dev",
          onStart: () => console.log("Starting dev server..."),
          plugins: []  // Any plugins go here
        }
      ]
    }
  ]
}

export default jido(config);

Plugins

Now, another fun part of Jido. Plugins. A plugin is essentially an object of the following type:

type Plugin = {
    onStart?: Hook;
    onSuccess?: Hook;
    onFailure?: Hook;
};

Basically, its an object with any or all of these hooks, which are attached to the step where the plugin is attached to.

However, the recommended way of writing a plugin is to write it in a function which returns an object of the above type. This allows in custom and argument-dependent functionality of a plugin.

For example:

// Plugin function
const myPlugin = (name) => {
    return ({
        onStart: () => {
            console.log(`[myPlugin] Hello, ${name}! Step started...`);
        }
    });
}

// In a step in the config file:
plugins: [myPlugin("aether-flux")]

// In another step:
plugins: [myPlugin("John Doe")]

Now, Where Do You Use Jido?

Well, one of the use-cases is when publishing a new version of a package to NPM or anywhere else. That was the reason why I even thought of making this CLI.

There are many other applications as well. For instance:

Deploy to vercel after a successful build.
Clean + Reset project state before testing.
Run local dev with custom logging and/or analytics tracking.
Alert team (Slack, Discord, etc) after a successful build and deploy.

And anywhere else really, where you find yourself running the same bunch of tasks over and over again.

So, What Do You Think?

I hope Jido can simplify repetitive tasks for many devs out there, thus allowing them to focus more on the fun part (aka 'coding') rather than spending so much time just pushing to github and building and deploying and all that.

Do give it a chance in your workflow once. I'm sure it'd work wonders.

BTW, publishing any new version of Jido is being automated by jido.

⚒ The Hidden Complexity Of Routing: Why Your Requests Take Longer Than They Should

Amartya Chowdhury — Wed, 26 Feb 2025 17:08:59 +0000

When you type a URL and hit Enter, does it just magically find what to load in the page? Or when building your own server, just adding app.get("/user/:id") will do all the magic itself?

The simple answer is NO. We usually never think much about routing and how it works, but its one of the major factors that affect the performance of a framework and a server.

😮‍💨 The Normal Approach

The simplest way we all think first when asked about how to implement routing is to use a basic for loop.
1️⃣ Store the routes in an array.
2️⃣ When a request is made, search for that route in the array using a for loop.
3️⃣ If the route is found, the corresponding logic is executed.

The problem? Speed.
Imagine a huge server with 1000+ routes. Then, to search for a specific route using this approach, what is the time required? O(n), n being the number of routes, i.e. 1000 here. That's a huge blow to the performance.

🚀 The Better Approach

You may be wondering, what should be done then? The answer lies in a magical little data structure, Trie.

A trie is basically a tree, which stores strings character-by-character, branching out whenever required (see image for better understanding). This reduces unnecessary comparisons, and you can just follow the path in the trie and find the matching path.

The time complexity? Just a mere O(s), s being the length of route. So, if "/users" is the URL, s is 6. No matter how many thousands of routes exist in the server, this approach only thinks about the route that is being requested, significantly reducing the time taken and enhancing performance.

🔥 The Even Better Approach

Now, is there any way to make this approach even more performant? The answer is to use a HashMap.

The trie is still going to store every route as it used to store earlier, character-by-character. However, this seems inefficient too, as most routes that get requested to a server are usually just static sites ("/users", "/dashboard" etc).

So, we use a hashmap here. While storing the routes, we get all the static parts (words) of the route (ex 'dashboard' and 'home' in "/home/dashboard") and store them in the hashmap as keys. Their values will store the ending node of the trie where these static words end.

When a request comes in, we first check if each part is static or dynamic. If its static, we instantly look in the hashmap first. If found, we get at which node of the trie it ends, and start searching from there again.

This updated approach helps in jumping through the static words stored in the trie and only check for dynamic parts (like 'id' in "/user/:id").

Since most requested routes contain static routes, this approach improves performance significantly. Although the time complexity is still O(s) theoretically, in practice, most routes, especially ones with just static parts, get searched in just O(1).

So What's The Takeaway?

Routing isn't just about matching URLs to functions—it directly impacts server performance.

❌ A simple for loop works, but it doesn’t scale well.
✅ A Trie speeds things up, as lookup time depends only on route length.
🚀 Combining it with a HashMap makes it even more efficient, allowing many static routes to be matched in near O(1) time.

Many modern frameworks use optimized routing techniques under the hood, but knowing how they work gives you the power to build faster, more scalable applications. So, the next time you write app.get("/user/:id") you'll know the real magic behind it 😉

For more informative stuff, follow me on LinkedIn and Twitter.

⚡ Tired of DB Setups? Meet Swapp: The Universal DB Adapter

Amartya Chowdhury — Sun, 09 Feb 2025 08:11:12 +0000

Let's be honest: working with databases can be a pain. Whether its a SQL database like MySQL or PostgreSQL, or a NoSQL one like MongoDB, each has its own syntax, setup and quirks. Using any one of these involves copying and pasting tons of boilerplate code, and dealing with all sorts of dependencies.

And don't even get me started on switching databases, especially from a SQL to a NoSQL one or vice-versa. Learning multiple different ways to write queries for the same basic operations gets annoying, right?

That's where Swapp comes in!

Imagine setting up a database with just one statement, and use one query language for both SQL and NoSQL databases. Sounds like a dream? Well, it just got real!

🚀 Swapp.js is live!

🔗 GitHub Repo | 📦 NPM Package

🚀 Swapp.js just launched on Product Hunt! and Peerlist

What is Swapp?
How to use Swapp?
- Installation
- Configuring Your Database
- Basic CRUD Operations
Why use Swapp?
Conclusion

What is Swapp?

Swapp is an easy-to-use database abstraction layer for Node.js. It connects to both SQL (like Supabase) and NoSQL (like MongoDB) databases using a simple, unified interface. The beauty of Swapp is that it lets you use a universal query language - think SQL-like queries - across both SQL and NoSQL databases. No more changing the entirety of your code just to switch from a SQL to a NoSQL database (or the other way around).

Here's what Swapp provides you with:

Skip the tedious database setup process.
Write queries in a SQL-like syntax that works across both MongoDB and Supabase (and more databases getting support soon).
Focus on building your app, not on configuring your database.
Enjoy easy-to-understand API calls for CRUD operations.

Basically, it does the heavy-lifting so you don't have to. Just configure Swapp, and then you can start building your app's features immediately. Swapp will take care of setting up the database for you.

How to use Swapp?

Installation

Installing Swapp is really easy. Just download it from npm, and you're set to go!

npm install swapp.js --legacy-peer-deps

yarn add swapp.js

Configuring Your Database

Right now, Swapp supports MongoDB and Supabase. More databases are currently in development.

If you're using MongoDB:

const db = new Swapp({
  provider: 'mongodb',
  config: {
    connectionString: '<mongodb-connection-string>',
    dbName: '<database-name>'
  }
})

In case you use Supabase:

const db = new Swapp({
  provider: 'supabase',
  config: {
    supabaseKey: '<Supabase-Key>',
    supabaseUrl: '<Supabase-URL>'
  }
})

Basic CRUD Operations

Most of the basic CRUD operations work just as expected. For example, to save data to the database:

await db.save('<collection/table name>', {name: "John", age: 25})

Now comes the fun part: the queries. Look at this example:

const data = await db.get('collection/table name', 'WHERE name = "John"')

This searches for entries in the database with name = "John". Classic SQL-like query. The catch? This works seamlessly, whether you're using a SQL database (like Supabase) or a NoSQL one (like MongoDB)!

Similarly, there are functions for db.update() and db.delete() as well. Check out the GitHub repository of Swapp for more detailed documentation.

Why Use Swapp?

If you're still unsure why you should use Swapp when there are so many database packages out there, let me try changing your mind:

Save Time: No more memorizing different query languages for different databases. Swapp lets you focus on building your app, instead of worrying about database setups and queries.
SQL and NoSQL in One Package: Swapp gives you the flexibility to use both SQL and NoSQL databases. If you wanna try out MongoDB for some flexible data storage and then shift to Supabase for a more structured data, Swapp lets you do that easily by changing just a single statement.
Ideal for MVPs and Prototyping: If you're building an MVP or a prototype and don't want to be bogged down by database setup, Swapps lets you just plug in and get started quickly.
Simple, Intuitive API: CRUD operations? Check. Universal queries? Check. But still easy to work with. You won't need to read through pages of documentation to get a simple query running.

Conclusion

Swapp is here to make your life easier. Whether you're new to databases or have been wrangling them for years, this tool can save you a ton of time and effort.

So, why not give it a try? You'll be up and running in minutes, and you can spend your valuable time actually building your app.

Check out the GitHub Repository and leave a star if you found Swapp to be actually helpful in your development workflow. Feel free to leave any feedback and suggestions you may have, I am always open to new ideas.

Let's swap out the complexity and start building!

Create your own Event Scheduling API using Express and Supabase

Amartya Chowdhury — Mon, 04 Nov 2024 15:51:54 +0000

Ever needed a platform to manage your club's events? Or perhaps schedule meetings in your office? But in search of affordable platforms, you get lost in the numerous options presented to you? Or maybe you just want to organize your life better and schedule when you have to attend which events?

Follow this post through the end, and you'll end up with a basic event scheduling API where all basic features like event creation and registration will be available.

The GitHub repository for this project is at https://github.com/xerctia/gatherly

What is Express?

Express is a Javascript framework for setting up and building servers to handle various kinds of requests like GET, POST etc. Express is one of the most popularly used backend frameworks, and is also one of the easiest framework for beginners to start with. In this blog, we will be using Express for making our server and setting up the required endpoints.

What is PostgreSQL?

PostgreSQL is an open-source relational database management system (RDBMS), known for its reliability, scalability, and support for complex queries. It offers advanced features like support for JSON data, full-text search, and extensibility, making it versatile for both small projects and large-scale applications. PostgreSQL is popular among developers and is valued for its robust performance.

There are many PostgreSQL providers available on the web that allow usage of a PostgreSQL database, some free of cost and some with a paid plan. In this project, we will be using Supabase and its database as our PostgreSQL.

Setting up the project

Create a folder for this project. I will name it Gatherly, which is the name I've decided.
Set up Node and npm: npm init -y
Install Express and other required packages: npm install express dotenv cors pg Note: pg is the package used for using PostgreSQL in Node.js.
Now create an index.js file with the following boilerplate code:

const exp = require('express');
const cors = require('cors');

const app = exp();
const PORT = 3000 || process.env.PORT;

app.use(express.json());
app.use(express.urlencoded({extended: true}));
app.use(cors());

app.get("/", (req, res) => {
    res.send("Hello, Gatherly!");
})

app.listen(PORT, () => {
    console.log(`server started on ${PORT}`);
})

Congrats! You have successfully set up a basic server in Express!

Setting up Supabase with your Project

Supabase setup

Go to https://supabase.com and log into or create an account, and then create a new project with any name you see fit. I have named it Gatherly (obviously).
Now go to the project dashboard and then navigate to Project Settings -> Database.
In the starting of the page, a section of "Connection String" will be present. Click the Node.js tab here and copy the connection string and store it somewhere for now.
Now go to the SQL Editor and run the following query to create an 'events' table:

CREATE TABLE events (
  id SERIAL PRIMARY KEY,
  title VARCHAR(255) NOT NULL,
  description TEXT,
  start_time TIMESTAMP NOT NULL,
  end_time TIMESTAMP,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Connecting database to Express

Go to your project folder and create a file named .env. Write DATABASE_URL= and then paste the Connection String you copied earlier (Supabase setup: Step-3) and enclose it within double quotes. For example:

DATABASE_URL="postgresql://username:password@host:port/dbname"

Create another JS file db.js to set up and connect the PostgreSQL database.

const { Pool } = require('pg');
require('dotenv').config();

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  ssl: {
    rejectUnauthorized: false
  }
});

module.exports = pool;

Now lastly, we need to import this connected database to our main index.js file.

const pool = require('./db');

Congratulations, you have successfully connected your Supabase database to your index.js file. We are now ready to start building the actual API endpoints.

API Endpoints

GET /events : Fetch all events

Create a new GET method as follows:

app.get('/events', async (req, res) => {
  // code to be written
})

Inside this function, we will write the actual code that will fetch us the data. First of all, let's implement a try-catch block for better error handling.

try {
  // code to be written
} catch (e) {
  console.error(e);
  res.status(500).json({error: "Database error."}); // 500 = Internal Server Error
}

This format will be maintained for all the endpoints we will be building. Within the try block, we will write the code for the required feature.
To fetch all the events in the database, we need to query the database and store it in a variable. Since we are following an asynchronous approach, so we need to use await to store the data correctly.

const result = await pool.query("SELECT * FROM events");

The output of this query, i.e. result, has an array of objects called 'rows'. Here, we need to return all the events, so we will just return the entire 'rows'.

res.status(200).json(result.rows); // 200 = OK

With this, our first endpoint is ready! To test it out, you can go to the Table Editor at Supabase project's dashboard and add 2 or 3 events for testing purposes. The entire code for this endpoint is:

app.get('/events', async (req, res) => {
    try {
        // Getting all events
        const result = await pool.query("SELECT * FROM events");
        res.status(200).json(result.rows); // 200 = OK
    } catch (e) {
        console.error(e);
        res.status(500).json({error: 'Database error'}); // 500 = Internal Server Error
    }
})

POST /events : Create a new event

First of all, let's set up a basic boilerplate of an endpoint:

app.post("/events", async (req, res) => {
  try {
    // code to be written
  } catch (e) {
    console.error(e);
    res.status(500).json({error: "Failed to create event."}); // 500 = Internal Server Error
  }
})

In this case, as we have some data we need from the user, we can define those outside of the try-catch block.

const { title, description, start_time, end_time } = req.body;
try {
.....

Now within the try block, we need to write the query to insert a row in a table. The query() method lets you denote variable values in the string query as $1, $2 etc. and then provide those variables in order in an array. This will be how we add our variable inputs from user to the query.

const result = await pool.query(
  "INSERT INTO events (title, description, start_time, end_time) VALUES ($1, $2, $3, $4) RETURNING *",
  [title, description, start_time, end_time]
);

Again, like the previous time, we will print the result rows. But this time, we only need to print the first element of the 'rows' array, which will be the row we just inserted.

res.status(201).json(result.rows[0]); // 201 = Resource Created

Hurray, we've built our endpoint to add new events! Here's the entire code:

app.post('/events', async (req, res) => {
    const { title, description, start_time, end_time } = req.body;  // Destructuring the input data

    try {
        // Insert the event details into a new row in the table
        const result = await pool.query(
            'INSERT INTO events (title, description, start_time, end_time) VALUES ($1, $2, $3, $4) RETURNING *',
            [title, description, start_time, end_time]
        );
        res.status(201).json(result.rows[0]); // 201 = Resource Created
    } catch (e) {
        console.error(e);
        res.status(500).json({error: 'Failed to create event.'}); // 500 = Internal Server Error
    }
})

GET /event/:id : Fetch details of an individual event

I'm sure you are clever enough to be able to set up a basic function for any endpoint, so I will not be showing that every time.
Here, our goal is to create a dynamic endpoint, where the value of 'id' will keep changing. So, we've marked it as :id, and we can access its value as follows:

const { id } = req.params;

This can also be done outside the try-catch, just like the input values in the previous endpoint.

Now within the try block, we need to write the query for selecting rows where the 'id' field will be equal to the id provided. If there's no results found, that means the event with this id doesn't exist, so we can return a 404 error.

const result = await pool.query("SELECT * FROM events WHERE id = $1", [id]);
if (result.rows.length === 0) {  // event not found
  return res.status(404).json({error: "Event not found."});
}

If this isn't the case, that means the event exists. But since 'rows' is an array, so even if it contains one element, we need to access it by rows[0]. So the required row is in rows[0].

res.status(200).json(result.rows[0]);

And voila! You can now successfully get a specific event's details! Here's the full code:

app.get('/event/:id', async (req, res) => {
    const { id } = req.params; // Destructuring the URL parameters

    try {
        // Get the current event row
        const result = await pool.query('SELECT * FROM events where id = $1', [id]);
        if (result.rows.length === 0) {  // length 0 means no rows returned, i.e. event isn't found
            res.status(404).json({error: 'No event found.'}); // 404 = Resource Not Found
        } else {
            res.status(200).json(result.rows[0]); // 200 = OK
        }
    } catch (e) {
        console.error(e);
        res.status(500).json({error: 'Database error.'}); // 500 = Internal Server Error
    }
})

User Registration

Supabase

For implementing this feature, you will need to create a new table in Supabase first.

Go to SQL Editor and run the following query:

CREATE TABLE registrations (
  id SERIAL PRIMARY KEY,
  event_id INTEGER NOT NULL,
  name VARCHAR(255) NOT NULL,
  country VARCHAR(100) NOT NULL,
  specialty VARCHAR(255) NOT NULL,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (event_id) REFERENCES events(id) ON DELETE CASCADE
);

POST /event/:id/register

We can take the input values as well as the parameter value outside the try-catch.

const { id } = req.params;
const { name, country, specialty } = req.body;
try {
.....

Now we will first check whether the event with 'id' exists. For this, we will follow the approach of GET /event/:id, and check if rows.length is nonzero, i.e. it has some results.

const event = await pool.query("SELECT * FROM events WHERE id = $1", [id]);
if (event.rows.length === 0) {
  return res.status(404).json({error: "Event not found.'});
}

Now that the event exists, we can write the query for actually adding a registration to the database to the new table we just created, i.e. 'registrations'.

const registration = await pool.query(
  "INSERT INTO registrations (event_id, name, country, specialty) VALUES ($1, $2, $3, $4) RETURNING *",
  [id, name, country, specialty]
);
res.status(201).json({msg: "Registration successful!", result: registration.rows[0]);

Thus we have implemented a feature for registering users for an event as well! Here's the entire code:

app.post('/event/:id/register', async (req, res) => {
    const {id} = req.params;  // Destructuring URL parameters
    const {name, dept, college, country, laptop} = req.body;  // Destructuring input data

    try {
        // Checking if event exists
        const event = await pool.query('SELECT * FROM events where id = $1', [id]);
        if (event.rows.length === 0) {  // length 0 means no rows returned, i.e. event isn't found
            return res.status(404).json({error: 'Event not found.'}); // 404 = Resource Not Found
        }

        // Insert new row for new registration
        const registration = await pool.query(
            'INSERT INTO registrations (event_id, name, dept, college, country, laptop) VALUES ($1, $2, $3, $4, $5, $6) RETURNING *',
            [id, name, dept, college, country, laptop]
        )

        res.status(201).json({msg: 'Registration successful!', result: registration.rows[0]}); // 201 = Resource Created
    } catch (e)
        console.error(e);
        res.status(500).json({error: 'Failed to register for event.'}); // 500 = Internal Server Error
    }
})

GET /event/:id/registrations : Fetch all registrations for a given event

This one is a homework for you guys. (Don't be mad, if you couldn't do it even after trying, the GitHub code is always available)
A hint: You may check if the event exists in the same way as we did in POST /event/:id/register. After that, you need to write a SELECT query for registrations table to fetch all rows with the given event_id.

Similarly, you may also try and build an endpoint for deleting a particular event, like DELETE /event/:id .

Wrapping Up

Congratulations! You have successfully created your own API for scheduling events and managing user registrations. You have come a long way.

You can add more features, like adding a cron job so that events whose end_time have passed are deleted automatically.

If you liked this post, drop a like, and comment if you have any doubts or just want to chat related to this. Also follow me on LinkedIn: https://www.linkedin.com/in/amartya-chowdhury/

DEV Community: Amartya Chowdhury

Demystifying QR Codes

Phase 1: Encoding text into bytes

Phase 2: The Math (and correcting errors)

Multiplication in GF(2^8)

Fast way: Log and Antilog Tables

Error Correction Levels

Generating Error Correction Bytes (Reed Solomon Codes)

Phase 3: Masks and Format String

Choosing a mask: Penalty Rules

Format String

Implementing Everything: The Battle Wounds I Have

Benchmarks

What I Left Out

Next Steps

Like me?

You Don't Have to Grind LeetCode

Are you inconsistent, no matter how hard you try?

No LeetCode? Then what?

So, is LeetCode (or any problem solving) useless?

Conclusion?

Building Profig - A Config Framework

What is Profig?

Features

Usage

Sample Config

Documentation Generation

🛠 Tech Dive

Final Notes

Building Profig - A Config Framework

What is Profig?

Features

Usage

Sample Config

Documentation Generation

🛠 Tech Dive

Final Notes

I Got Tired of Repeating the Same Commands, so I Built Jido - a Workflow Automation CLI

What is Jido?

The Config File

Plugins

Now, Where Do You Use Jido?

So, What Do You Think?

⚒ The Hidden Complexity Of Routing: Why Your Requests Take Longer Than They Should

😮‍💨 The Normal Approach

🚀 The Better Approach

🔥 The Even Better Approach

So What's The Takeaway?

⚡ Tired of DB Setups? Meet Swapp: The Universal DB Adapter

Table Of Contents

What is Swapp?

How to use Swapp?

Installation

Configuring Your Database

Basic CRUD Operations

Why Use Swapp?

Conclusion

Create your own Event Scheduling API using Express and Supabase

What is Express?

What is PostgreSQL?

Setting up the project

Setting up Supabase with your Project

Supabase setup

Connecting database to Express

API Endpoints

GET /events : Fetch all events

POST /events : Create a new event

GET /event/:id : Fetch details of an individual event

User Registration

Supabase

POST /event/:id/register

GET /event/:id/registrations : Fetch all registrations for a given event

Wrapping Up