DEV Community: Gaurav Kumar

How to Pick the Perfect Database Without Losing Your Mind

Gaurav Kumar — Mon, 08 Jun 2026 07:42:26 +0000

Hey fellow dev — let's tackle the choice that keeps us up at night: which database should you use?

I've boiled down the major database archetypes into a practical field guide so you can make the right call for your next project or system design interview. For each archetype you'll get: a real-world example, core characteristics, pros/cons, common pitfalls, and concrete product examples.

Before You Even Look at a Database, Answer These 6 Questions

Every database choice I've made that turned out well started here. Every bad choice skipped at least one of these.

What shape is your data? Rows and columns with fixed fields? Nested JSON documents? Nodes and edges? Timestamped measurements?
How stable is your schema? If your fields change often between records, you'll hate rigid relational schemas. If they're locked in, schema flexibility is a non-issue.
How complex are your relationships? Do entities reference each other heavily? Many-to-many? Deep traversals? This is where most teams underestimate.
What are your query patterns? Short key lookups vs. aggregations vs. full-text vs. joins — these push you toward completely different architectures.
What's the expected scale? A single-region app serving 10K users is a different problem from global OLTP at 1M writes/sec.
Who is operating this thing? The best database for your use case is the one your team can actually run well. Don't adopt Cassandra if no one on your team has operated it.

Quick thumb rule

If...	Start with...
ACID + complex relationships	Relational DB
Flexible schema + hierarchical documents	Document DB
Extreme low-latency key lookups	Key–Value store
Graph traversals	Graph DB
High-cardinality time series	Time-Series DB

Relational Databases (RDBMS) — The Reliable Workhorse

RDBMS is the foundational technology for systems where data consistency, reliability, and complex relationships are critical. Because they're designed to be highly structured and secure, they're the industry standard for any application where "getting the data right" matters more than raw speed.

Characteristics

Structured rows and columns with a defined schema
Strong ACID guarantees for transactions
Powerful SQL for joins, aggregation, and complex queries
Mature tooling for backups, migrations, and analytics

Pros

Battle-tested for correctness and consistency
Great for normalized data and multi-table transactions
Rich ecosystem (ORMs, monitoring, tooling)

Cons

Schema migrations can be painful at large scale
Joins across huge tables can be slow without careful indexing
Vertical scaling limits unless you adopt sharding or distributed SQL

Examples: PostgreSQL, MySQL, Microsoft SQL Server

Who uses them: Core transactional systems at Shopify, payment systems, most SaaS apps

Common pitfalls

Over-normalizing for read-heavy workloads — optimize with materialized views or read replicas
Ignoring indexing and query plans; assuming indexes are "free"

Document Databases — The Flexible Multi-Tool

Document databases shine when your data requirements are evolving rapidly or too varied to fit neatly into a rigid table schema. They're the go-to for modern, agile development — think CMS or user profiles where each record may have different fields.

Characteristics

Schema-flexible JSON-like documents (nested structures welcome)
Queryable fields and secondary indexes; supports partial updates
Good balance between flexible modeling and querying capability

Pros

Evolve your data model quickly without rigid migrations
Excellent for denormalized data and aggregations that map to document shapes
Often easier to scale horizontally than single-instance RDBMS

Cons

Complex joins are either unsupported or expensive (application-level)
Risk of inconsistent schemas and duplicated data if not managed
Transactions historically limited (though many modern engines now support them)

Examples: MongoDB, Couchbase, Amazon DocumentDB

Who uses them: Content systems, user profile stores, product catalogs

Common pitfalls

Modeling relational semantics as documents without a strategy — leads to data redundancy and maintenance headaches
Uncontrolled document growth (oversized documents, deeply nested arrays) hurts performance

Key–Value Stores — The Blazing-Fast Lookup

Think of these as a giant, super-organized dictionary where you can grab any piece of information instantly by its unique key. The go-to choice for session management and caching.

Characteristics

Simple API: store and retrieve by primary key
Extremely low-latency reads and writes
Minimal structure — values are opaque blobs to the store

Pros

Excellent performance at scale; trivially sharded
Simple to reason about and operate

Cons

Limited querying (no secondary indexes or complex queries)
Application must handle consistency and indexing logic

Examples: Redis, Amazon DynamoDB (used as KV), Memcached

Common pitfalls

Using KV where you actually need complex queries or relationships
Treating cache as primary storage without durable persistence or correct eviction handling

Column-Family (Wide-Column) Stores — The High-Throughput Workhorse

Unlike standard systems that store data row by row, these databases organize information by columns — enabling specific data points to be read and written at incredible speeds. Ideal for massive workloads like IoT telemetry, web logs, or real-time user activity feeds.

Characteristics

Data modeled as rows with many sparse columns grouped into families
Optimized for write-heavy workloads and large-scale partitioning
Tunable consistency and compaction strategies

Pros

High write throughput, designed for horizontal scale
Efficient for queries reading contiguous ranges or specific columns

Cons

Query flexibility is lower than relational databases
Requires careful data modeling to avoid hot partitions

Examples: Apache Cassandra, ScyllaDB, HBase

Common pitfalls

Poor partition key choices causing hotspotting and degraded performance
Trying to support ad-hoc analytics without ETL into an analytics store

Graph Databases — The Relationship Specialists

Graph databases store data as a network of nodes (entities) and edges (relationships). By treating connections as first-class citizens, they allow high-performance traversal of complex data paths without the heavy cost of JOIN operations.

Characteristics

Native representation of nodes and edges with rich traversal capabilities
Efficient for deep, variable-length relationship queries
Query languages: Cypher, Gremlin, or GQL-like syntaxes

Pros

Expressive for relationship-heavy domains; traversals are fast
Intuitive modeling for networks and hierarchies

Cons

Not ideal for wide analytical queries or massive ad-hoc aggregations
Scaling can be more complex than key-value or column stores

Examples: Neo4j, Amazon Neptune, JanusGraph

Common pitfalls

Modeling everything as a graph when simpler data models suffice
Ignoring traversal complexity — performance degrades with high-degree nodes

Time-Series Databases — Optimized for Temporal Data

Purpose-built to store and query data points indexed by time — sensor readings, server logs, stock market fluctuations. Essential for applications where tracking trends and anomalies over time is critical.

Characteristics

Time is a first-class citizen (efficient append, retention, downsampling)
Built-in functions for aggregations over windows and rate calculations
Often compact storage and compression for high-ingest workloads

Pros

Excellent for metric retention, querying recent data, and rollups
Features like retention policies and continuous aggregations

Cons

Not a general-purpose store for arbitrary relational data
May need separate systems for long-term archival or complex joins

Examples: InfluxDB, TimescaleDB (Postgres extension), Prometheus

Common pitfalls

Using a TSDB for non-temporal data
Trying to join TSDB data with relational transactional data without ETL

Search Engines / Full-Text Stores — The Queryable Text Engine

These systems excel at ranking results by relevance and handling typos through fuzzy matching. The industry standard for powering site-wide search bars, log analysis tools, and document discovery.

Characteristics

Inverted indexes optimized for text search and relevance ranking
Support for filters, facets, and near-real-time indexing
Powerful query DSLs for scoring and boosting

Pros

Great for full-text search, autocomplete, and ranked results
Can support analytics over indexed fields

Cons

Not designed as a source-of-truth transactional database
Indexing lag and eventual consistency between primary store and index

Examples: Elasticsearch, OpenSearch, Algolia

Common pitfalls

Treating the search index as the primary data store (data loss risk)
Forgetting to reindex when source data schema or semantics change

NewSQL / Distributed SQL — SQL with Scale

NewSQL databases offer both strict ACID consistency and massive horizontal scalability. They automate data distribution across cloud clusters, removing the need for manual sharding while maintaining a standard SQL interface.

Characteristics

SQL and ACID semantics combined with distributed architecture
Built-in sharding/replication to scale reads and writes

Pros

Familiar SQL model with modern horizontal scaling
Often simpler to operate than hand-sharded RDBMS clusters

Cons

Complexity and operational costs may still be higher than single-node RDBMS
Some trade-offs in latency or consistency depending on config

Examples: CockroachDB, Google Spanner, YugabyteDB

Common pitfalls

Expecting the same latency characteristics as a single-machine RDBMS
Underestimating the operational model (geo-partitioning, transaction latency)

Multi-Model Databases — One Engine, Multiple Models

Versatile platforms built to handle multiple data structures — documents, graphs, relational tables — within a single unified engine. Instead of managing separate databases for different data types, you store and query varied structures using one consistent API.

Characteristics

Support for two or more data models within one engine
Aims to reduce polyglot persistence complexity

Pros

Use the right model for each feature without managing multiple systems
Simplified operational footprint

Cons

Each model may not be best-in-class; vendor lock-in risk
Complexity in modeling and backups across models

Examples: ArangoDB, Azure Cosmos DB

Common pitfalls

Believing multi-model removes the need for careful modeling and performance testing

Vector Databases — The AI-Powered Semantic Engine

AI models convert text, images, or audio into vectors, and these databases find the most similar vectors using semantic meaning rather than exact keyword matches. The backbone of modern RAG pipelines and AI-powered search.

Characteristics

Stores high-dimensional vectors (embeddings) generated by ML models
Optimized for similarity search (Approximate Nearest Neighbor — ANN)
Supports hybrid search (metadata filtering + vector similarity)

Pros

Highly efficient at finding semantically similar items at scale
Enables advanced AI use cases like LLM memory and RAG
Flexible support for various distance metrics (cosine, L2, inner product)

Cons

High memory footprint; vector indexes (like HNSW) can be RAM-intensive
Query results are probabilistic (approximate), not deterministic
Requires a pipeline to generate and sync embeddings from source data

Examples: Pinecone, Milvus, Weaviate, Qdrant, pgvector (PostgreSQL extension)

Who uses them: AI startups, platforms building generative AI features, search infrastructure teams

Common pitfalls

Storing massive raw data in the vector DB — use it for embeddings, store raw data in a traditional DB
Ignoring embedding staleness when source content changes
Choosing the wrong distance metric or index parameters, leading to poor recall/precision

How I Choose: Practical Heuristics

Start with the shape of your data and queries:

Heavily relational and transactional → RDBMS or Distributed SQL
Document-like, evolving schema → Document DB
Extreme single-key performance → Key–Value store
Traversals and relationships are core → Graph DB
Metric/time-based workload → Time-Series DB

Then apply these filters:

Prioritize correctness first for money/health/safety systems (ACID > scale). You can scale later.
Consider operational burden: prefer familiar tools unless scale demands otherwise.
Prototype the hot paths: build and load-test a minimal model of your expected queries and traffic.
Plan for backups, migrations, and observability from day one.

Quick Reference: Decision Table

Database Type	Best Used For	Example Use Cases	Popular Options
Relational (SQL)	Structured data with relationships & transactions	Banking, E-commerce orders, ERP, CRM	PostgreSQL, MySQL, SQL Server
Document	Flexible, schema-less JSON data	CMS, Product catalogs, User profiles	MongoDB, Couchbase
Key-Value	Ultra-fast reads and writes	Caching, Sessions, Rate limiting	Redis, DynamoDB
Vector	Semantic search using AI embeddings	RAG, AI chatbots, Recommendations	Pinecone, Weaviate, Milvus
Graph	Highly connected data and relationships	Social networks, Fraud detection, Knowledge graphs	Neo4j, Amazon Neptune
Time-Series	Data that changes over time	Monitoring, IoT sensors, Stock data	InfluxDB, TimescaleDB
Search	Full-text search and analytics	Log analysis, Search engines, Observability	Elasticsearch, OpenSearch
Columnar	Analytical workloads and large-scale reporting	Data warehouses, BI dashboards	ClickHouse, Snowflake

Quick Design Patterns

Read-heavy with complex joins → RDBMS + read replicas or materialized views
Flexible user data + frequent reads → Document DB with controlled denormalization
High ingest telemetry → TSDB or column-family store with downsampling pipeline
Low-latency session/cache → Redis or managed in-memory KV
Search plus data store → Primary store (RDBMS/DocDB) + search index (Elasticsearch) with a sync strategy

Originally published on gauravbytes.dev

The 5 Cron Jobs That Save Backend Servers From Disaster

Gaurav Kumar — Wed, 20 May 2026 07:34:11 +0000

Small background jobs that quietly prevent big production incidents.

Most backend systems don’t fail because of massive traffic spikes or complex bugs. They fail quietly.

A database backup stops running.
Logs slowly consume all available disk space.
A background job fails and never retries.
Temporary files pile up until the server starts behaving unpredictably.

And the worst part?

Most of these problems are preventable.

That’s where cron jobs come in. They are the silent automations running behind the scenes that keep production systems healthy, stable, and resilient.

In this article, we’ll look at 5 cron jobs that every backend server should have.

1. Automated Backups

Regularly backing up your data is non-negotiable. This is one of the most important cron jobs any backend system can run.

Production incidents rarely happen because someone intentionally breaks the database. Most failures come from small mistakes — accidental deletes, bad deployments, corrupted migrations, or infrastructure issues.

An automated backup job ensures there is always a recent recovery point available.

2. Log Cleanup

Logs are useful — until they silently consume your entire server storage.

Every backend service generates logs:

API logs
error logs
access logs
worker logs

Over time, these files grow much larger than expected. If left unmanaged, they can fill disk space and crash applications unexpectedly.

A log cleanup cron job automatically deletes or compresses old logs before they become a problem.

3. Server Health Checks

Servers rarely warn you before failing. Usually, they fail first and alert later.

A health monitoring cron job continuously checks:

CPU usage
memory usage
disk utilization
service uptime
queue backlog

If something looks unhealthy, alerts can be sent before users notice issues.

4. Cache Cleanup

Backend systems generate a surprising amount of temporary data.

Cached responses, temporary uploads, processing artifacts, and stale files slowly accumulate in the background. Most teams forget about them until storage suddenly becomes an issue.

A cleanup cron job ensures temporary data doesn’t become permanent clutter.

5. Retry Failed Jobs

Not every task succeeds on the first attempt.

External APIs timeout.
Webhooks fail.
Email providers temporarily go down.
Payment services become unreachable.

Without a retry mechanism, those failures often turn into lost data or broken workflows.

A retry cron job periodically reprocesses failed tasks and gives the system another chance to complete them successfully.

Final Thoughts

Cron jobs are easy to overlook because they run quietly in the background.

But in production systems, these small automations often make the difference between:

a stable server
and a late-night production incident

Most backend disasters don’t happen because of complex architecture problems.

They happen because basic operational tasks were never automated.

And these 5 cron jobs help prevent exactly that.

Build a Secure PostgreSQL AI Agent with LangChain + Ollama

Gaurav Kumar — Tue, 12 May 2026 04:30:00 +0000

🚀 Introduction

Imagine asking your database:

“Show me the top 10 customers by revenue.”

…and instantly getting results without writing a single SQL query.

That’s exactly what an AI-powered database agent can do.

In this tutorial, we’ll build a secure PostgreSQL AI Agent using:

🧩 LangChain for agent orchestration
🦙 Ollama for running local LLMs
🐘 PostgreSQL as the database
🛡️ A custom SQL safety layer to block destructive queries

By the end, you’ll have a local AI assistant capable of converting natural language into SQL queries safely and efficiently.

💻 Source Code:
postgres-agent GitHub Repository

🤖 What is a PostgreSQL AI Agent?

A PostgreSQL AI Agent is essentially an LLM-powered assistant that can:

Understand natural language
Generate SQL queries
Execute them against PostgreSQL
Return readable results

Think of it like ChatGPT connected to your database — but with guardrails and controlled execution.

⚙️ Tech Stack

Tool	Purpose
LangChain	Agent orchestration and tool calling
Ollama	Run LLMs locally without API costs
langchain-ollama	LangChain integration for Ollama
psycopg2	PostgreSQL adapter for Python
Python	Core application runtime

🧱 System Architecture

🔌 Step 1: Connect to PostgreSQL

We’ll start by creating a PostgreSQL connection using psycopg2.

import psycopg2

DB_CONFIG = {
    "host": "localhost",
    "port": 5432,
    "database": "postgres",
    "user": "postgres",
    "password": "root",
}

def get_connection():
    return psycopg2.connect(**DB_CONFIG)

🔐 Production Tip:
Never hardcode credentials in production. Use environment variables or a secret manager.

🛠️ Step 2: Create LangChain Tools

LangChain agents interact with systems using tools.

These tools expose safe and structured database operations to the LLM.

📋 Tool: List Database Tables

@tool
def list_tables() -> str:
    """List all tables in the database."""
    conn = get_connection()
    try:
        cur = conn.cursor()
        cur.execute("""
            SELECT table_name FROM information_schema.tables
            WHERE table_schema = 'public'
        """)
        tables = [row[0] for row in cur.fetchall()]
        return f"Tables: {', '.join(tables)}" if tables else "No tables found."
    finally:
        conn.close()

This gives the agent dynamic schema awareness instead of relying on hardcoded table names.

📑 Tool: Fetch Table Schema

@tool
def get_table_schema(table_name: str) -> str:
    """Get the schema (columns and types) of a specific table."""
    conn = get_connection()
    try:
        cur = conn.cursor()
        cur.execute("""
            SELECT column_name, data_type, is_nullable
            FROM information_schema.columns
            WHERE table_schema = 'public' AND table_name = %s
            ORDER BY ordinal_position
        """, (table_name,))
        columns = cur.fetchall()

        if not columns:
            return f"Table '{table_name}' not found."

        schema = "\n".join([
            f"  {col[0]} ({col[1]}, nullable={col[2]})"
            for col in columns
        ])

        return f"Schema for '{table_name}':\n{schema}"
    finally:
        conn.close()

This helps the LLM understand:

Column names
Data types
Nullability
Table structure

⚡ Tool: Execute SQL Queries

@tool
def execute_sql(query: str) -> str:
    """Execute a SQL query against the PostgreSQL database and return results. Use this for SELECT queries."""

    is_safe, reason = validate_read_only_sql(query)

    if not is_safe:
        return f"Safety Guard: Blocked query. {reason}"

    conn = get_connection()

    try:
        cur = conn.cursor()
        cur.execute(query)

        if cur.description:
            columns = [desc[0] for desc in cur.description]
            rows = cur.fetchall()

            if not rows:
                return "Query returned no results."

            result = " | ".join(columns) + "\n"
            result += "\n".join([
                " | ".join(str(v) for v in row)
                for row in rows[:50]
            ])

            if len(rows) > 50:
                result += f"\n... ({len(rows)} total rows)"

            return result
        else:
            conn.commit()
            return f"Query executed successfully. Rows affected: {cur.rowcount}"

    except Exception as e:
        conn.rollback()
        return f"SQL Error: {e}"

    finally:
        conn.close()

This becomes the core execution engine of the AI agent.

🛡️ Step 3: Add a SQL Safety Guard

Allowing an LLM to execute unrestricted SQL is dangerous.

That’s why every query should pass through a validation layer before execution.

✅ Allowed vs Blocked Queries

Allowed	Blocked
`SELECT`	`INSERT`
`WITH`	`UPDATE`
`SHOW`	`DELETE`
`EXPLAIN`	`DROP`
—	`ALTER`
—	`TRUNCATE`

🧼 Query Normalization

Before validation, we sanitize queries by removing:

Comments
Hidden injections
String-based bypass attempts

This significantly improves safety when working with LLM-generated SQL.

🧠 Step 4: Setup Ollama for Local LLMs

Ollama makes it incredibly easy to run large language models locally.

No OpenAI API.
No usage limits.
No cloud dependency.

Useful links:

🔽 Pull the Model

ollama pull qwen2.5:7b

Verify installation:

ollama list

🧩 Recommended Models for SQL Agents

Model	Command	Notes
Qwen 2.5 7B	`ollama pull qwen2.5:7b`	Used in this tutorial
Llama 3.1 8B	`ollama pull llama3.1`	Strong general-purpose model
DeepSeek-R1 7B	`ollama pull deepseek-r1`	Excellent reasoning
Mistral 7B	`ollama pull mistral`	Lightweight and fast

📦 Install LangChain Ollama Integration

pip install langchain-ollama

References:

⚙️ Configure ChatOllama

from langchain_ollama import ChatOllama

llm = ChatOllama(
    model="qwen2.5:7b",
    temperature=0
)

Setting temperature=0 helps generate more deterministic and reliable SQL queries.

Why Use Ollama?

✅ Completely local execution
✅ No API cost
✅ Privacy-friendly
✅ GPU acceleration support
✅ Supports many open-source models

🔗 Step 5: Create the LangChain Agent

tools = [list_tables, get_table_schema, execute_sql]

agent = create_agent(llm, tools)

LangChain enables the AI agent to:

Select tools dynamically
Chain multiple operations
Reason step-by-step
Generate context-aware SQL

💬 Step 6: Create an Interactive Chat Loop

while True:
    user_input = input("\nYou: ").strip()

    if user_input.lower() in ("exit", "quit"):
        print("Goodbye!")
        break

    if not user_input:
        continue

This turns the application into a conversational SQL assistant.

🧾 Step 7: Add Debugging & Observability

Debugging AI agents becomes much easier when you can inspect tool calls and outputs.

def print_turn_details(messages: list[BaseMessage]) -> None:
    final_response = ""

    for message in messages:
        if isinstance(message, AIMessage):

            for tool_call in message.tool_calls:
                tool_name = tool_call.get("name", "unknown_tool")
                tool_args = format_tool_payload(
                    tool_call.get("args", {})
                )

                print(f"\nTool call: {tool_name}({tool_args})")

            content = format_content(message.content).strip()

            if content:
                final_response = content

        elif isinstance(message, ToolMessage):
            tool_name = getattr(message, "name", None) or "tool"

            tool_output = (
                format_content(message.content).strip()
                or "(no output)"
            )

            print(f"\nTool response [{tool_name}]: {tool_output}")

    if final_response:
        print(f"\nAgent: {final_response}")
    else:
        print("\nAgent: I couldn't generate a response.")

This helps you inspect:

Tool invocations
Tool outputs
Agent reasoning flow
Final responses

🧪 Example Queries

Try prompts like:

"List all tables"
"Show schema of users table"
"Get top 5 users by revenue"
"How many orders were placed last month?"

🌍 Real-World Use Cases

This architecture can be extended into real production systems.

📊 AI Analytics Dashboards

Allow non-technical users to query business data using plain English.

💬 Internal Data Chatbots

Integrate with Slack or Teams for self-serve analytics.

🧾 Automated Reporting

Generate recurring reports automatically using natural language prompts.

🏢 SaaS Admin Tools

Provide operations teams with an AI-powered database interface.

🤖 AI Copilots for Analysts

Speed up SQL generation and analytics workflows.

🎯 Final Thoughts

You’ve now built a secure and extensible PostgreSQL AI Agent powered by LangChain and Ollama.

The biggest takeaway here is that tool-based AI architecture gives LLMs structured access to databases without exposing unrestricted control.

Key Learnings

LangChain simplifies AI agent orchestration
Ollama enables local LLM execution
SQL validation is essential for security
Tool-driven agents are highly extensible

With a few additional improvements like authentication, query caching, and semantic memory, this can evolve into a powerful production-grade AI data assistant.

📦 Full Working Source Code:
postgres-agent GitHub Repository

The Day I Stopped Building Alone: OpenClaw as My Virtual Team

Gaurav Kumar — Thu, 26 Mar 2026 04:00:00 +0000

Building a SaaS product solo means you're never just a developer. You're the researcher, the architect, the QA engineer, the SEO specialist — and somewhere in between all that, you're supposed to actually write code.

That was my reality while building ShiftMailer, my AI-powered email marketing product. Constant context-switching. Constant skill gaps. Constant exhaustion.

Then I started using OpenClaw — an AI agent framework that doesn't just chat, but actually does things: reads files, runs commands, searches the web, analyzes code, and coordinates with other tools.

Here's the short version of what I learned:

What works really well

Research: Instead of spending hours comparing tools or validating ideas, I delegate it. OpenClaw synthesizes, not just searches.
Code amplification: I'm a backend engineer — I don't need AI to replace me, I need it to handle the repetitive stuff so I can focus on the interesting parts. That's exactly what it does.
Unexpected wins: It analyzed my site's SEO and gave me specific, implementable suggestions. Not generic advice — actual recommendations based on my content.

What doesn't (yet)

Orchestration: Complex multi-step workflows can get messy. I'm still the conductor — the agent executes well, but I keep the orchestra in sync.
Security: When an agent has access to your files and environment, "trust but verify" isn't optional. Review code before shipping. Keep sensitive configs isolated.

The honest comparison

AI agents aren't cofounders. A cofounder brings human judgment, equity, and fixed skills. An AI agent brings on-demand skills, zero scheduling overhead, and no sleep requirements — but needs oversight on the hard calls.

The gap between "idea" and "working product" has shrunk dramatically for me. ShiftMailer exists today because I stopped trying to do everything myself.

If you want the full story — including the detailed breakdown of workflows, a cofounder comparison table, and what I'm still figuring out — read the complete article on Hashnode.

Originally published at gauravbytes.hashnode.dev