DEV Community: Amartya Chowdhury

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

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