Forem: Chirag Aggarwal

How we solved logging at Appwrite

Chirag Aggarwal — Sun, 19 Apr 2026 11:56:39 +0000

A few weeks back I came across a post by @boristane sharing a website he made, loggingsucks.com. It caught my eye because it had been shared by my favorite tech YouTuber, @theo. Like most people, I was really inspired by the article and shared it with my team. @lukebsilver, Appwrite's Engineering Lead, was also inspired by it and decided to work on a new PHP library, utopia-php/span, to fix logging throughout the Appwrite codebase.

What we had

Before this, Appwrite used a combination of two different libraries targeting logging in two different areas:

utopia-php/console — a very simple wrapper library around stdout logging using functions like Console::success(), Console::error(), etc.
utopia-php/logger — an adapter-based library to push error logs to monitoring systems like Sentry, AppSignal, Raygun, etc.

Combined, these libraries served their purpose for a long time, but we often ran into problems when debugging production issues, the same ones the original article discusses in detail. I'd highly recommend going through that article first so I don't repeat it all here.

Our solution

Funnily enough, the first tricky problem was deciding on a name. "Logger" was already taken, so we had to be creative. The word "Span" captured exactly what we were trying to solve: a fundamental unit of work with a named, timed operation alongside various attributes, errors, trace IDs, etc.

The first step was to move away from simple log lines to structured logging. Span enforces this by only exposing a single primary method, add(), which accepts a key-value pair.

Before:

Console::info("Deleting project {$project->getId()} (type={$type}, region={$project->getAttribute('region')})");

After:

Span::add('project.id', $project->getId());
Span::add('project.type', $type);
Span::add('project.region', $project->getAttribute('region'));

This massively improved the queryability of our logs — one of the things we struggled with most when going through logs in production.

We also wanted the library to be extremely simple to use. Earlier, with "logger", we had to hop through various dependency injection loops just to use it:

public function action(
    Message $message,
    Document $project,
    Log $log, // ← has to be injected just to add a tag
): void {
    $log->addTag('projectId', $project->getId());
    $log->addTag('type', $payload['type']);
    // ...actual work...
}

With Span, it's much simpler:

public function action(
    Message $message,
    Document $project,
): void {
    Span::add('projectId', $project->getId());
    Span::add('type', $payload['type']);
    // ...actual work...
}

Why not just make the logger methods static?

Because Appwrite's codebase leverages coroutines (via Swoole) for concurrency between requests, similar to goroutines in Go. A naive static implementation would leak state across concurrent requests. Span solves this by allowing you to choose the storage type:

Span::setStorage(new Storage\Coroutine());

Exporters

To combine both logger and console capabilities, Span exposes built-in Exporters, which, as the name suggests, export the logs to not just stdout but any supported adapter. The library currently supports three:

Stdout: basic usage. Dumps the output as plain JSON:

{
  "action": "worker.deletes",
  "span.trace_id": "7a3f9c2b4e1d8f06",
  "span.duration": 1.92,
  "project.id": "67f3a9",
  "project.type": "projects",
  "project.region": "fra"
}

Pretty: JSON dumps are very useful in production where you have OpenTelemetry or other monitoring set up, but locally you just want things to be readable:

worker.deletes · 1.92s · 7a3f9c2b

  project.id      67f3a9
  project.type    projects
  project.region  fra

  ────────────────────────────────

Sentry: since Sentry is primarily an error tracking system, Span also exposes a callable "sampler" that lets you filter which logs get exported to a particular exporter:

Span::addExporter(
    new Sentry(dsn: '...'),
    // Sampler: drop noisy expected errors, keep everything else.
    sampler: function (Span $span): bool {
        $error = $span->getError();
        return !($error instanceof ExecutorException) || $error->isPublishable();
    },
);

Before and after

One massive improvement we saw was with error logs. Before, we had very verbose and noisy errors that were often hard to make sense of:

[Error] Timestamp: 2026-04-17T10:32:16+00:00
[Error] Type: Utopia\Database\Exception\Timeout
[Error] Message: Query took too long
[Error] File: /usr/src/code/src/Appwrite/Cloud/Platform/Workers/Deletes.php
[Error] Line: 214
Trace: #0 /usr/src/code/app/worker.php(828): ...

Now:

{
  "action": "worker.deletes",
  "span.trace_id": "7a3f9c2b4e1d8f06",
  "span.duration": 2.14,
  "project.id": "67f3a9",
  "error.type": "Utopia\\Database\\Exception\\Timeout",
  "error.message": "Query took too long",
  "error.file": "/usr/src/code/src/Appwrite/Cloud/Platform/Workers/Deletes.php",
  "error.line": 214,
  "error.trace": [
    { "file": "/usr/src/code/app/worker.php", "line": 828, "function": "action" }
  ]
}

If you're writing PHP in 2026, give utopia-php/span a shot. And a massive shoutout to @lukebsilver, who actually built the library. I just learned from him and wanted to share what I picked up.

JStack + Appwrite: A Match Made in Heaven for Modern Web Development

Chirag Aggarwal — Sun, 06 Jul 2025 15:27:22 +0000

If I had a penny for each time a youtuber has launched his own tech stack, I would have 2 pennies, which isn't much but its weird that it happened twice.

I am talking about T3 Stack launched a while back by everyone's favourite Theo, but recently a new player has entered the market called JStack, by Josh who is the lead Devrel at Upstash. To be fair, its not even that recent, but as always ~~I am late to the party~~ I try to give a framework time to mature and gather feedback from community before giving it a shot.

So, did I prefer JStack over T3 stack? Did it have more compatibility with Appwrite, my favourite backend provider? Can it be hosted on Appwrite Sites? Let's find out.

Getting Started

Let's start with initialising the project:

bunx create-jstack-app@latest

Options selected:

┌   jStack CLI 
│
◇  What will your project be called?
│  testing-jstack-appwrite
│
◇  Which database ORM would you like to use?
│  None
│
◇  Should we run 'bun install' for you?
│  Yes

Using: bun

✔ testing-jstack-appwrite scaffolded successfully!

Let's just quickly run a dev server to see what we get out of the box:

cd cd testing-jstack-appwrite
bun dev

Initialising Project

On skipping the ORM option, the stack still sets up a /src/server folder with an example posts router. But it only mocks the DB using an array which does not persist:

// Mocked DB
interface Post {
  id: number
  name: string
}

const posts: Post[] = [
  {
    id: 1,
    name: "Hello World",
  },
]

We skipped the ORM option because Appwrite provides built-in schema management through its SDK, eliminating the need for a separate ORM layer. To get started, let's head over to https://cloud.appwrite.io to set up our project.

If you are using Appwrite for the first time, I highly recommend you check out our Start with Web docs.

Here is a quick setup guide:

Create a new project -

Add a new web platform and select Next.js -

Go to project overview and grab your project's ID and region-specific endpoint:

Create a new .env file in your project directory and paste in those values:

NEXT_PUBLIC_APPWRITE_PROJECT_ID=686a271700323696d223
NEXT_PUBLIC_APPWRITE_ENDPOINT=https://fra.cloud.appwrite.io/v1
NEXT_PUBLIC_APP_DOMAIN=localhost # we will change it later

Now, let's initialise the Appwrite SDK in the project using:

bun add appwrite

This covers up on how to initialize Appwrite in normal Next.js project. Now we need to configure our Appwrite databases according to the project. For this demo, let's create a Posts collection to shift the mock database JStack uses as an example to Appwrite.

Defining Schema

Go to the Appwrite Console > Databases > Create Database. We will call it main , and keep it' ID as main as well:

Similarly, create a collection posts and keep its ID as posts.
Each document in Appwrite already has an unique ID attached to it, so the only attribute we need is name for now:

Lastly, you will need to define who can access your collection. To learn more about it, check out the docs for Appwrite Permissions. For now, we will set it to any:

Syncing Types

That's it, we are all set with configuration on the Appwrite Console. Now let's set it up in our project. I will also take the help of the Appwrite CLI to help me set up things faster. You can learn more about how to install it by following the installation docs.

Once done, run:

appwrite init project

? How would you like to start? Link directory to an existing project
? Choose your organization 67610b8ee51f147ca943
? Choose your Appwrite project. [object Object]
✓ Success: Project successfully linked. Details are now stored in appwrite.json file.
Would you like to pull all resources from project you just linked? Yes

Once done, let's utilize the last Types Generation feature to sync our defined types:

appwrite types src/types       

ℹ Info: Detected language: ts
ℹ Info: Directory: src/types does not exist, creating...
ℹ Info: Found 1 collections: posts
ℹ Info: Found 1 attributes across all collections
ℹ Info: Added types to src/types/appwrite.d.ts
✓ Success: Generated types for all the listed collections

Result will look something like this:

import { type Models } from 'appwrite';

/**
 * This file is auto-generated by the Appwrite CLI. 
 * You can regenerate it by running `appwrite types -l ts src/types`.
 */

export type Posts = Models.Document & {
  name: string;
}

Obviously pretty small for now, but a really helpful feature once the project expands and more collections are defined.

Configuring Code

Final steps are to connect the Appwrite backend with our tech stack. For that let's create a simple appwrite.ts file in src/lib folder:

import { Client, Databases, ID } from "appwrite";

const client = new Client()
    .setEndpoint(process.env.NEXT_PUBLIC_APPWRITE_ENDPOINT!)
    .setProject(process.env.NEXT_PUBLIC_APPWRITE_PROJECT_ID!);

const databases = new Databases(client);

export { client, databases };

Now, we can modify the original post-router.ts file to use the defined database:

import { z } from "zod";
import { j, publicProcedure } from "../jstack";
import { databases } from "@/lib/appwrite";
import { type Posts } from "@/types/appwrite";
import { ID } from "appwrite";

const DATABASE_ID = "main";
const POSTS_COLLECTION_ID = "posts";

export const postRouter = j.router({
  recent: publicProcedure.query(async ({ c }) => {
    const posts = await databases.listDocuments<Posts>(
      DATABASE_ID,
      POSTS_COLLECTION_ID,
    );
    return c.superjson(posts.documents.at(-1) ?? null);
  }),

  create: publicProcedure
    .input(z.object({ name: z.string().min(1) }))
    .mutation(async ({ c, input }) => {
      const post = await databases.createDocument<Posts>(
        DATABASE_ID,
        POSTS_COLLECTION_ID,
        ID.unique(),
        {
          name: input.name,
        },
      );

      return c.superjson(post);
    }),
});

And done! Now your JStack application is using Appwrite as its backend provider.

Testing

Start the dev server if not already by running:

bun run dev

Your application should have started on: http://localhost:3000/
Create a new post.
You should be able to see it in recent posts:

Also, the data should be visible in your Appwrite Console:

Deploying your application

Until recently, to deploy your Next.js application, you had pretty low choices. But no more Appwrite Sites. Now, you can have your backend and frontend hosted on Appwrite.

Check out these docs on how to get started with Sites - https://appwrite.io/docs/advanced/self-hosting/sites

Let's deploy your application using Sites:

Go to Appwrite Console > Sites > Create Site.
You can upload a tar file directly, or connect to a GitHub repository (I prefer the GitHub option for automatic deployments).
Select the repository:

You can keep all the settings as the default ones, just make sure to upload the environment variables we defined earlier:

Depending on the domain you are assigned / plan to use, you also need to update the APP_DOMAIN variable we defined earlier. For me I will keep it:

NEXT_PUBLIC_APP_DOMAIN=jstack-appwrite-template.appwrite.network

Click on deploy.

And done! Your application should be live 🎉

You can checkout the demo application here - https://jstack-appwrite-template.appwrite.network/

Conclusion

Let's start by answering the question the blog began with: Do I prefer JStack over T3 Stack? I'm sorry, Theo, but I do.

JStack solves the fundamental problems I have always had with Next.js:

Using Hono instead of Next.js's inbuilt convention for defining API routes.
Using TanStack query out of the box. Trust me, you should start now if you are not using it.
Type safe and uses Zod.

The most noticeable difference between T3 Stack and JStack is how light they are, mainly due to the inclusion of the tRPC protocol in T3 Stack. Although JStack also uses tRPC, it seems like a much simpler implementation of it. Most projects do not require the complexity tRPC adds, and in my opinion it makes the code 10x more complicated to maintain.

So, give JStack a shot if you are starting with a new project (or want to spend a weekend migrating your existing stack to it). Huge shoutout to Josh for creating this wonderful stack. And lastly, give Appwrite a chance to be your next all in one cloud platform, both for your backend and frontend needs.

Sources:

JStack - https://jstack.app/
Appwrite Docs - https://appwrite.io/docs
Github repository - https://github.com/ChiragAgg5k/jstack-appwrite-template

Creating Knowledge bases using MindsDB

Chirag Aggarwal — Wed, 25 Jun 2025 03:35:39 +0000

Whenever we think we knowledge base, what is the first thing that comes to our mind?

For me it had always been a library.

Hundreds of thousands of meticulously organised lines of pure knowledge. In digital form, this knowledge is what we call as data. The internet is filled with data, and with the arrival of AI harnessing its power has become easier than ever before.

But what if you wanted your own library, your own knowledge base?

In this blog, we will discuss how you can do just that, and use this library of yours to ask anything you would like using simple natural language. We will create a knowledge base of various research papers, ask it some complex questions and for fun, stress test the hell out of it.

So let’s begin!

Creating a knowledge base

As an example lets create Scholar Map, an AI-powered research assistant where you can store any research paper and query for them in simple natural language.

To get started, first setup mindsdb self-hosted instance by following these docs - https://docs.mindsdb.com/setup/self-hosted/docker

Make sure the instance is available on http://127.0.0.1:47334.

Now,

Clone the repository:

git clone https://github.com/ChiragAgg5k/scholar-map.git
cd scholar-map

Install uv package manager if not already by following these installation docs.
Sync up dependencies:

uv sync

Start the application using:

uv run main.py

You should see this:

╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│  Scholar Map                                                                                                                                                                  │
╰───────────────────────────────────────────────────────────────── Research Paper Knowledge Management System ──────────────────────────────────────────────────────────────────╯
Connecting to MindsDB...
Attempting to connect to MindsDB server...
Connection established successfully!
Setting up research papers knowledge base...

The script will automatically run the configuration code and setup knowledge base.

Demo

From student to full-time Platform Engineer at Appwrite

Chirag Aggarwal — Sat, 21 Jun 2025 14:52:08 +0000

TLDR

For those who are not really interested in reading some random university student’s story, here is a short TLDR. I worked at Appwrite as an Engineering Intern for 6 months and just got offered a full-time position as a Platform Engineer, while still being in University for another year :D

The story ahead covers how while drowning in a sea of desperation a light of hope changed everything for me, how my experience was working for a fully remote OSS company, and the challenges I faced while working in PHP, a language I had never touched before this :p

Pre-Interview

Back in September-November 2024, I was kind of at the lowest point of my engineering journey yet. I had concluded my last internship around August when the project I was working on abruptly closed, and since then I was on a constant hunt for my next one.

Silence. From all the mediums I tried - LinkedIn, Upwork, AngelList, cold DMs, and what not.

The thing is that once you start “working”, although it was an unpaid one, it’s pretty hard to go back to doing… nothing. “Nothing” is the wrong word I guess, I was still working on OSS, building projects, and trying to learn new things. But if someone asked what I was up to nowadays… i drew a blank.

Then one day I was just hanging out on Discord and saw a notification from a bright red server I usually didn’t check much. Hey, it’s another job opening, so I applied like usual. Another month passed, silence again. But then I saw an email from Emma, our People’s person at Appwrite.

“We wanna have a chat with you.”

This was a very unusual email for me. Usually, companies like to give an assignment for the first round, but here it was a direct meeting scheduled… so I already knew something was different this time.

The Interview(s)

Of course, I am not allowed to share the entire interview experience without getting into a call with Emma after this is published. So, I just want to share one question that has stuck with me since then,

“Looking at your resume, you don’t seem to have much if any experience with PHP. And Appwrite’s entire backend is in PHP. Will you be able to handle this?” - Torsten, Product Engineer at Appwrite.

Stunned. Before going to the interview I did see the codebase was written in PHP. I had never touched it before. No contributions, No issues filed. So I assumed the position I was applying for might have nothing related to this codebase… maybe a new project altogether… right? Nope.

My answer? It was somewhere along the lines of “I will figure it out, trust me, bro”.

Very bad answer I know. But it was the best I could come up with. After the interview, I went on a grind. Reading the codebase, running it, and understanding its architecture (in that process I even wrote an article - Architecture Patterns for Beginners: MVC, MVP, and MVVM). Long story short I tried to learn as much about Appwrite’s codebase as was physically possible in that timeframe from the next interview scheduled.

And Tada~ It worked. I got the offer!

Experience

Working at Appwrite is unlike working in any other place. From the first day on, even though you are an Intern, you are never treated like one. I was introduced to the entire codebase in my first week and assigned to issues not from the pending log, but actual production issues that users were facing.

You can message anyone. At any point.

Work on any issue that you like.

There is a padding issue you saw on the website? Knock yourself out and raise the PR.

The beautiful thing about Appwrite being open source is that you could do this from the very start. It’s just now I could bug anyone on the team more freely if I was stuck on any issue.

It’s hard to summarise how much work I did in the past 6 months, but here are some notable ones:

200+ PRs merged in the Appwrite organization’s repositories, including main, website, SDK, MCP, etc. repositories.
Uptime monitoring for the Appwrite Assistant.
Adding a monthly limit to the number of free Phone OTPs allowed.
Fixing Amazon and Slack OAuth adapters. Add Figma OAuth adapter.
Making several changes to SDKs and making releases.
Adding Types generation to Appwrite CLI.
Worked on the DevKeys feature in the latest Appwrite release 1.7
Added 2 blogs on the website - self-hosting using coolify and announcement for DevKeys.
Taking leadership on the Synapse project, operating system gateway for remote serverless environments.
Adding new phone OTP adapter - Inforu, which reduces pricing for phone OTPs for Israeli users by 11x.
and… a lot more.

Honestly looking back at it, I never realized I worked on so much. It feels like I had just joined Appwrite yesterday.

Thank You

At last, I wanna thank the entire Appwrite team for treating me like part of the team since day one, and for giving me this opportunity. Let’s build like a team of hundreds_

You can check out my profile to learn more about me - https://www.chiragaggarwal.tech/

Hit me up on any socials if you have any doubts, I am always up for a chat :D

Automate anything - Making research analysis effortless

Chirag Aggarwal — Sat, 14 Jun 2025 05:13:48 +0000

Starting with a research project can be overwhelming.

There are so many data points to consider, so many hours of reading to do, and within all that chaos, the hardest piece of the puzzle to find is a starting point.

I faced this first hand when last year I had to work on multiple papers to earn a single credit point for my engineering degree. Unfortunately why universities force this pointless system is not the spotlight of today’s discussion.

Instead, we are going to discuss how you can cheat on this mundane activity using Runner H.

The article will redefine how you interact with AI, helping you put together analysis, execution, summarisation and integration with a single prompt.

So, let’s dive in.

Researcher’s Dilemma

Whenever you start with a research project, the first question that comes to mind is: "Has this been researched before?"

Answering this question is crucial for:

Avoiding duplication of work
Finding gaps in the existing study
Not claiming something as noble when it has already been done before

However, doing this is a very manual process, and requires hours and hours of find papers, reading them and doing accurate analysis.

Meet Runner H

Ever tried using Perplexity or ChatGPT in research mode?

Think of Runner H as that, but on steroids.

Runner H is an advanced AI-powered web automation tool that lets you perform multi-step online tasks using natural language instructions. It seamlessly integrates with services like Slack, Notion, Gmail, and Excel, enabling you to create complex workflows, no coding experience required.

For our purpose, we can use Runner H to:

Quickly identify similar research papers with a Google Scholar scan.
Assess similarities between them and your topic using AI.
Scan the internet to find gaps between the existing work.
Export the findings in a structured format.

The prompt

Below, I have crafted a prompt that you can copy and paste into Runner H, replace with the topic you need to research, and voila~, see the magic unfold:

Analyse if my research idea, {YOUR_RESEARCH_IDEA}, has been previously explored. Search Google Scholar for similar research papers. For each, extract the title, authors, publication date, abstract, journal/conference, and similarity percentage to my idea, and note any research gaps mentioned or left open. Create an Excel file summarising all findings.

Just replace {YOUR_RESEARCH_IDEA} with the idea you want to research on.

Demo

Let’s try researching on a topic:

“The impact of generative AI tools on student learning outcomes in higher education”

So Runner H after doing all the analysis and hard work for us was able to generate a structured output. Unfortunately, even though prompt specifically asks for Excel format, most of the times for me it generated a PDF format for me. Still Runner H is still in early phases and hopefully will be improved in future by the team.

So what makes Runner H different?

One of the most fascinating differentiations I found in Runner H compared to other agentic tools was its ability to search, summarise and synthesize as well. Instead of just dumping in raw results, it evaluates the relevance of each paper, highlights the overlaps and gaps in the study, and presents it in an actionable format.

Using Runner H has completely transformed my approach to starting a research topic. It has bridged me to the starting point where I used to struggle the most. For students, academic professionals, and anyone doing any sort of research work, Runner H is a game changer.

Happy researching! If you have questions or want to share your own experiences with Runner H, drop a comment below.

Vibe coding an Email Ticket Automater using Postmark

Chirag Aggarwal — Sat, 31 May 2025 02:44:00 +0000

This is a submission for the Postmark Challenge: Inbox Innovators.

What I Built

Support tickets…

Nobody really loves either writing or much worse reading them. And managing them is much much worse than managing my laundry, and that is a really high bar to pass.

So, in a world where we all are writing and summarising emails for the sake of maintaining formality, automating support tickets seems like the logical next step.

And sure there are companies that do this… not really going to name them, but my vision here was to just create something that takes the unorganized text and convert it to organized boxes, while still being pretty to look at… cough Jira cough.

Meet EmailTicket. Firstly hoping that marks are not being deducted for the lack of naming creativity, it's here to do exactly what it says. Create tickets based on emails. Sounds simple right? Well kind of… but with some headaches.

Historically, when creating tickets you would have to ask the user a bunch of information like whether it is a billing issue, a bug, or feedback, when did the issue start, etc.

After creation, you would have to manually keep track of information like how urgent is it. Has the ticket been closed or is it still in progress? etc. etc.

You know… the boring stuff.

Image captured during the pre-AI times (just kidding it was created using ChatGPT)

But with AI, we no longer need to take care of that stuff. Just give it a random block of text and out comes structured beauty (It’s like a dream come true for data scientists honestly).

This is pretty much what Email Ticket does for now. It’s highly inspired by platforms like HelpScout (an amazing tool btw do check it out) and in the future can extend a lot more if good guys like the ones from Postmark support it :D

Demo

Checkout the live link here - https://email-ticket-automator.vercel.app

If your emails are stuck on processing/waiting, It’s highly likely that I ran out of the 100 free emails. So… don’t sweat too much about it 😅

Code Repository

ChiragAgg5k / email-ticket-automator

AI-powered helpdesk platform leveraging email-parsing by Postmark

📧 Email Ticket

A modern, AI-powered helpdesk platform that transforms email support into an organized ticket management system. Built with React, TypeScript, Postmark, and Appwrite for seamless customer support experiences.

🏹 Quick Start

Prerequisites

Node.js 18+ and npm
Postmark account for email parsing
Appwrite account for backend services

Installation

Clone the repository

git clone https://github.com/ChiragAgg5k/email-ticket-automator.git
cd email-ticket-automator

Install dependencies
```
bun i # or npm install
```
Configure Appwrite
- Create an Appwrite project at cloud.appwrite.io
- Update the configuration in src/lib/appwrite.ts:
```
client.setEndpoint("YOUR_APPWRITE_ENDPOINT");
client.setProject("YOUR_PROJECT_ID");
```
Start the development server
```
bun dev
```
Open your browser Navigate to http://localhost:8080 to see the application

🛠️ Tech Stack

Frontend

React - Modern React with hooks and functional components
TypeScript - Type-safe development experience
Vite - Fast build tool and development server
Tailwind CSS - Utility-first CSS framework
shadcn/ui - High-quality, accessible UI components

Backend & Services

…

View on GitHub

How I Built It

So most of the application is vibe-coded using Lovable. Was it because I am lazy? Probably yes. But that’s not the exact reason. In my opinion tools like Lovable, V0, Firebase Studio (god there are so many now), etc. are perfectly fine to use to get an initial MVP of your idea up and running.

And in a world where AI is dominating the entire development process, not utilizing these tools is just slowing you down.

So let’s talk about the 10% of coding I actually did.

The first was integration with a database. Or more specifically a Backend as a Service because who codes their own backend nowadays? So naturally I went with Appwrite. Lovable refused to do this integration, but thankfully Appwrite is extremely easy to set up. I used it to implement Authentication flow, as well as Database for ticket storing and retrieval.

Next was the start of the application, Postmark. Postmark made the entire process of receiving an email, parsing it into JSON, and receiving it just via an API call so easy, I forgot dealing with emails was such an annoying task.

Firstly, I needed to A) Either get inbound domain forwarding setup, or B) Get my account approved to be able to send emails to the default inbound email address with no domain restrictions. I tried both techniques and luckily got my account approved in 2 days!

Not so luckily I was never able to set my inbound domain even tho I had my MX record set properly and could verify it using https://www.whatsmydns.net/ (You can check my comment here complaining about it - https://dev.to/chiragagg5k/comment/2o6hi). So something to note down @Postmark team.

To utilize the API seamlessly without ever needing to touch a single line of actual backend code, I came up with this flow:

Appwrite triggers a “create” document/ticket event.
The event triggers a function that then calls the Postmark’s API for sending an inbound email.
Postmark listens to the inbound email and triggers an email parsing flow.
After parsing is done it returns the output to a webhook URL which is just an Appwrite function.
The Appwrite function finally processes the parsed content and stores it back to the database.

Finally time for structured outputs. Almost all LLMs offer a way to generate structured outputs now in their APIs. Here are some docs I found for this:

and on and on…

(a small plug would be to check this repo I worked on which allows you to use any LLM with structured outputs and consistent syntax in PHP - https://github.com/utopia-php/agents)

You can check the repository code itself to see which one I picked because I might have changed it by the time you are reading it :p

That’s it then. Let me know in the comments how was your experience using EmailTicket Automater. You can reach out to me on any of my social media links if you have any queries or just wanna have a casual talk. A big shoutout to Postmark for arranging this contest and letting me have fun with their platform, as well as my company Appwrite for supporting the application’s backend :D

Bye!

Focus on the product, not the tech stack

Chirag Aggarwal — Wed, 14 May 2025 16:48:53 +0000

Recently I got this DM,

“Which tech stack should I learn?”

“Should I use Next.js or Svelte?”

“Is Python better for the backend than node?”

I am sure we have asked or been asked questions like this several times in our tech journeys. As someone who is just starting out, I think it seems like a very important thing to ask. You don’t wanna waste your time learning a technology that might become worthless soon? Or isn’t fast enough? or isn’t the “industry standard”… right?

Or should it matter?

Languages are just tools

Back in 2003 when Facebook was originally founded, its backend was written in PHP. Was it the lack of options? You can say so. Back then they certainly didn’t have a plethora of frameworks or hell even languages to choose from. But what about now? Realistically PHP should be dead by now…

Right?

But if you look at the statistics by Kinsta, around 79.2% of the internet still relies on PHP to some degree. Okay, but that number has to be declining for sure!

But wait...

Nope, it has been on a steady increase since 2011, peaking at 80.6% in 2015, and maintaining a steady line.

But how?

It’s because language is just a tool. It does not matter how many new bleeding edge languages enter the market increasing the performance metrics by some fractions of seconds, as long as a ~~tool~~ language sufficiently fulfills its job, it will stay relevant. PHP has done a great job at that. It’s constantly evolving as well, something which is direly required to stay alive in the software world.

So next time if someone asks you “Which language should I choose?”, ask them two things:

Which language are you more comfortable with?
Do the other languages provide a set of features more beneficial for your use case? Even if so are they worth the effort to learn? (arguments like uh it's 0.001sec faster should not be relevant)

It’s OK to not upgrade

Image from: https://foreverealize.me/posts/how-to-update-dependencies/

I was once asked, “Why is your website still at Next version 13 when 15 has arrived?”

To which I ask, why does it matter? Sure software is meant to be ever-evolving, but that doesn’t necessarily mean it's a good idea to always hop on the upgrade bandwagon without looking at the consequences.

This in this case will be a complete re-write since Next 15 introduces a ton of breaking changes.

And it's OK not to upgrade every time.

Judge a product by its usefulness, not complexity

A lot of people especially those building projects just for improving their resume will try to make them extremely complex. It will be a wobbly mess of high-end sounding technologies like SSR, TRPC, GraphQL, Kubernetes, Redis, etc.

Sure I do understand the thinking behind this, it does show your ability to work with complex technologies.

But in the age of AI and the really fast-moving pace of technology, it's pretty trivial for someone to learn technologies on the go and incorporate them into their project. Real engineering will always be that “solves a problem, not create one”. Solving problems always requires asking questions first:

Does your project really need TRPC or GraphQL? Why not just use REST like everyone does bruh?
Do I really need Kubernetes for those 5 concurrent connections?
Does my really interactive website need SSR where then each button click will be a server action and take ages to process any action?

And please, stop building clones. It does not matter:

how many services you use in it
how much knowledge you gained from creating it
how complex the project was to make

The YouTube clone you made by following a random Youtuber’s 8-hour-long guide is not going to help you in any way.

Quoting Theo (idk where he said tho):

To build a great product, you need to first be a customer

If you want project ideas, look around you. Try to solve problems you face every day. If you just try looking, you WILL find many.

Final words

This blog is a summary of my (I admit very short-lived) experience of working in tech till now. I always tried not to treat tech as something I specialize in, but as a tool that helps me solve problems.

I started off my journey in web with a simple problem, I just wanted a website of my own because it would be cool :D

Then a simple problem gave birth to more problems with a chain reaction ongoing, to me finding myself working with PHP, something I would have never imagined doing in a million years before.

So…. that’s it. Keep building and showcasing your work, and most importantly, have fun at it!

Debugging with Source Maps: A Comprehensive Guide

Chirag Aggarwal — Sun, 09 Mar 2025 18:44:24 +0000

We all have been there, working on a new feature for 10+ hours straight, and everything is going well. You build your project and push the code to production. And boom, a new production error alert! Everyone in your team - whether at a company or a hackathon - starts to look for someone to blame. Found it; it was from you. But none of your test suites resulted in an error. Everything with the code itself looks excellent.

You check the logs. The error is:

Uncaught Error: Cannot read property 'xyz' of undefined at app.min.js:1:45678

You think to yourself, what the heck is app.min.js:1:45678 supposed to mean? There was no file like that in the entire source code? Your file was called app.js. And it's 45678 characters long! That's impossible to debug!! Still, you try to open the file and potentially find the root cause of the error. It's a mess. The entire file is filled with random gibberish you are unable to understand. What should you do?

Now, this is where Source Maps come into play. Source Maps allow you to map the minified code in your production environment, aka the random gibberish you just saw, with the actual source code, allowing you to pinpoint the root cause of the error in your source code and debug it effectively.

In this blog, we will detail what source maps are, why and how they are created, and give some tips on effectively using source maps to debug your code. Let's dive in!

Why is source code minified?

Before we delve into Source Maps, let's first decode what happened to your clean, formatted and linked source code and why it looks nothing like it on the browser.

The simple answer is minification.

Minification is the process of converting your source code into production-ready code without changing any of its functionality. This is typically done by the bundler you are using, such as Webpack. To learn more about bundlers, you can check out this awesome guide on Javascript bundlers by Snipcart.

Simply put, bundlers optimise your source code by stripping out whitespaces, comments, and redundant code and even removing or renaming variables for shorter alternatives. This makes your code super efficient and much smaller in size.

Why does this happen?

Improved load times - Smaller file sizes lead to better website loading times.
Obfuscation—Although it won't make your code entirely illegible, it does make it harder for regular users to understand.
Browser Performance - The code is altered in a way that's easy for browser engines to parse.

Here is an example of what a minified React app code looks like:

bundle.js file created by Webpack on building a simple React app, even the text is overflowing from the terminal screenshot!

What are source maps?

Source maps are files whose names end with .map and that map the minified code to your actual source code. Examples of such files can be example.min.js.map or for css, styles.css.map. They are explicitly generated only by build tools like Webpack, Vite, Rollup, Parcel etc. Since source maps are only required for debugging purposes, these tools usually have the option to generate source maps off by default. For example to enable it in Webpack, you can do:

// add this to your package.json file
"scripts": {
    "build:dev": "webpack --mode development --devtool source-map",
}

or add it to your webpack.config.js file:

module.exports = {
    devtool: 'source-map',
    // ...rest of your config
}

A source map includes crucial information on how the mapping is done, including the actual source file name, the content it includes, various variable name the source code has, name of the minified code file etc.

Here is a format of how a typical source map file looks like:

{
  "mappings": "AAAA,SAAQA,MAAMA,QAAQ,OAAO;AAC7B,SAAQC...",
  "sources": ["src/index.js"],
  "sourcesContent": [
    "import React from 'react';\nimport { createRoot } from 'react-dom/..."
  ],
  "names": ["React", "createRoot", "App", "count", "setCount", "useState", ...],
  "version": 3,
  "file": "bundle.js.map"
}

The most important section here is mappings. This uses a special kind of encoding called VLQ base 64 encoded string to map the lines and locations to compiled file and its corresponding original file.

Visualising source maps

"Okay, great!" I hear you saying. "How is this actually helpful? I still can't read the source maps and manually decode the mappings."

That's a great question! This brings me to the main highlight of this blog—source map visualisers. These tools allow you to see the mappings in a visual manner to locate and debug the problem effectively. There are many source map visualisers on the market, but today, we will be focusing on Sokra & Paulirish's source map visualization. You can find the source code for this on their Github Repository.

Here is a side-by-side comparison of how your code (on the right-hand side) can look like a jumbled mess when minified (on the left-hand side). However, the colour-coded mapping of the visualiser helps us map these two codes by hovering over them.

Working Example

Let’s create a simple React app and play around with it’s sourcemaps!

Start with creating a project directory:

mkdir my-project
cd my-project

Init a new project:

npm init -y

Add the following dependencies into package.json

{
  "name": "react-counter-app",
  "version": "1.0.0",
  "description": "Simple React Counter App",
  "main": "index.js",
  "scripts": {
    "start": "webpack serve --mode development",
    "build": "webpack --mode production",
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "dependencies": {
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@babel/core": "^7.23.0",
    "@babel/preset-env": "^7.23.0",
    "@babel/preset-react": "^7.22.15",
    "babel-loader": "^9.1.3",
    "css-loader": "^6.8.1",
    "html-webpack-plugin": "^5.5.3",
    "style-loader": "^3.3.3",
    "webpack": "^5.88.2",
    "webpack-cli": "^5.1.4",
    "webpack-dev-server": "^4.15.1"
  }
}

Create a src/index.js file with following React code:

// src/index.js
import React from 'react';
import { createRoot } from 'react-dom/client';
import './styles.css';

function App() {
  const [count, setCount] = React.useState(0);

  const increment = () => {
    setCount(count + 1);
  };

  const decrement = () => {
    setCount(count - 1);
  };

  return (
    <div className="app">
      <h1>Counter: {count}</h1>
      <button onClick={increment}>Increment</button>
      <button onClick={decrement}>Decrement</button>
    </div>
  );
}

// New React 18 createRoot API
const container = document.getElementById('root');
const root = createRoot(container);
root.render(<App />);

Add styling by adding a src/styles.css file:

/* src/styles.css */
.app {
  font-family: Arial, sans-serif;
  max-width: 500px;
  margin: 0 auto;
  padding: 20px;
  text-align: center;
}

button {
  background-color: #4CAF50;
  border: none;
  color: white;
  padding: 10px 20px;
  text-align: center;
  text-decoration: none;
  display: inline-block;
  font-size: 16px;
  margin: 10px;
  cursor: pointer;
  border-radius: 4px;
}

button:hover {
  background-color: #45a049;
}

Now define the webpack config by creating a webpack.config.js file in the root folder:

// webpack.config.js
const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  entry: './src/index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js',
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        use: {
          loader: 'babel-loader',
          options: {
            presets: ['@babel/preset-env', '@babel/preset-react']
          }
        }
      },
      {
        test: /\.css$/,
        use: ['style-loader', 'css-loader']
      }
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: './public/index.html'
    })
  ],
  devServer: {
    static: {
      directory: path.join(__dirname, 'public'),
    },
    port: 3000,
    open: true
  },
  resolve: {
    extensions: ['.js', '.jsx']
  }
};

Now you can start the application by running:

webpack serve --mode development

This is how it should look (very basic i know :D):

You can find the source maps using your browser's dev tools. The format can look different depending on the browser you are using. Here, I am using Zen, but the format should look similar for all browsers.

You can do so by right-clicking anywhere on the page and clicking on Inspect Element. Then, go to the Sources section of your browser and find the source file. Here on Zen, it's available in the debugger section since it's mainly used for debugging purposes.

Now, you can load this in the source-map-visualization. It will look something like this:

On right you can skip all the React code and skip to the section that contains just your code. On hovering over each section of your code you will see exactly which part of the minified code it maps to!

It can look pretty confusing at first, but try hovering over various elements in the UI and you will see how intuitive it actually is. For eg. in this example code,

React.useState(0) ----> t().createElement("h1",null,"Counter: ",n) .... // so on

Hovering over React.useState reveals that it maps to a createElement in the minified code. So our bundler, Webpack, in this case, optimised our code by directly converting our state into a javascript element and directly modifying it in subsequent code. This makes our application much, much more performant and reduces the file sizes the browser has to load!

Security Considerations

While creating the example app, you may have noticed we had to explicitly add the flag --mode development to the Webpack run command. This is because source maps are supposed to be used for debugging purposes only, and can lead to security concerns when used in production, including:

Concern	Description	Mitigation
Exposing Source Code	Source maps reveal your original code, including comments and logic	Use `hidden-source-map` or `nosources-source-map` in production
IP Protection	Intellectual property may be exposed via full source maps	Deploy source maps to secure, authenticated location
File Size	Source maps can be large, affecting download performance	Generate maps only in development, or serve separately
Server Configuration	CORS issues may prevent source map loading	Configure proper `Access-Control-Allow-Origin` headers

There are also tools like Sentry or Rollbar which use your source maps for better error reports without violating any of the security concerns. Tools like these are considered best practise for production environments.

Conclusion

Source maps are a mind-blowing feature that lets you map your source code precisely to the minified code loaded by your browsers, which is generated by bundlers like Webpack for performance and speed. We explored how debugging can be made easy using this feature and tools like source map visualisers to aid in the process.

The web is built on top of layers and layers of abstractions done by tools like bundlers, but when things go catastrophically wrong, we might discover that these abstractions are not always hundred percent perfect, and hence, we need to take out our tools, look under the hood, and find the fix ourselves.

To learn more about package managers like NPM, Bun, PNPM, and yarn, you can check out my other article, Mastering npm: A Comprehensive Guide to Package Management.

References

Thanks to these fantastic references by the Google Chrome dev team that helped me learn about source maps myself and in writing this article:

Writing Event-Driven Serverless Code to Build Scalable Applications

Chirag Aggarwal — Sun, 26 Jan 2025 17:12:20 +0000

Serverless isn't just trendy—it's rewriting how software scales.

Netflix streams billions of hours without servers. Coca-Cola automates workflows without infrastructure. Figma and T-Mobile ditch downtime. What do they know that you don't?

The secret? Event-driven serverless code. It's the backbone of apps that scale instantly, cut costs, and survive traffic spikes. No servers. No guesswork. Just code that reacts.

This isn't hype—it's a blueprint. Ready to build smarter? Let's break down how event-driven serverless turns scalability from a challenge into a reflex.

Brief Intro to Serverless

Spoiler alert: servers are still there.

There are multiple definitions for this term online, often filled with complex jargon. The best way I like to define it is:

A "fashion" of deploying your code where YOU don't have to think about the servers running your code.

Let's take an example:

Take Bob. He built mytrashcode.com but panicked at "server setup." He's a developer, not a sysadmin. Instead, he uploaded his code to a cloud provider. They handled security, scaling, and traffic—his site went live. No late-night server meltdowns. No panic during traffic surges. Done.

Why Can't I Manage My Own Servers?

Managing your own servers usually takes one of two paths. You either run physical hardware—like turning an old laptop into a DIY server—or rent a Virtual Private Server (VPS) from providers like DigitalOcean Droplets, Azure VMs, or AWS Lightsail. These fall under IaaS (Infrastructure as a Service), where the cloud company provides the bare-metal infrastructure, but the rest—updates, scaling, security—is entirely up to you.

Does this mean self-managing servers is impossible?

Not at all. Plenty of teams still do it. But managing your own servers comes with a lot of... challenges, including:

Knowing how to manage infrastructure/hardware.
Setting up auto-scaling and downscaling.
Periodically applying system patches and updates to avoid exposing vulnerabilities.
Configuring proxies, SSL certificate generation, network settings, etc.

Dividing Your Code into Functions

Serverless code doesn't need to be monolithic, i.e., all code doesn't need to be in the same place. It can be a collection of bite-sized, event-triggered functions.

A Function is nothing but a set of code that performs a specific task. When writing your entire code serverless, you'll find that you can divide your code into various functions, each handling a specific part of your application. Let's understand this more deeply with an example:

When Bob first logs into mytrashcode.com as a new user, the system triggers a "send welcome email" function before redirecting him. Subsequent logins bypass this function entirely, routing him straight to the dashboard. This separation serves a critical purpose—while 99% of users interact solely with the dashboard, isolating secondary functions (like email triggers) enables independent scaling.

Though trivial in this example, the cost implications compound dramatically at scale. Each decoupled function operates on its own resource allocation curve—high-frequency features like dashboard access demand consistent infrastructure, while one-time actions (welcome emails) can scale down during inactive periods. This modular approach prevents overprovisioning for rarely triggered events, even before considering complex systems with hundreds of interdependent functions.

Where to Deploy???

Okay, so just a quick recap—we now know:

Deploying serverless is great!
Dividing your code into functions is modular and scalable.
Functions can be triggered by events.

So, where do you deploy this architecture? Leading platforms like AWS Lambda, Azure Functions, and Google Cloud Functions support it, but we'll focus on Appwrite Functions.

Appwrite, an open-source Backend-as-a-Service (BaaS), bundles authentication, databases, storage, and serverless functions into a single toolkit. This tight integration streamlines deployment—instead of managing fragmented cloud services, Appwrite centralizes backend logic, letting you deploy event-driven functions with minimal overhead. For developers prioritizing simplicity without sacrificing scalability, this unified approach reduces operational friction significantly.

So, let's deploy our function!

Deploying Your First Function

Before writing code, set up your backend on Appwrite:

Go to appwrite.io and register or log in.
Create an organization (if new).
Create a new project.
Copy your Project ID for later use.

Now, let's simulate a server-side project using the node-appwrite package:

Create a project directory:

mkdir my-project  
cd my-project

Install the Appwrite CLI and initialize your project:

npm init -y  
appwrite init

Install dependencies:

npm install dotenv node-appwrite

Create your function using the Appwrite CLI:

appwrite init function

For the runtime, I selected Node 20, but you can choose any runtime.

Write your main function in src/main.js:

import dotenv from "dotenv";
import { Account, Client, Users } from "node-appwrite";

dotenv.config();

const client = new Client();
client.setEndpoint("https://cloud.appwrite.io/v1");
client.setProject(process.env.PROJECT_ID);

const users = new Users(client);
const account = new Account(client);

const main = async () => {
  await account.create(
    "test-user",
    "test@test.com",
    "test@123",
    "test",
  );
  const session = await account.createEmailPasswordSession(
    "test@test.com",
    "test@123",
  );
  console.log(session);
};

main();

Add a start script in package.json to run node src/main.js.
Create a .env file with the required environment variables.

This function simulates a new user creation and login, logging the session details.

Note: Replace the email IDs with actual emails to receive the email.

Now, let's set up the function logic. Navigate to functions/your-function where your function resides.

For this demo, we'll use Resend to send emails:

Install the resend package:

npm install resend

Update src/main.js with this code:

import { Resend } from 'resend';

// https://appwrite.io/docs/advanced/platform/events
export default async ({ res, req, log }) => {
  const resend = new Resend(process.env.RESEND_API_KEY);

  await resend.emails.send({
    from: 'hello@yourdomain.com',
    to: req.body.email,
    subject: 'Hello!',
    text: 'Hi, its nice to meet you!',
  });

  log('Email sent successfully');

  return res.json({
    success: true,
    message: 'Email sent successfully',
  });
};

You need to set up an account on Resend to get the API Key. Resend also requires you to connect to your own domain to send emails. You can read more about it on the Resend docs.

Now, let's push the created function to the console using:

appwrite push functions

The final step is to set up the event that connects the two pieces of code together using the users.*.create event:

Go to the Appwrite console and navigate to your created project.
Navigate to the Functions tab.
You should see your newly created function there—click on it.
Go to its settings and under the Events section.
Add a new event to trigger this function: users.*.create.

And... voila! Your program is done. If everything is set up correctly, running your main script should send the newly created user an invitation email. Try it using:

npm run start

Conclusion

In conclusion, serverless architecture is more than just a passing trend—it's a transformative approach to building and scaling modern applications.

Platforms like Appwrite further simplify the process, offering a unified backend solution that integrates seamlessly with serverless functions. Whether you're a solo developer like Bob or part of a larger team, adopting serverless can turn scalability from a daunting challenge into an effortless reflex.

Thanks for reading!

You can also connect with me here: https://www.chiragaggarwal.tech/

Architecture Patterns for Beginners: MVC, MVP, and MVVM

Chirag Aggarwal — Fri, 27 Dec 2024 20:22:17 +0000

Building software can be complex.

You might not have to think much about it when building your side project, but production software differs.

It can require multiple components, all of which if not handled correctly can lead to chaos.

But it doesn't need to be this complex. In today's article we will be delving into the world of architectural patterns, and discuss some divides your software into 3 simple components, each focusing on related tasks.

Architectural patterns

Whenever we are talking about architectural patterns in software design, the first ones to top the list include architectures like client-server, layered, monolithic, microkernel, even-driven, etc. These patterns are concerned with overall system architecture, including multiple applications, services, servers, etc.

However, MVP, MVC, and MVVM focus on organizing code within a single application by separating data, user interface, and logic. These are a subset of architecture patterns that focus on the overall system.

MVC, MVP, and MVVM

For the sake of keeping the blog readable and not exceeding the word length, we will focus on just the architectural patterns that organize the code within a single application, namely:

Model-View-Controller
Model-View-Presenter
Model-View-ViewModel

Clearly, all three models have two components fixed, i.e. the Model and the View. So let's first discuss them in detail before coming to each of the architecture.

Model

The model consists of all the code that is related to data present in the software. It's the layer for communication of the database and network layers with the rest of the application. Its main responsibilities include:

Handle data and business logic.
Encapsulate the application's data and the rules governing access to that data.
Handling data structures.
Performing CRUD (Create, Read, Update, and Delete) operations on data.

View

View is pretty much the front end of your application or everything that the user will be able to see and interact with. It's also known as the User Interface (UI) of your application. Its responsibilities include:

Handle non-business logic and purely presentational logic.
Present the data provided by other layers to the user.
Receive user input and forward it to other layers.
May or may communicate directly with the Model layer.

Model-View-Controller (MVC) Architecture

Now that we have an understanding of what Model and View layers do, let's take a look at individual architectural patterns.

Starting with MVC, it uses a Controller layer that communicates with both the Model and View layers.

It's main responsibilities of the controller include:

Manipulating data through the Model layer.
Receive instructions, aka the UI, from the View layer.
Update the View with changes defined due to control logic.

Here, although the View layer cannot directly interact with the Model layer, it can however receive updates based on changes in the data. Hence all three layers are connected to each other in some form, with the controller being the main component.

Model-View-Presenter (MVP) Architecture

Here, the Presenter layer assumes the functionality of the "middle-man" between the Model and View layers and handles all the communication between them. There is no communication at all between the Model and View layers directly.

Its responsibilities include:

Update the UI or the View layer based on user actions.
Update the data or Model layer based on code logic.
Handle much of the business logic that would be otherwise handled in the controller in MVC architecture.

Model-View-ViewModel (MVVM) Architecture

This architecture at first glance is almost identical to MVP architecture. But there are some key differences between them:

Multiple views can be mapped to a single ViewModel layer.
It uses data binding between the ViewModel layer and the View layer, making it more event-driven.
There is no concept of User Interface in this architecture. The View layer represents the actions of the user, not the interface.

Side by Side comparison

Aspect	MVC	MVP	MVVM
Full Name	Model-View-Controller	Model-View-Presenter	Model-View-ViewModel
Separation of Concerns	Basic	Better	Best
Data Flow	Two-way	One-way	One-way with data binding
View-Logic Relationship	Many-to-one	One-to-one	Many-to-one
Testability	Hard	Good	Best
Maintenance	Hard	Easy	Easy
Learning Curve	Easy	Easy	Harder
Performance	Can be slower due to tight coupling	Better performance with looser coupling	Smooth performance, especially for complex UIs
UI Updates	Controller updates View	Presenter updates View	ViewModel updates View through data binding
Dependency on UI Framework	High	Low	Low or no dependency
Scalability	Suitable for small-scale projects	Good for simple and complex projects	Ideal for large, data-heavy apps

But which is the most popular you might ask? All of them are equally popular architectures being used according to the company's respective requirements for a product. Some companies adopting these different architectures are:

MVC: StackOverflow, GoDaddy, Visual Studio website Dell
MVP: Google (for some Android apps)
MVVM: Apple (for some iOS apps using SwiftUI), Angular framework, Vue.js framework

Also, many companies use a mix of these architectures depending on the specific needs of each project or product. The choice of architecture often depends on factors such as the complexity of the application, the development team's expertise, and the specific requirements of the project.

Conclusion

This article covered the basics of architectural patterns, from how overall architecture is designed to how a single application can be further divided into three components for better management and scalability.

MVC, with its straightforward approach, remains popular for web applications.
MVP builds upon MVC's foundation, offering improved testability and a cleaner separation of concerns.
MVVM, the most recent of the three, has gained significant traction in modern application development.

There is no clear winner between them and each pattern offers unique advantages and is suited to different projects and development scenarios. As the software development landscape continues to evolve, we may see further refinements of these patterns or the emergence of new architectures altogether.

Want to learn more about the architectural patterns discussed? Here are some references I found helpful:

My Hackfrost Journey: Navigating Development Challenges with Daytona

Chirag Aggarwal — Thu, 05 Dec 2024 16:11:31 +0000

The Winter of Tech Innovation

As the crisp winter winds swept across India, the tech community buzzed with excitement. Hackfrost, a hackathon organized by the dynamic WeMakeDevs community—founded by the renowned tech educator Kunal Kushwaha—promised to be more than just another coding competition. This 48-hour virtual event was set to challenge developers, foster innovation, and bring together a diverse group of tech enthusiasts from across the country.

The Allure of the Challenge

When I first stumbled upon the hackathon announcement, it was the prize lineup that immediately caught my eye—a treasure trove that would make any developer's heart race:

Latest MacBook Pro
High-end Dell Monitor
Sleek iPad
Compact M4 Mac Mini
Premium Keychron Keyboards
An assortment of exclusive tech swag

But this wasn't just a simple giveaway. The competition had a unique twist: every project needed to incorporate Kestra, an open-source orchestration tool that was gaining significant traction in the developer community. What seemed like a constraint at first quickly transformed into an exciting opportunity for innovation.

Team Formation: A Community-Driven Approach

My journey began in the vibrant corridors of Quira, an open-source community that has been my technical home for quite some time. Networking has always been more than just collecting contact information—it's about finding passionate individuals who complement your skills and share your vision.

I was fortunate to connect with an incredible team:

K Om Senapati: A brilliant problem solver with a knack for backend architecture
Juanita: A frontend wizard with an eye for user experience
Chelsea: Our team's DevOps expert who understands the intricacies of cloud infrastructure

Our diversity was our strength. Each of us brought unique perspectives and skills to the table, transforming a potential challenge into an opportunity for collaborative innovation.

The Development Environment Dilemma

Any developer who has worked on a team project knows the pain of environment setup. It's a time-consuming process typically involving:

Endless configuration scripts
Dependency version conflicts
Complex environment variable management
Hours of synchronization between team members

This is where Daytona emerged as our unexpected hero. What would traditionally take days was reduced to mere minutes. The tool's ability to streamline development environments was nothing short of revolutionary for our team.

Development Container Configuration with Daytona

To ensure a consistent development environment, we leveraged Daytona's powerful configuration capabilities. Here's a step-by-step guide to setting up Daytona for our project:

Install Daytona: You can find the instructions specific to your OS on their website here.
Create Devcontainer Configuration
We crafted a detailed devcontainer configuration to standardize our development environment:

   {
       "name": "Flow Forge Development Container",
       "build": {
           "dockerfile": "Dockerfile",
           "context": ".."
       },
       "customizations": {
         "vscode": {
           "settings": {
             "terminal.integrated.shell.linux": "/bin/sh",
             "eslint.enable": true,
             "prettier.resolveGlobalModules": true
           },
           "extensions": [
             "esbenp.prettier-vscode",
             "dbaeumer.vscode-eslint",
             "ms-vscode.vscode-typescript-tslint"
           ]
         }
       }
   }

Add a Provider: We opted for a cloud provider due to low-spec configurations on some of our teammates' systems. Specifically, due to an abundance of Azure credits, we chose Azure using:

   daytona provider install

Running the Project: After pushing our devcontainer to the project repo, we can start the environment easily with:

   daytona create https://github.com/ChiragAgg5k/flow-forge --devcontainer-path=.devcontainer/devcontainer.json

Feedback and Reflections

While traditional development environments often feel like navigating a maze of configurations, Daytona emerged as a breath of fresh air. Its intuitive approach to setting up development environments was nothing short of revolutionary for our team.

Key Observations:

Simplicity: What traditionally took hours of manual configuration was reduced to a few command-line interactions.
Consistency: Every team member's environment was identical, eliminating the notorious "it works on my machine" syndrome.
Flexibility: The tool seamlessly handled different development setups, from local machines to cloud-based environments.

Cloud-Powered Development

Given my modest MacBook's specifications, we decided to leverage cloud computing. Daytona's seamless Azure integration was a game-changer. With just a few clicks, I added Azure as our cloud provider, and suddenly, our entire development ecosystem was accessible, consistent, and performant.

The magic of Daytona wasn't just in its simplicity, but in its ability to democratize development environments. Teammates with varying hardware could now collaborate effortlessly, breaking down technological barriers.

Architecting the GitHub Workflow Manager

Our project aimed to solve a real-world problem: simplifying GitHub workflow management using Kestra's powerful orchestration capabilities.

Technical Architecture

Frontend: Next.js, chosen for its server-side rendering and robust ecosystem
Orchestration: Kestra, running on an Azure VM
Authentication & Backend: Appwrite, providing a flexible Backend-as-a-Service solution

We implemented basic authentication to interact with the Kestra instance, allowing users to define, monitor, and execute complex workflows with unprecedented ease.

Key Features

Seamless GitHub workflow creation
Real-time workflow status tracking
Customizable workflow templates
Secure authentication mechanisms

Beyond the Competition

While the prize table remained unclaimed by our team, the true value of Hackfrost transcended material rewards. We had:

Learned cutting-edge technologies
Practiced collaborative development
Solved a tangible industry problem
Strengthened our professional network

Daytona's Impact: The development tool didn't just simplify our setup—it transformed how we think about collaborative coding.

Final Thoughts

Tech competitions are rarely about winning. They're about growth, learning, and pushing technological boundaries. Our Hackfrost journey exemplified this philosophy—a testament to the power of community, innovation, and the right tools.

To Daytona, Kestra, and the entire WeMakeDevs community: Thank you for creating spaces where innovation thrives.

Check out the live project here

For more information about me, checkout my Portfolio

How a Viral Tweet Landed Me Multiple Job Interviews

Chirag Aggarwal — Thu, 21 Nov 2024 04:39:59 +0000

We all enjoy using social media. In today's digital world, it’s nearly impossible to find someone who doesn’t. Social platforms wield immense power—capable of making someone famous overnight. However, such power has its downsides. Today, I’ll share how one casual tweet (or X, as it’s now called) turned my luck around and landed me multiple internship interviews when I was struggling to get any.

Background

Hi, I’m Chirag Aggarwal, a 3rd-year B.Tech CSE student at a tier-3 university in India. Like many in my situation, I was struggling to secure an internship, despite:

Two previous internship experiences
Multiple solid projects
A portfolio website
A CGPA of 9.71
And much more

At the same time, I was practicing DSA (Data Structures and Algorithms) daily. Although not always required for internships, I was targeting companies like Amazon, Google, Microsoft, and Goldman Sachs, where DSA knowledge is crucial.

The Tweet

One day, I realized I had completed 400 problems on LeetCode. Normally, this would be a moment of pride—a milestone to share on LinkedIn and celebrate. But instead of feeling accomplished, I was disappointed. Despite my constant effort, I felt unrewarded. So, I vented my frustration on Twitter:

When I posted it, I didn’t expect much. I often tweeted random thoughts, and this felt like just another one of them. But, as you can see from the numbers above, it was anything but ordinary.

Soon, my phone started buzzing... and it didn’t stop. Thousands of people joined the conversation.

The Reactions

The responses to my tweet generally fell into three categories:

Struggling comrades who empathized and shared similar struggles.
Critics who blamed me for focusing on DSA instead of development.
Supporters who offered genuine help and advice.

Struggling Comrades

The first category overwhelmed me. I was shocked to see so many talented individuals facing the same struggles. It felt like the entire industry was filled with people like me—working hard and still not seeing results.

Here’s one response that really stood out:

Critics

This was, unsurprisingly, the largest group. Due to the viral nature of my tweet, many people jumped to conclusions and shared similar critiques:

(Thanks, Rohan. Really appreciated that last one! 😅)

Most critics suggested I focus on projects and development instead of just DSA. Ironically, that’s exactly what I’d been doing for a long time. I’ve always enjoyed development more than solving DSA problems, contributing to open source, and building amazing stuff.

Still, I understood their perspective. If I saw someone only doing DSA without focusing on development, I might have left a similar comment.

Supporters

This was my favorite category. Although smaller, it was still more support than I’d ever expected. These tweets genuinely lifted my spirits:

These words reminded me that I was on the right track and just needed to keep pushing forward.

What Happened Next?

I got calls. Emails. Offers.

The viral tweet brought me visibility—a crucial factor in landing interviews. I had a few rounds with different companies, but in the end, I accepted an offer that didn’t even require a formal interview. After an introductory call and a basic assignment, I was handed the offer letter.

This happened thanks to one person:

(Thanks a lot, Teja!)

Conclusion

I wish I had a concrete lesson or formula to share, but this journey was a rollercoaster sparked by one lucky tweet.

If there’s one takeaway, it’s this:

Be active on social media. Build in public. Share your creations, passions, and energy with the world.

Luck favors those who are ready to take advantage of it.

Check out my portfolio: chiragaggarwal.tech

Feel free to reach out if you want to discuss anything!