In this post, I’ll walk you through how Lovable turns natural language prompts into production-ready full-stack applications using Supabase as the infrastructure backbone. If you're building MVPs, this workflow changes everything.

The Setup: Connecting Lovable to Supabase

Lovable connects directly to your Supabase project using the project reference and API keys. You don’t need to manually configure database URLs, credentials, or CLI tools. Once connected, every schema change, edge function, and Row Level Security (RLS) policy is automatically deployed through Supabase's CLI, keeping your environment in sync as your app evolves. You can find the option to connect on the top right in lovable as shown in the image.

Designing the Database with Just a Prompt

When you describe a feature, Lovable analyzes the underlying data needs and creates the necessary schema. It builds tables with proper relationships, sets up RLS policies, and even adds performance-enhancing indexes and foreign key constraints. All of this happens through natural language-to-SQL conversion, eliminating the need to write a single line of database code. Lovable asks you to review the Sql and then executes after your approval which is a great feature.

What stands out is how it applies Row Level Security (RLS) policies by default. Many developers skip this in early stages and expose sensitive data. Lovable ensures that doesn’t happen.

Writing and Deploying Edge Functions

If your app needs custom API logic, say uploading PDFs or triggering AI models, Lovable generates Supabase Edge Functions written in TypeScript. These are production-grade by default: they include proper CORS headers, error handling, and secrets management.

Within seconds, they’re deployed globally on Supabase’s edge network, ready to serve requests.

Here’s an example of an edge function generated by lovable in supabase

As the database evolves, Lovable syncs the types across your frontend and backend using TypeScript. This means you can rely on compile-time safety rather than chasing runtime bugs. Changes to your schema are reflected instantly in your React components, ensuring both consistency and developer confidence.

Adding Vector Search and AI in One Step

In this project, a PDF-based AI chatbot, Lovable blew me away.

When I mentioned “AI chatbot” in the prompt, it automatically enabled the pgvector extension, created embedding columns, and hooked it up with OpenAI's embeddings API. It even created similarity search functions and integrated them into the app logic. The image below shows the table with vector embeddings stored.

This level of abstraction makes advanced AI features accessible.

Making Smart Architectural Choices

Lovable doesn't just generate code, it understands when and why to make specific architectural decisions. For instance, it knows when to move logic to edge functions vs keeping it on the client. It structures your database thoughtfully, avoids redundant queries, and chooses performant indexes based on your use case.

File uploads? It sets up Supabase Storage buckets, defines the right access rules, and configures CDN delivery without you needing to touch a dashboard.

Lovable also takes care of integrating external services from OpenAI to Stripe and Twilio. I does things like secret management, auth flow handling, error retries, and rate limiting strategies for you. You don’t just get the integration, you get a maintainable implementation that’s ready to scale.

Conclusion

Lovable + Supabase changes how MVPs are built. Instead of stitching together backend, auth, storage, and APIs, you describe your idea, and get a working app, fast.

For founders and small teams, it means faster launches, fewer distractions, and more time to validate what matters. If you’ve been stuck on setup, maybe all you need is the right prompt.

RAG stands for Retrieval-Augmented Generation.

Instead of hoping your LLM (Large Language Model) remembers everything, RAG retrieves the most relevant information in real-time and feeds that context into the model to generate an accurate response.

Think of it as combining search + AI, a Google-like brain with human-like understanding.

Here’s how I built a simple chat with pdf app using Lovable and Supabase.

The Architecture

Here’s the tech stack I used:

• Frontend: React (with a streaming chat interface)

• Backend: Supabase Edge Functions (powered by Deno)

• Database: PostgreSQL with pgvector

• AI: OpenAI Embeddings + GPT-4o-mini

The entire system works in three stages:

1. Ingest

2. Store

3. Retrieve

Let’s walk through each of them.

Stage 1: Document Processing

Whenever a user uploads a PDF:

1. I extract the text using any text extraction package.

2. Then, I split that text into manageable chunks, around 500 characters per chunk.

3. Finally, I generate embeddings for each chunk.

What are embeddings?

Embeddings convert text into a vector of numbers that represent its meaning. This lets the system measure similarity between chunks of text, even if they use different words.

I use OpenAI’s Embedding API for this step. It’s simple, fast, and highly accurate.

Stage 2: Storing Embeddings

This is where pgvector comes in.

Supabase supports the pgvector extension, which allows you to store and search high-dimensional vectors right inside your PostgreSQL database.

Each text chunk and its corresponding embedding are stored as a row in the database. This gives you full control over your knowledge base, and there’s no need for external vector DBs.

Stage 3: Smart Retrieval

Now the fun part, asking questions and getting smart answers.

Here’s what happens when a user asks a question:

1. The question is converted into an embedding.

2. A vector similarity search is run on the database.

3. The top 5 most relevant chunks are retrieved.

4. These chunks are sent as context to the LLM.

Stage 4: Response Generation

The retrieved chunks are merged into a single context string.

That context, along with the user’s original question, is sent to GPT-4o-mini.

The response is streamed back to the frontend in real time, creating a smooth, chat-like experience.

Why This Setup Works

• No fine-tuning required — it adapts to any document.

• Highly accurate — thanks to embedding-based context.

• Real-time streaming — fast responses, no waiting.

• Scalable and cheap — built on Supabase + OpenAI.

• Prompt-powered — easy to evolve using Lovable.dev.

The Result

What you get is a RAG system that:

• Understands your documents deeply.

• Answers questions using real, relevant context.

• Streams responses instantly.

• Scales effortlessly.

• Costs pennies per query.

I’ll soon be sharing a follow-up on how you can do all of this using just prompts with Lovable.dev and Supabase, no complex backend required.

Subscribe to newsletter so that you don’t miss it!

MCP is a protocol which standardizes how applications provide context to LLMs. MCP basically allows us to give our LLMs access to various external systems.

Imagine you're building a web application with Supabase as your database. When you need to create tables or run migrations, let’s say you asked an LLM to generate the SQL, then manually executed it.

But what if the LLM could run those migrations for you?

That’s where MCP comes in! With AI tools that support MCP—like Cursor, Windsurf, and Claude Desktop—you can let the LLM interact with your systems directly.

MCP Architecture

MCP follows a client-server architecture with four key components:

• Hosts – AI tools like Cursor, Claude, etc.

• Clients – Applications that stay connected to MCP servers via hosts.

• MCP Servers – Provide context to clients by linking to data sources or external services.

• Data Sources – The actual databases, or remote services that MCP servers interact with.

How to use MCP

Let’s take cursor as an example. You can find an MCP section in cursor settings where you can add your MCP. For supabase, you can just add an MCP server by passing the CLI command npx -y @modelcontextprotocol/server-postgres <connection-string> . You can read more about this here

Now you can ask the cursor chat to query your db or run any migrations in your supabase project and it does it for you.

How to build an MCP server

We’ve seen how to use an MCP server in tools like cursor but do we build one? There are SDKs for building MCP clients and servers in various programming languages like Python, Typescript etc. Let’s use the Typescript SDK in order to build a weather forecast MCP. This is the same example provided in modelcontextprotocol.io for building an MCP server. I’ll try to simplify it here.

Setting Up the Project

First, ensure you have Node.js and npm installed. Then, create a project directory and install the necessary dependencies:. modelcontextprotocol/sdk is the typescript SDK which I was talking about earlier and zod is used for schema validation in typescript.

mkdir weather
cd weather
npm init -y
npm install @modelcontextprotocol/sdk zod
npm install -D @types/node typescript

Configuring the Project

Add the following to your package.json . Adding "type": "module" means that Node.js will treat your JavaScript files as ECMAScript Modules (ESM) instead of CommonJS (CJS). This helps us in using modern ES module syntax like import/export in our code. The “build” script is to build our project at the end.

"type": "module",
"scripts": {
    "build": "tsc && chmod 755 build/index.js"
 }

Create a tsconfig.json and paste the following. This file configures TypeScript compilation settings:

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "Node16",
    "moduleResolution": "Node16",
    "outDir": "./build",
    "rootDir": "./src",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules"]
}

Now add this code in src/index.ts

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const NWS_API_BASE = "https://api.weather.gov";
const USER_AGENT = "weather-app/1.0";

// Create server instance
const server = new McpServer({
  name: "weather",
  version: "1.0.0",
});

// Helper function for making NWS API requests
async function makeNWSRequest<T>(url: string): Promise<T | null> {
    const headers = {
      "User-Agent": USER_AGENT,
      Accept: "application/geo+json",
    };

    try {
      const response = await fetch(url, { headers });
      if (!response.ok) {
        throw new Error(`HTTP error! status: ${response.status}`);
      }
      return (await response.json()) as T;
    } catch (error) {
      console.error("Error making NWS request:", error);
      return null;
    }
  }

  interface AlertFeature {
    properties: {
      event?: string;
      areaDesc?: string;
      severity?: string;
      status?: string;
      headline?: string;
    };
  }

  // Format alert data
  function formatAlert(feature: AlertFeature): string {
    const props = feature.properties;
    return [
      `Event: ${props.event || "Unknown"}`,
      `Area: ${props.areaDesc || "Unknown"}`,
      `Severity: ${props.severity || "Unknown"}`,
      `Status: ${props.status || "Unknown"}`,
      `Headline: ${props.headline || "No headline"}`,
      "---",
    ].join("\n");
  }

  interface ForecastPeriod {
    name?: string;
    temperature?: number;
    temperatureUnit?: string;
    windSpeed?: string;
    windDirection?: string;
    shortForecast?: string;
  }

  interface AlertsResponse {
    features: AlertFeature[];
  }

  interface PointsResponse {
    properties: {
      forecast?: string;
    };
  }

  interface ForecastResponse {
    properties: {
      periods: ForecastPeriod[];
    };
  }

  // Register weather tools
server.tool(
    "get-alerts",
    "Get weather alerts for a state",
    {
      state: z.string().length(2).describe("Two-letter state code (e.g. CA, NY)"),
    },
    async ({ state }) => {
      const stateCode = state.toUpperCase();
      const alertsUrl = `${NWS_API_BASE}/alerts?area=${stateCode}`;
      const alertsData = await makeNWSRequest<AlertsResponse>(alertsUrl);

      if (!alertsData) {
        return {
          content: [
            {
              type: "text",
              text: "Failed to retrieve alerts data",
            },
          ],
        };
      }

      const features = alertsData.features || [];
      if (features.length === 0) {
        return {
          content: [
            {
              type: "text",
              text: `No active alerts for ${stateCode}`,
            },
          ],
        };
      }

      const formattedAlerts = features.map(formatAlert);
      const alertsText = `Active alerts for ${stateCode}:\n\n${formattedAlerts.join("\n")}`;

      return {
        content: [
          {
            type: "text",
            text: alertsText,
          },
        ],
      };
    },
  );

  server.tool(
    "get-forecast",
    "Get weather forecast for a location",
    {
      latitude: z.number().min(-90).max(90).describe("Latitude of the location"),
      longitude: z.number().min(-180).max(180).describe("Longitude of the location"),
    },
    async ({ latitude, longitude }) => {
      // Get grid point data
      const pointsUrl = `${NWS_API_BASE}/points/${latitude.toFixed(4)},${longitude.toFixed(4)}`;
      const pointsData = await makeNWSRequest<PointsResponse>(pointsUrl);

      if (!pointsData) {
        return {
          content: [
            {
              type: "text",
              text: `Failed to retrieve grid point data for coordinates: ${latitude}, ${longitude}. This location may not be supported by the NWS API (only US locations are supported).`,
            },
          ],
        };
      }

      const forecastUrl = pointsData.properties?.forecast;
      if (!forecastUrl) {
        return {
          content: [
            {
              type: "text",
              text: "Failed to get forecast URL from grid point data",
            },
          ],
        };
      }

      // Get forecast data
      const forecastData = await makeNWSRequest<ForecastResponse>(forecastUrl);
      if (!forecastData) {
        return {
          content: [
            {
              type: "text",
              text: "Failed to retrieve forecast data",
            },
          ],
        };
      }

      const periods = forecastData.properties?.periods || [];
      if (periods.length === 0) {
        return {
          content: [
            {
              type: "text",
              text: "No forecast periods available",
            },
          ],
        };
      }

      // Format forecast periods
      const formattedForecast = periods.map((period: ForecastPeriod) =>
        [
          `${period.name || "Unknown"}:`,
          `Temperature: ${period.temperature || "Unknown"}°${period.temperatureUnit || "F"}`,
          `Wind: ${period.windSpeed || "Unknown"} ${period.windDirection || ""}`,
          `${period.shortForecast || "No forecast available"}`,
          "---",
        ].join("\n"),
      );

      const forecastText = `Forecast for ${latitude}, ${longitude}:\n\n${formattedForecast.join("\n")}`;

      return {
        content: [
          {
            type: "text",
            text: forecastText,
          },
        ],
      };
    },
  );

  async function main() {
    const transport = new StdioServerTransport();
    await server.connect(transport);
    console.error("Weather MCP Server running on stdio");
  }

  main().catch((error) => {
    console.error("Fatal error in main():", error);
    process.exit(1);
  });

This code sets up an MCP server using the Model Context Protocol SDK in TypeScript. It provides tools (get-alerts, get-forecast) to fetch weather alerts and forecasts from the NWS API based on user-inputted locations.

Running the MCP Server

Now run npm run build in the terminal. This should create a build folder and index.js file in it.

We can now add this MCP server to cursor. In cursor setting, under MCP section, add an MCP server. The command to be used is node <path to build/index.js> . Looks the screenshot below, this is how it looks after successfully adding the MCP

Now we can ask Cursor to tell us the weather of any location is the US (because the MCP server uses the NWS API and only US locations are supported).

Simplifying AI Automation with Pre-built MCP Servers

Several platforms provide pre-built MCP servers, making it easy to integrate automation into your tools. Two notable ones are:

• Smithery.ai

• Glama.ai

Let’s take Smithery’s GitHub MCP server as an example. Instead of manually interacting with GitHub, you can:
✅ Add the MCP server to Cursor (or any AI-powered tool)
✅ Run the provided command with your GitHub Personal Access Token
✅ Start issuing commands like creating repositories, pushing commits, or managing pull requests—just by asking the AI!

Conclusion

MCP unlocks a new level of automation by allowing LLMs to interact with databases, APIs, and other external services in real time. Whether it's managing Supabase migrations or fetching live weather data, MCP makes it possible—without manual intervention!

Want to explore more? Check out modelcontextprotocol.io for in-depth documentation. Thanks for reading and Happy coding!

Meta Tag Order Matters

One key issue was that my Twitter meta tags were placed after the Open Graph (OG) tags in the index.html file. Twitter prefers its own meta tags to be defined before OG tags, or it might ignore them.

Fix → Always define Twitter meta tags first in your <head> section.

Image Size Limits & Best Practices

Different platforms handle OG images differently:

• WhatsApp: Requires images to be under 300KB, or they may not load.

• Twitter & LinkedIn: Accept larger images, but Twitter prefers 1200x630px for optimal display.

Fix → If your image isn’t appearing, try compressing it below 300KB

Cache Issues & How to Force a Refresh

Even after fixing the meta tags, changes weren’t reflecting on Twitter. That’s because social media platforms cache OG images aggressively.

Fix → Add a ?v=1 (or any versioning parameter) to your OG image URL to force a refresh. Example:

htmlCopyEdit<meta property="og:image" content="https://www.makemymvp.today/opengraph-image.png?v=1">

This tricks platforms into reloading the latest version of the image.

Final Debugging Checklist

If your OG image isn’t displaying correctly, check:
✅ Meta tag order (Twitter tags first)
✅ Image size & format (compressed for WhatsApp)
✅ Cache refresh (?v=1 trick)

After applying these fixes, my OG image now loads perfectly across Twitter, LinkedIn, and WhatsApp for makemymvp.today! 🚀

I hope this helps if you ever run into similar issues! Thanks for reading and Happing coding!

Secure Shell (SSH) is a protocol used to safely connect and send commands to remote machines from your local machine. A common use is to connect to your deployment server hosted in the cloud and control it from your local machine. An SSH command usually looks like this:

ssh user@<IP_Address>

Your server will have the SSH daemon (sshd) running on port 22, allowing you to connect to it. You can also connect using other ports with the -p flag like this: ssh -p <port_number> user@<IP_Address>. Make sure sshd is set to listen on that port number on your server. You can find the file /etc/ssh/sshd_config on your server to set the port numbers the daemon listens to.

With that explained, how does SSH actually work? Let’s explore it further.

How does SSH work internally

SSH is a protocol built on top of TCP/IP, similar to HTTPS. It encrypts traffic end-to-end using public key cryptography. When you run the command ssh user@<IP_Address>, the SSH client connects to the SSH server over port 22 using a basic TCP handshake. Then, the client and server exchange SSH protocol versions and decide which cryptographic algorithms to use, such as Diffie-Hellman or ECDH for key exchange and AES for encryption. During the key exchange, they establish a shared secret without directly transmitting it. Server authentication occurs on the client side, where the server sends its public key. The client checks this key against the ~/.ssh/known_hosts file. If the key is not in the file, the user is prompted like the following to accept it.

The authenticity of host '178.111.18.112' can't be established.
ECDSA key fingerprint is SHA256:dsjdba4sa7iudybduiduo ad098bsmvs+ijO8Y.
This host key is known by the following other names/addresses:
    ~/.ssh/known_hosts:3: abc.xyz.com
Are you sure you want to continue connecting (yes/no/[fingerprint])?

You may have seen this prompt on your terminal if you've ever tried to SSH into a server.

Once the shared session key is established, all further communication is encrypted using a symmetric encryption algorithm like AES, which was agreed upon earlier. The server may also prompt for a password to authenticate the user.
That's it! An SSH connection is established between the client and server, allowing the client to execute commands on the remote server.

How is it different from HTTPS

HTTPS is also a protocol built on top of TCP/IP that uses encryption. So, what's the difference? Unlike SSH, HTTPS uses SSL/TLS certificates for authentication. It's important to note that HTTPS also encrypts traffic like SSH. However, HTTPS is designed to be stateless, while SSH maintains a state (such as the current working directory). It's easier for a client to mistakenly trust a fake SSL/TLS certificate from a web server than to trust a public key from an SSH server, because the client is immediately alerted about unknown hosts. HTTPS is designed to handle web traffic and is understood by browsers, whereas SSH is a command-line-based protocol. These are some differences between SSH and HTTPS.

Conclusion

There you have it! Now you understand how SSH works internally and how it differs from HTTPS. You can learn more about SSH by visiting this link. Thanks for reading, and happy coding!

In a recent interview, I was asked about the difference between Sharding and Partitioning in the context of databases, and I couldn't answer properly. In this blog, we will learn what are they and the difference between them.

Why “Shard or Partition” a Database?

The terms Sharding and Partitioning come into play when you have to scale your database. When there is a lot of traffic coming to access your database, you will need to either Shard or Partition your database to make your queries faster and serve requests faster. Both of them are database partitioning techniques. Now let’s look at them individually.

Partitioning

Database partitioning involves dividing the data in an application's database into distinct segments, or partitions. Partioning can be of different types like Horizontal partitioning, Vertical partitioning, Range partioning etc..

Horizontal partitioning is when you divide a table by rows. Vertical partitioning is when you divide columns into different tables. You can choose the type of partitioning based on your query patterns. For example, you might choose vertical partitioning if your queries only access specific columns in a table with many columns. By splitting the table into two different tables, you reduce the amount of data read from the disk, which can significantly speed up queries. You can learn about all types of partitioning here.

Sharding

Database sharding is the process of distributing a large database across multiple machines to improve performance and scalability. Each shard is a partition, but sharding specifically focuses on distributing these partitions across different physical nodes to handle large-scale data more efficiently.

It is important to note that the data is stored across multiple database servers which are called shards.

For example, if you have user data in two different countries, you can shard the data based on the location and locate the servers in the respective countries. This makes the queries faster for both the countries.

Comparison

Sharding can be considered a subset of partitioning (specifically, horizontal partitioning), while partitioning is a broader concept that refers to dividing data into smaller chunks. Sharding always involves storing data across multiple database servers, whereas partitioning does not necessarily mean that.

Now you know the differences between sharding and partitioning. Thanks for reading, and happy coding!

I've always wondered how files are sent to the server in an HTTP request. Whenever I need to create a UI for file upload on the frontend and send it to the backend using an API call, I set the content-type to multipart/form-data in my HTTP headers. But what is multipart/form-data and how does it actually send the data to the server? Let's dive deep into it...

Handling form data

What is form data? Form data is a format for sending data from a web form. Let's say you have a form in your application that a user needs to fill out and submit, which essentially makes a POST request. When you make a POST request, you need to encode the data that forms the body of the request in some way. HTML forms provide three methods of encoding.

• application/x-www-form-urlencoded (the default)

• multipart/form-data

• text/plain

text/plain is rarely used because it doesn't encode special characters and has issues with new lines (read more about it here). application/x-www-form-urlencoded is the default encoding when you use the <form/> tag in your HTML code unless you specify the enctype as multipart/form-data. It is recommended to use multipart/form-data when the form data includes complex data like files, binary data, or non-ASCII characters. Otherwise, application/x-www-form-urlencoded is fast and efficient for small and simple data but not suitable for file uploads.

Don't worry about having a <form/> tag in your code whenever you have to upload files in the frontend. You can always use let fd = new FormData() and append whatever data you wanna send.

Structure of multipart/form-data

Let's examine the structure of multipart/form-data by setting up a simple loop that listens for incoming connections on port 8002 using netcat (nc).

The command will continuously listen for connections on port 8002. When a connection is made, it doesn't send any data (printf '' sends an empty string), and the loop restarts, ready to accept a new connection. Now, let's make a connection and send a file to the server at port 8002 using the command curl -F secret=@tick.gif http://localhost:8002, where tick.gif is a file in my folder. This command sends the file in an HTTP request. The -F flag tells curl to send the data as a multipart/form-data request. Let's look at the data printed by our while loop.

We can see that the host is localhost:8002 and the Content-Type is multipart/form-data. After that, we see a boundary and the binary data of the file starts. Here's how the data is sent when there are two (name, value) pairs. For example, the form sends two things to the server: a name and an image.

--boundary
Content-Disposition: form-data; name="name"

John Doe
--boundary
Content-Disposition: form-data; name="file"; filename="photo.jpg"
Content-Type: image/jpeg

(binary data)
--boundary--

The form data is divided into multiple parts and separated by a boundary. Each part includes headers that describe the content, followed by the data (text, binary, etc.). Now you know how multipart/form-data actually sends the data.

Conclusion

multipart/form-data encoding is a good choice when your form includes complex data like files. For simple and small data, it is not as efficient as application/x-www-form-urlencoded because of the overhead from boundary markers, which are needed for sending files and mixed data types.

EXPIRE

The EXPIRE command in Redis sets a timeout for a key. If you recall our Keyvalue store struct from the previous blog, it had an Expirations map[string]time.Time map. This is where we store the keys with timeouts. Let's look at the code.

func executeEXPIRE(args []string, kv *KeyValueStore) string {
    if len(args) <= 1 {
        return "(error) ERR wrong number of arguments for 'EXPIRE' command"
    }
    key := args[0]
    expiration, err := strconv.Atoi(args[1])
    if err != nil {
        return "(error) ERR value is not an integer"
    }
    var key_exists bool
    kv.mu.Lock()
    defer kv.mu.Unlock()
    if _, exists := kv.Strings[key]; exists {
        key_exists = true
    } else if _, exists := kv.Lists[key]; exists {
        key_exists = true
    } else if _, exists := kv.Hashes[key]; exists {
        key_exists = true
    }

    if key_exists {
        kv.Expirations[key] = time.Now().Add(time.Duration(expiration) * time.Second)
        return "(integer) 1"
    }

    return "(integer) 0"
}

The function accepts more than 1 argument (the key and the expiration value). It first checks if the timeout is a number and then verifies if the key exists in any of the 3 maps in the key-value store (Strings, Lists, Hashmaps). It then stores the current timestamp plus the expiration value, indicating when the key should expire.

Active/Passive Expiration

Redis expires these keys both actively and passively.

A key undergoes passive expiration when a client tries to access it after it has timed out. So, whenever a command like GET, MGET, INCR, or DECR is executed, we need to check if the key has expired. Let's write a function for this.

func checkExpiredStrings(key string, kv *KeyValueStore) bool {
    if expirationTime, exists := kv.Expirations[key]; exists {
        if time.Now().After(expirationTime) {
            delete(kv.Expirations, key)
            delete(kv.Strings, key)
            return true
        }
    }
    return false
}

This function is now called before executing the commands mentioned above. If this function returns true, it returns (nil).

if checkExpiredStrings(key, kv) {
        return "(nil)"
}

There is another function, checkExpiredLists, used when executing commands that deal with Lists, such as LPUSH, RPUSH, LRANGE, and LPOP.

Regarding active expiration, Redis periodically checks keys to see if they have expired and deletes them if they have. I have not personally implemented this. You can read about Redis's implementation in their docs.

TTL

TTL returns the remaining time to live of a key that has a timeout. The function that executes this command first checks if the key exists in any of the maps (Strings, Lists, Hashmaps) and then checks if there is an expiration. If it exists, it returns the time to live of that key. If key is actually expired, it deletes it from the key-value store. This is also one more way of passive expiration. Here's the snippet where it returns the remaining time if the key exists.

if expirationTime, exists := kv.Expirations[key]; exists {
    if time.Now().Before(expirationTime) {
        ttl := time.Until(expirationTime).Seconds()
        return fmt.Sprintf("(integer) %d", int(ttl))
    delete(kv.Expirations, key)
    delete(kv.Strings, key)
    delete(kv.Lists, key)
    delete(kv.Hashes, key)
    return "(integer) -2"
}

TTL returns -2 if the key does not exist and -1 if the key exists but has no associated expiration.

Writing RESP

We have explored implementing some essential commands in Redis. Now let's see how we can write back to the client using RESP. To keep it simple, godisDB always sends a Bulk String to the client. As you may have noticed, all our commands were also returning strings as responses.

func WriteBulkString(s string, conn io.ReadWriter) error {
    val := []byte(s)
    conn.Write([]byte("$"))
    conn.Write(strconv.AppendUint(nil, uint64(len(val)), 10))
    conn.Write([]byte("\r\n"))
    conn.Write(val)
    _, err := conn.Write([]byte("\r\n"))
    return err
}

This function is quite simple. It starts by appending the $ symbol, which signifies Bulk Strings in RESP. Then, it appends the length of the response followed by CRLF. Next, it adds the actual string followed by another CRLF. Any Redis client will be able to read this as a Bulk String.

Conclusion

We have finished reading input in RESP, executing commands, and writing to the client in RESP. In the next blog, we will look at how to implement persistence. You can check out the code here. Thanks for reading, and happy coding!

Key-Value Store

We know that Redis is a key-value in-memory database. So, we need to set up a key-value struct to store the data in our database. Here's the structure for it:

type KeyValueStore struct {
    Strings     map[string]string
    Lists       map[string][]string
    Hashes      map[string]map[string]string
    Expirations map[string]time.Time
    mu          sync.RWMutex
}

KeyValueStore is a struct with multiple hash maps where the key for each map is a string, but the type of value depends on the data structure we want to store in the database. For now, I've included Strings, Lists, and Hashes. mu is the mutex used to acquire a lock while reading/writing to this key-value store (Remember, godisDB is multithreaded unlike Redis). Ignore the Expirations map[string]time.Time for now; we will discuss this in the next blog when we explore the EXPIRE and TTL commands.

In the main function, before listening for connections, we will initialize our key-value store.

func main() {
    listener, err := net.Listen("tcp", ":6369")
    if err != nil {
        fmt.Println("error listening")
    }
    kv := &KeyValueStore{
        Strings:     make(map[string]string),
        Lists:       make(map[string][]string),
        Hashes:      make(map[string]map[string]string),
        Expirations: make(map[string]time.Time),
    }
    ...
    go handleConnection(c, kv)

As you can see, kv is passed as an argument to handleConnection function.

Executing Commands

Now that we have a command and the arguments in a struct similar to [{HELLO [world]} , let's write a function to execute the commands

func executeCommand(cmd Command, conn io.ReadWriter, kv *KeyValueStore) string {
    switch cmd.Name {
    case "SET":
        return executeSET(cmd.Args, kv)
    case "GET":
        return executeGET(cmd.Args, kv)
    case "SETNX":
        return executeSETNX(cmd.Args, kv)
    case "MSET":
        return executeMSET(cmd.Args, kv)
....continues

This function is a switch statement that handles commands case by case. I've only included 4 commands, but it is a really long function that supports commands like PING, SET, GET, SETNX, MSET, MGET, INCR, DECR, RPUSH, LPUSH, RPOP, LPOP, LRANGE, DEL, EXPIRE, TTL. Each command is handled separately in its own function. Let's look at some important commands and their functions in this blog.

SET

SET is usually the first command you try when you start using Redis. This command sets the string value of a key. Implementing a function to execute this command is straightforward. Here's the function:

func executeSET(args []string, kv *KeyValueStore) string {
    if len(args) <= 1 {
        return "(error) ERR wrong number of arguments for 'SET' command"
    } else {
        key := args[0]
        value := args[1]
        kv.mu.Lock()
        defer kv.mu.Unlock()
        kv.Strings[key] = value
    }
    return "OK"
}

SET command accepts two arguments: the key and the value. We acquire a lock on the kv store and set the key-value in kv.Strings because the SET command sets the string value of a key. Let's move on to the GET command.

GET

The GET command returns the string value of a key. We simply need to search for the key in kv.Strings and return the value if the key exists. Here's the function:

func executeGET(args []string, kv *KeyValueStore) string {
    if len(args) < 1 {
        return "(error) ERR wrong number of arguments for 'GET' command"
    }
    key := args[0]
    kv.mu.RLock()
    defer kv.mu.RUnlock()
    if checkExpiredStrings(key, kv) {
        return "(nil)"
    }
    if value, exists := kv.Strings[key]; exists {
        return value
    }
    return "Error, key doesn't exist"
}

The GET command accepts only one argument. You can see that at the end of the function, the value is returned if the key exists. kv.mu.RLock() acquires a read lock, allowing multiple goroutines to read (but not write) at the same time. This is different from kv.mu.Lock(), where only one goroutine can read or write after acquiring the lock. The function checkExpiredStrings is called to check if the key has an expiration set. We will explore this more in the next blog.

Commands like MSET, MGET, and SETNX are various versions of the SET and GET commands. You can look at their implementations in the source code.

Let's move on to the INCR command.

INCR

INCR increments the number stored at key by one. This is a string operation because Redis does not have a dedicated integer type. The string stored at the key is treated as a base-10 64-bit signed integer to perform the operation. If the key does not exist, it is set to 0 before the operation. An error is returned if the key contains a value of the wrong type or a string that cannot be represented as an integer. Here's the function:

func executeINCR(args []string, kv *KeyValueStore) string {
    if len(args) > 1 {
        return "(error) ERR wrong number of arguments for 'INCR' command"
    }
    key := args[0]
    kv.mu.Lock()
    defer kv.mu.Unlock()

    if _, exists := kv.Lists[key]; exists {
        return "(error) WRONGTYPE Operation against a key holding the wrong kind of value"
    }

    if _, exists := kv.Hashes[key]; exists {
        return "(error) WRONGTYPE Operation against a key holding the wrong kind of value"
    }

    if _, exists := kv.Strings[key]; !exists || checkExpiredStrings(key, kv) {
        kv.Strings[key] = "1"
        return "(integer) 1"
    } else {
        num, err := strconv.Atoi(kv.Strings[key])
        if err != nil {
            return "(error) ERR value is not an integer"
        }
        num++
        kv.Strings[key] = strconv.Itoa(num)
        return fmt.Sprintf("(integer) %d", num)
    }
}

Here, we first check if the key exists in Lists or Hashmaps and then move to Strings. In kv.Strings, if the key doesn't exist, we assign the key a value of 1 and return 1. Otherwise, we increase the existing value (if it can be converted to an integer).

DECR is a similar command to INCR but for decrement. Now, let's look at storing arrays in our database. Some important commands to store and retrieve arrays are RPUSH, LPUSH, RPOP, LPOP, and LRANGE.

RPUSH

RPUSH inserts all the specified values at the end of the list stored at key. If the key doesn't exist, it creates one. Here's the function for RPUSH:

func executeRPUSH(args []string, kv *KeyValueStore) string {
    if len(args) <= 1 {
        return "(error) ERR wrong number of arguments for 'RPUSH' command"
    } else {
        kv.mu.Lock()
        defer kv.mu.Unlock()
        key := args[0]
        if _, exists := kv.Lists[key]; !exists || checkExpiredLists(key, kv) {
            kv.Lists[key] = make([]string, 0)
        }

        for i := 1; i < len(args); i++ {
            kv.Lists[key] = append(kv.Lists[key], args[i])
        }
    }
    return "OK"
}

RPUSH accepts more than one argument and appends all the provided values to the list and returns "OK".

You can check out other commands like LPUSH, RPOP, and LPOP, which are used to store and retrieve values from arrays.

LRANGE

LRANGE returns the specified elements of the list stored at key. Let's look at the function

func executeLRANGE(args []string, kv *KeyValueStore) string {
    key := args[0]
    kv.mu.Lock()
    defer kv.mu.Unlock()
    if _, exists := kv.Lists[key]; !exists || checkExpiredLists(key, kv) {
        return "Error, key does not exist"
    }

    startIndex, err := strconv.Atoi(args[1])
    if err != nil {
        return "Error, Start Index must be an integer"
    }
    endIndex, err := strconv.Atoi(args[2])
    if err != nil {
        return "Error, End Index must be an integer"
    }

    if startIndex < 0 {
        startIndex = len(kv.Lists[key]) + startIndex
    }
    if endIndex < 0 {
        endIndex = len(kv.Lists[key]) + endIndex
    }
    if startIndex > endIndex || startIndex >= len(kv.Lists[key]) {
        return "empty"
    }
    if endIndex >= len(kv.Lists[key]) {
        endIndex = len(kv.Lists[key]) - 1
    }

    str := strings.Join(kv.Lists[key][startIndex:endIndex+1], " ")
    return str
}

LRANGE accepts the key, startIndex and endIndex as arguments.There are many safety checks in this function to handle indices going out of range. Finally, the desired elements are joined with spaces and returned as a string.

We've only discussed the implementation of some essential commands. Please check out all the implementations in the source code.

Conclusion

In the next blog (part-3), we will look at two important commands, EXPIRE and TTL, and the checkExpiredLists function, which we skipped in this blog. We will also discuss how to write back to the client in RESP. Thanks for reading. Happy coding!

I've always wanted to understand how Redis works internally and how its features are built. So, I decided to create my own version of Redis, but in Go (Redis is actually built in C). The name "godisDB" came naturally when merging Go and Redis. You can find the source code here. I'm breaking these blogs into multiple parts since there are many features, and I can keep publishing blogs as I build them one at a time. This blog (Part 1) will cover the following things:

1. Creating a basic TCP server in Go

2. Parsing Redis Serialization Protocol (RESP)

We need to create a TCP server because Redis is essentially a TCP server running on a port and accepting requests from clients. Redis uses the "Redis Serialization Protocol (RESP)" to communicate with its clients, and clients should use the same protocol to talk to Redis. If we use the same protocol for our database, all existing Redis clients can communicate with godisDB without any issues.

Creating a basic TCP server in Go

Creating a TCP server in Go is fairly simple because there is a package called "net" that can do it for us in a few lines of code. Like all TCP servers, ours should listen for connections on a specific port. Since Redis runs on port 6379, let's use port 6369. Here's the code using the "net" package:

func main() {
    listener, err := net.Listen("tcp", ":6369")
    if err != nil {
        fmt.Println("error listening")
    }
    for {
        c, err := listener.Accept()
        if err != nil {
            fmt.Println("error accepting connection")
        }
        fmt.Println("client connected")
        go handleConnection(c)
    }
}

net.Listen allows the server to listen on the port, and listener.Accept is used to accept connections. This is called in a for loop so we can accept multiple clients. Then, I call the function handleConnection in a goroutine. A goroutine runs independently of the calling function. This is where godisDB differs from Redis because Redis is single-threaded and uses I/O Multiplexing and an event loop like Node.js to handle multiple clients. GodisDB handles each client in a goroutine, which runs independently. Now, let's look at how the handleConnection function works.

func handleConnection(conn net.Conn) {
    defer conn.Close()
    fmt.Printf("Client connected: %s\n", conn.RemoteAddr().String())
    for {
        var buf []byte = make([]byte, 50*1024)
        n, err := conn.Read(buf[:])
        if err != nil {
            conn.Close()
            fmt.Print("client disconnected with ", err.Error())
            break
        }
        commands, err := ParseRESP(conn, buf[:n])
        fmt.Print(commands)
        executeCommands(conn, commands, kv)
    }
}

This function reads input from the client in a connection, uses the ParseRESP function to parse the input, and then executes the commands. Let's look at what Redis Serialization Protocol (RESP) is and how it is parsed in the following sections.

Redis Serialization Protocol (RESP)

Redis Serialization Protocol (RESP) is a protocol used by Redis and its clients to communicate. It is simple to implement, fast to parse, and human-readable. In an RESP-serialized payload, the first byte identifies the type, and the content follows. \r\n (CRLF) is the terminator in RESP. Here's a picture from the Redis documentation showing the types and their identifying bytes..

A simple string looks like +OK\r\n.

A bulk string looks like $<length>\r\n<data>\r\n. For example, $5\r\nhello\r\n (where $ indicates a Bulk string and 5 is the length of the string "hello").

An array looks like *<number-of-elements>\r\n<element-1>...<element-n>. For example, *2\r\n$5\r\nhello\r\n$5\r\nworld\r\n (where * indicates an Array, 2 is the number of elements, followed by 2 bulk strings as elements).

Understanding Bulk strings and Arrays is essential for now. You can read more about RESP in the Redis docs here. Now, let's build our parser for RESP.

Parsing RESP

Remember that in the handleConnection function, we stored the client's input in a byte array (inputBuf). We copy it into a bytes.Buffer because the functions we use to parse this input will update the pointer internally. This way, we can keep reading the buffer without losing track of how much has already been read.

var buf *bytes.Buffer = bytes.NewBuffer([]byte)
buf.Write(inputBuf)

We can start by reading the first byte to identify the type, then write separate functions to read each type. Here's the code for this function named parseSingle.

func (rp *RESPParser) parseSingle() (interface{}, error) {
    b, err := rp.buf.ReadByte()
    if err != nil {
        return nil, err
    }
    switch b {
    case '+':
        return readSimpleString(rp.c, rp.buf)
    case '-':
        return readError(rp.c, rp.buf)
    case ':':
        return readInt64(rp.c, rp.buf)
    case '$':
        return readBulkString(rp.c, rp.buf)
    case '*':
        return readArray(rp.c, rp.buf, rp)
    }
    return nil, errors.New("Invalid input")
}

As mentioned earlier, the ReadByte function reads and returns the next byte from the buffer, moving the internal pointer forward by one byte. Now, let's focus on the readArray function because Redis clients send requests to the Redis server as an array of strings.

func readArray(buf *bytes.Buffer, rp *RESPParser) (interface{}, error) {
    count, err := readLength(buf)
    if err != nil {
        return nil, err
    }
    var elems []interface{} = make([]interface{}, count)
    for i := range elems {
        elem, err := rp.parseSingle()
        if err != nil {
            return nil, err
        }
        elems[i] = elem
    }
    return elems, nil
}

In this function, we first read the length of the array (The readLength function handles the first CRLF by moving the pointer to the start of the array) and then iterate over this length to read the contents inside the array. In the for loop, we call the parseSingle function again, but with an updated pointer since some bytes have already been read.

Now, if the input is something like *2\r\n$5\r\nhello\r\n$5\r\nworld\r\n, the parseSingle function first detects the type and calls the readArray function. Then, the readArray function calls the parseSingle function twice to read the two bulk strings. Let's look at the readBulkString function:

func readBulkString(buf *bytes.Buffer) (string, error) {
    len, err := readLength(buf)
    if err != nil {
        return "", err
    }

    bulkStr := make([]byte, len)
    _, err = buf.Read(bulkStr)
    if err != nil {
        return "", err
    }

    // moving buffer pointer by 2 for \r and \n
    buf.ReadByte()
    buf.ReadByte()

    return string(bulkStr), nil
}

In this function, we first read the length of the bulk string and then read the buffer up to that length (Again, the readLength function handles the first CRLF by moving the pointer to the start of the BulkString). Finally, we move the buffer pointer by 2 at the end to account for the final CRLF.

So, for the above example, the parseSingle function will return an array ["hello", "world"]. In the array of strings sent by the client, the first element is the command, and the following elements are the arguments. So here, "hello" is the command, and "world" is an argument. Let's define a struct to manage this.

type Command struct {
    Name string
    Args []string
}

The following code will help us pack the result from parseSingle function into this struct

value, err := rp.parseSingle()
if err != nil {
    return nil, err
}

var cmds = make([]Command, 0)
tokens, err := toArrayString(value.([]interface{}))
if err != nil {
    return nil, err
}
cmd := strings.ToUpper(tokens[0])
cmds = append(cmds, Command{
    Name: cmd,
    Args: tokens[1:],
})

This code takes the first argument and stores it as the Name, while the other elements are stored as Args. The final result for our example will be [{HELLO [world]}.

That's how we parse RESP-serialized inputs and store them as Redis commands to be executed.

Conclusion

In Part 2 of this blog series, I will discuss how the commands are executed and sent to the client. I was inspired by Dhravya's Radish and Arpit Bhayani's DiceDB before building my own Redis. You can check out their implementations if you are interested. Happy coding!

What does rebase do

Rebase is a Git utility used when a team is working on a repository and wants to integrate changes from one branch to another. Git merge is another tool for this purpose, and we will explore the differences between them in the next section. First, let's dive into what rebase does.

Let's start with having a main branch and creating a feature branch for developing a new feature. Let's say we made 2 commits in this new feature branch. Meanwhile, our team has made 1 new commit in the main branch. Now we are in a situation where the main branch and the feature branch have diverged. We want to get the changes from the main branch into the feature branch keeping the history clean and making it look like we cut the feature branch from the latest main branch. Rebase can help us do exactly that. When we rebase our feature branch onto the main branch, the base of our feature branch will be updated, making it appear as if we created this feature branch from the latest commit in the main branch. Confused? Look at the image below to understand this better.

Let's create a new git repo and see how this works using git logs.

mkdir rebase_testing
cd rebase_testing
git init

Now I'll make an initial commit in main, then cut a feature branch. Make 2 commits in the feature branch. Note: all are empty commits.

git commit --allow-empty -m "main: commit 1"
git checkout -b feature_branch
git commit --allow-empty -m "feature: commit 1"
git commit --allow-empty -m "feature: commit 2"

Now let's make a new commit in the main branch

git checkout main
git commit --allow-empty -m "main: commit 2"

This is how git logs look in this state in both the branches.

Main:

Feature branch:

Now let's rebase feature branch onto main

git checkout feature_branch
git rebase main

Now let's look at the commit history of the feature_branch

As you can see, the base commit of the feature branch has changed from main: commit 1 to main: commit 2, just like in the image. And that's how rebase works. Now we can merge the feature branch into the main branch by running git checkout main and git merge feature_branch.

How is it different from git merge

Git merge is also a Git utility used to integrate changes from one branch to another. However, unlike rebase, merge does not rewrite commits. Instead, it creates a new merge commit. Look at the image below for a better understanding.

A new merge commit is created only when the two branches have diverged, as in the example above. However, if the main branch doesn't have any new commits, Git can directly move the main branch tip to the feature branch tip. This is called a fast-forward merge.

Now it is easy to see that, after rebasing the feature branch onto the main branch, the feature branch is no longer diverged from the main branch. So, merging the feature branch into the main branch will result in a fast-forward merge without a new merge commit.

This is why some developers prefer "rebase and merge" instead of "just merge".

Golden rule of rebasing

The golden rule of rebasing is to never use it on public branches like main. Since rebase can rewrite the commits of a branch, your main branch will then be different from everyone else's main branch, which is not desirable.

Conclusion

If you want a clean commit history without any merge commits, you can choose to rebase and then merge. But if you want to keep all the merge history and avoid the risk of rewriting commit history, go for the classic merge.

The go-to docs when I need to learn something about Git are the Atlassian docs. This blog is also inspired by them. Thanks for reading and happy coding !

Scroll-driven animations are "animations that are triggered as the user scrolls through a webpage," according to ChatGPT. I always wanted to build a personal website with cool scroll-based animations. I used to be amazed by some websites (like this) with impressive scroll-based animations. But when I started building my personal website, I procrastinated a lot. Then I thought I should write a blog for myself on scroll-driven animations in CSS to get a better idea of how to build my website. So here we go!

We have a default time-based timeline in CSS animations. Below is an example of a typical time-based timeline:

#scroll-icon {
    animation: scroll-icon 1.8s ease infinite;
}
@keyframes scroll-icon {
    0%{
        opacity: 0;
        transform: translate(-0px,-10px);
    }
    50%{
        opacity: 1;
    }
    100%{
        opacity: 0;
        transform: translate(0px,50px);
    }
}

But Scroll based timelines can be of 2 types.

Types of Scroll based timelines

Scroll progress timeline

One can progress this timeline by scrolling an element. The progression starts at 0% and ends at 100%, and the element can be animated within this range.

Let's look at an example to understand this better.

#sticky-parallax-header {
    position: fixed;
    top: 0;
    animation: sticky-parallax-header-move-and-size linear forwards;
    animation-timeline: scroll();
    animation-range: 0vh 90vh;
}

@keyframes sticky-parallax-header-move-and-size {
    from {
        top: 93vh;
        width: 100vw;
        font-size: 20px;
    }
    to {
        top: 4;
        width: 40vw;
        font-size: 14px;
    }
}

In this above example, there is a line animation-timeline: scroll() which says the animation timeline is scroll based. So when my element is at the bottom of the page, the animation starts as the user scroll the page. The keyframes tell us that the element goes from width: 100vw width to width: 40vw, and similarly top and font-size are also changed. Let's look at how this animation turns out now!

Initial state of the header(at the bottom):

State when the page is half scrolled:

Final state:

You can see that the header moves to the top as you scroll. The width and font size also decrease as specified in the CSS code above. The header stops animating at the top and takes on the final width and font size mentioned in the code.

That's how scroll-progress timeline works!

View progress timeline

You can progress this timeline based on the visibility of an element. The progression is 0% when the element first becomes visible and 100% when the element reaches the edge and is no longer visible.Let's look at an example

.revealing-image {
    /* Create View Timeline */
    view-timeline-name: --revealing-image;
    view-timeline-axis: block;

    /* Attach animation, linked to the  View Timeline */
    animation: linear reveal both;
    animation-timeline: --revealing-image;

    /* Tweak range when effect should run*/
    animation-range: entry 25% cover 50%;
}

@keyframes reveal {
    from {
        opacity: 0;
        clip-path: inset(45% 20% 45% 20%);
    }
    to {
        opacity: 1;
        clip-path: inset(0% 0% 0% 0%);
    }
}

Here, we first create a view-timeline and then assign it using animation-timeline: --revealing-image;. The view-timeline-axis: block; defines that the animation follows the vertical scroll. The line animation-range: entry 25% cover 50%; is crucial as it specifies when the animation starts and ends. As mentioned earlier, the progression in this timeline is based on the visibility of an element. "Entry 25%" means the animation starts when the element is 25% visible, and "cover 50%" means the animation stops when 50% of the scrolling (for that element in the viewport) is done. Let's see how this turns out!

Image 1 (Opacity is less than 1 and the image is clipped):

Image 2 (Opacity is 1 and the image is fully visible):

It is clear in the devtools that the element has been scrolled more than 50%, so the animation has finished. That’s how the view progress timeline works.

Scroll-driven animations Devtools Extension

All the images above had a cool debugger on the right side. This is the DevTools extension for scroll-driven animation. It's very useful when you are learning scroll-driven animations. Get it here!

Conclusion

Scroll-driven animations can make your website look much more beautiful. It is really helpful to understand them. I learned them from https://scroll-driven-animations.style/, and this blog is also heavily inspired by that site. Please check out more scroll-driven animations there. Happy coding!

Recently, I realized I needed to learn about this and write a blog post. So, let's dive in and explore "some" of the Linux File System.

So, /etc, /var,/bin, and /opt folders are part of the larger File System Hierarchy in Linux. There are specific requirements and guidelines for where files and directories should be placed in Linux according to FHS (Formerly, FSSTND). FHS stands for Filesystem Hierarchy Standard, while FSSTND stands for Filesystem Standard. In this blog, I will focus on explaining these four folders mentioned above.

Let's start with /bin. "bin" stands for "binary," and this is where the essential executable binary files (i.e., compiled machine code) are stored for various system commands and utilities. So, common commands like cp, mv, rm, cat, grep, etc., are stored here.

Coming to /var, "var" stands for "variable," and it contains data files that are expected to change during the normal operation of the system. For instance, in /var/log, you can find all the logs of your apps.

/etc is where all the configuration files for your applications are stored. "etc" actually stands for "etcetera" but can also be seen as "editable-text-configurations." The origin of this name dates back to a time when people had folders like /bin for specific purposes but lacked folders for files such as configuration files, data files, or socket files. Although now it is mainly for configuration files, the name has remained unchanged.

/opt is used to store all third-party software packages in your system that are not part of the core operating system. This is where my story of finding the nginx config begins. Knowing that I installed nginx using a homebrew formula, and homebrew is third-party software on my computer, I can navigate to /opt/homebrew first. I also know that configuration files are in the /etc directory. So, I can search for either /opt/homebrew/etc or /opt/homebrew/nginx. /opt/homebrew/etc/ is the correct path, and then I navigate to /opt/homebrew/etc/nginx to locate where the nginx.conf file is stored.

Now I know where to look for the nginx.conf file, so I don't have to feel frustrated or bother the devops guy every time I need to edit it! One fun fact I got to know while researching about this topic is that the full form of Linux is "Lovable Intellect Not Using XP". Thanks for reading and Happy coding!

There are 4 main things to be seen when a Javascript engine is running.

• The CallStack

• Webapis/Libuv

• Event Queue

• Event Loop

CallStack is literally a stack(LIFO) which tracks what part of the program is running. When a function is called, it gets pushed to the Callstack and when the function returns, it gets popped from the Callstack.

WebAPIs are built-in browser APIs that enables asynchronous operations in JavaScript(in browser) whereas Libuv is a cross-platform library that provides support for asynchronous operations in Node.js. When there is an asynchronous call (like an API call or a DB Query) in our program, it gets handed over to WebAPi/Libuv. While WebAPi/Libuv are handling the queries, Javascript is not blocked and can continue executing the program further.

Event Queue is a queue(FIFO) where callbacks for these asynchronous calls are pushed once they are processed. So when WebAPi/Libuv are done handling the asynchronous calls, the corresponding callbacks are pushed into the Event Queue.

Event Loop is the one which connects the Event Queue with the Callstack. Its sole purpose is to check if the Callstack is empty and push the first item from the Event Queue to the Callstack. So when the Callstack is empty, the callback for an asynchronous event that was called earlier gets executed.

This is how Javascript handles async calls being a single-threaded language. Now you know WTF is an event loop in Javascript !

I was heavily inspired by the blog post(https://dev.to/nodedoctors/an-animated-guide-to-nodejs-event-loop-3g62) about how Nodejs event loop works while writing this blog. Thanks for giving it a read!