DEV Community: Hrishikesh Dalal

Dawai-Dost: A Private, Local Medicine Companion

Hrishikesh Dalal — Wed, 14 Oct 2026 14:06:50 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Dawai-Dost ("medicine friend") is a local-first app for families who look after elderly parents or grandparents. It does three things:

Reads the prescription. Photograph a doctor's handwritten or printed prescription. A vision-language model extracts each medicine, dose, timing and duration, and turns it into a simple daily schedule in English, Hindi or Marathi with large, readable text.
Remembers the history. Every prescription, refill and reported symptom is stored in a small on-device database, so the app builds a medication timeline for each family member.
Predicts and flags, using that history.
- Refill prediction: "Amlodipine runs out in 4 days. Order now."
- Missed-dose patterns: "Evening doses are missed 3 days out of 7."
- Change summaries: "This new prescription adds a medicine that was not in the last 3 visits."
- Interaction checks: it flags when two medicines from different doctors may clash, and tells you to confirm with a pharmacist.
- A one-page visit summary to hand to the doctor, so a 10-minute consultation is not spent trying to remember what changed.

Who would pay: families with elderly parents, especially adult children living in a different city, and small pharmacies or clinics that want to offer a "prescription companion" to regular patients. The problem is real. Prescriptions are hard to read, parents take medicines from several doctors, and nobody has a clear view of the whole picture. A family would reasonably pay a small monthly fee, roughly the price of a single doctor consultation per year, for peace of mind.

Safety note: Dawai-Dost is an assistant, not a doctor. Every output carries a "confirm with your doctor or pharmacist" notice, and low-confidence extractions are highlighted for human review instead of being guessed.

Code

Core of the pipeline:

import ollama, json, sqlite3
from datetime import date, timedelta

PROMPT = """Read this prescription image. Return ONLY JSON:
{"medicines":[{"name":"","dose":"","times":["morning|noon|night"],"days":0,"confidence":0.0}]}
If text is unclear, lower the confidence. Never guess."""

def read_prescription(image_path):
    r = ollama.chat(model="qwen2.5vl:7b",
        messages=[{"role": "user", "content": PROMPT, "images": [image_path]}])
    return json.loads(r["message"]["content"])["medicines"]

def save(db, patient, meds):
    for m in meds:
        db.execute("INSERT INTO rx(patient,name,dose,times,start,days) VALUES(?,?,?,?,?,?)",
                   (patient, m["name"], m["dose"], ",".join(m["times"]),
                    date.today().isoformat(), m["days"]))

def refill_alerts(db, patient, within=5):
    rows = db.execute("SELECT name,start,days FROM rx WHERE patient=?", (patient,))
    return [f"{n}: runs out {(date.fromisoformat(s)+timedelta(days=d)).isoformat()}"
            for n, s, d in rows
            if date.fromisoformat(s) + timedelta(days=d) <= date.today() + timedelta(days=within)]

def history_insight(db, patient):
    hist = db.execute("SELECT name,dose,start FROM rx WHERE patient=? ORDER BY start", (patient,)).fetchall()
    q = f"Summarise changes across this medication history and flag possible interactions. Be cautious, advise confirming with a pharmacist: {hist}"
    return ollama.chat(model="llama3.1:8b", messages=[{"role": "user", "content": q}])["message"]["content"]

How I Built It

Everything runs on the user's own machine or a small home server, with no cloud AI calls.

Vision model: Qwen2.5-VL (open-weight), served with Ollama. It reads the prescription photo and returns structured JSON. Each medicine gets a confidence score, and anything below a threshold is shown to the user as "please verify" rather than silently accepted.
Reasoning model: Llama 3.1 8B (open-weight), also via Ollama. It writes the plain-language schedule in English, Hindi or Marathi, and turns the stored history into summaries and cautious interaction notes.
Storage: SQLite. One small file holds every prescription, refill and dose log.
Prediction layer: simple, transparent logic. Refill dates come from start date plus days supplied. Missed-dose patterns come from counting skipped reminders by time of day. I kept this rule-based on purpose. Predictions about health should be explainable, and the LLM only turns the numbers into readable language.
Interface: a lightweight web UI with large fonts, plus an optional WhatsApp-style reminder flow for parents.

Design choice: the LLM never decides anything medical on its own. It extracts and explains. Dates and alerts come from deterministic code, and risky outputs always point the user back to a doctor or pharmacist.

Why Does Open Innovation Matter?

Privacy is the product. Prescriptions and medication history are some of the most sensitive data a family has. With open-weight models running locally, that data never leaves the device. With a closed API, every photo would be uploaded to someone else's servers. For a health tool, "your data stays on your machine" is the main reason people would trust and pay for it.
The economics work. A family uploads many prescription photos and gets daily summaries and reminders. Per-image and per-token API pricing would turn that into a recurring cost that grows with every user. Local inference has a flat cost, so a low monthly price still leaves a margin.
Niche fine-tuning. Indian prescriptions are messy: abbreviations like "1-0-1", mixed English and Hindi, and doctor handwriting. Open weights can be fine-tuned on these patterns and on regional-language output, which a general-purpose closed API handles inconsistently.
No lock-in. If a model is deprecated or a vendor changes its pricing or policy, a health product built on it breaks. With open weights, I can swap in a better model, pin a version that is known to be reliable, and keep the app working for years.
Works offline. It still works in areas with poor connectivity, which matters for elderly users and smaller towns.

Prize Categories

None

Where does my mind wonder?

Hrishikesh Dalal — Fri, 09 Oct 2026 16:01:10 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Building an open source AI Powered, Social and Outing finder. Works without any net, so no matter where you are - ALWAYS HAS YOUR BACK! The best part about this is that it learns more about you as you interact with it.

It is hyper-personalised so that more you interact with it more it knows about you, better it can recommend what you should do / go out for what mood.

If you are sad -> Give you comforting places
If you are energetic -> Recommends you outdoor activities as per your hobbies
If its end of the month & you have a tight budget -> Recommends you pocket friendly options

Demo

Couldn't get time to make a demo or a deployed link:(

Code

Still in the building process, will update once completed!

How I Built It

The workflow goes like:

Spatial Ingestion & Candidate Retrival
We first fetch the geo-spatial co-ordinates from the users device.
The client transmits (latitude, longitude) along with device state metadata. The backend executes a geospatial query fetching candidate POIs within a specified radius ($r$).
Semantic Context Synthesis
After we have our candidate, we fetch the users past records. The candidate venues are merged with the users vector embeddings. A lightweight ranker scores candidate POIs based on proximity, ambient context (time of day, day of week), and user activity history.
Inferenced Structured Generation
Find the top-k spots and give our what the candidate actuals has based on the intersection of the user likings, mood, budget & location.
User provides Feedback
Simple thumbs up thumbs down to tell if the LLM has worked properly or not.

Used Gemma 4 for building this interface. Further used the SERP API to get the locations and the surrounds activities. Used Mongo DB for vector embeddings.

Why Does Open Innovation Matter?

People would only go out if there is something in it for them. This can be the activities that they like doing. If we give them something that is way difficult or requires a lot of extra effort without a reward then they won't do it.

And why make this open source?

More users can improve this and we can get to what we want to do for free rather than spending just to figure out what we want to do. Closed APIs would incur cost and that eventually comes down to the user.

I love reading psychology too!

Prize Categories

None, I have not submitted code yet. Will update this when I submit the code.

Brutalist House: A 3D Spatial Wall & Local AI Color Palette Inspector

Hrishikesh Dalal — Fri, 02 Oct 2026 12:37:50 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built Brutalist House—a local AI-powered interior color palette generator and interactive 3D spatial room inspector.

I built this for a friend who is an interior design enthusiast and architect. They love brutalist architectural aesthetics—unprocessed concrete bases, raw functional zoning, and high-visibility accent pops—but constantly struggled to visualize how a 4-color palette translates onto actual 3D walls in a room. Plain HEX swatches on a flat screen just don't tell you how a room will feel when light hits specific surfaces.

Brutalist House solves this problem by taking local AI-generated color palettes (powered by Gemma 4 via Ollama) and applying them directly across:

An Interactive 3D Room Box Inspector: View each room (Living Room, Bedroom, Kitchen, Bathroom) as an interactive 3D box. Rotate the camera along $X$ and $Y$ axes, inspect individual walls (North, East, South, West, and Floor), and reassign specific colors to individual walls on the fly.

A 2D Architectural Floorplan: A high-contrast SVG plan view showing scale, room transitions, furniture accents, and door swings.

Automatic Local Storage History: Saves every generated palette and wall configuration locally so my friend can switch back and forth between design iterations with a single click.

Demo

GitHub Repository: Painting

Code

Below is a snippet of how the 3D Spatial Box handles pure CSS 3D matrix transforms and per-wall color assignments without requiring heavy external 3D engine bundles:

<div 
  className="relative w-[280px] h-[220px] transition-transform duration-300 ease-out"
  style={{
    transformStyle: 'preserve-3d',
    transform: `rotateX(${tiltX}deg) rotateY(${rotationY}deg)`
  }}
>
  {/* NORTH WALL */}
  <div 
    onClick={() => setSelectedWall('north')}
    className="absolute inset-0 border-4 flex flex-col items-center justify-center cursor-pointer"
    style={{
      backgroundColor: currentRoomWalls.north,
      borderColor: colors.primary,
      transform: 'translateZ(-140px) rotateY(180deg)',
    }}
  >
    <span className="text-xs font-black uppercase bg-white px-2 py-1 border border-black">NORTH WALL</span>
  </div>

  {/* FLOOR */}
  <div 
    onClick={() => setSelectedWall('floor')}
    className="absolute w-[280px] h-[280px] border-4 flex flex-col items-center justify-center cursor-pointer"
    style={{
      backgroundColor: currentRoomWalls.floor,
      borderColor: colors.primary,
      transform: 'translateY(70px) rotateX(90deg)',
    }}
  >
    <span className="text-xs font-black uppercase bg-white px-2 py-1 border border-black">FLOOR</span>
  </div>
</div>

How I Built It

Local Open-Weight AI Model: Powered by Gemma 4 running locally through Ollama (/api/ollama). The model acts as the "brutalist design consultant," returning structured JSON containing color variables (background, primary, secondary, accent) and an architectural design rationale.
Frontend Framework: Built with Next.js (App Router), TypeScript, and Tailwind CSS.
3D Engine: Implemented using pure CSS 3D transforms (perspective, preserve-3d, rotateX, rotateY, translateZ) to deliver fluid 60FPS room rotations without adding heavy 3D library dependencies.
Persistence Layer: Integrated standard localStorage pipelines so that custom wall color tweaks and past palette history persist seamlessly across sessions.

Why Does Open Innovation Matter?

Local-First Privacy & Zero Vendor Lock-in: Design concepts, room ideas, and creative prompts stay 100% on the user's local machine. Running open-weight models like Gemma 4 via Ollama ensures complete data ownership.
Zero API Costs & Unlimited Iteration: Traditional proprietary APIs charge per token, making rapid palette generation and real-time prompt experimenting costly. Open-weight inference allows infinite generation cycles without rate limits or subscription paywalls.
Fine-Tuned Control: Open models allow developers to inspect, fine-tune, and customize prompt structures directly, tailoring responses to niche aesthetic movements (like brutalism or minimalism) without closed-system alignment filters over-sanitizing creative output.

Prize Categories

Build for a Friend
Best Use of Local AI / Open Weights (Gemma & Ollama)

Drupal x Google Summer of Code - Week 3: Reuse & Previews

Hrishikesh Dalal — Tue, 07 Jul 2026 07:17:42 +0000

WELLLLCOMMEE to Week 3 of this series!

In the last week made quite a few structural changes that will help us. Have created the YAML extractor and parser which can extract the YAML component form any response of the LLM using Symfony to validate it. Made a Utility for this thereby making the code reusable.

Official Issue Tracker: Week 3 Tracker

Let me now give me glimpse for this.

https://www.youtube.com/watch?v=7sH6pv2Vyns

The Output Preview & Validator

Tiny UI Changes

Time to Dive Deep into this

YAML Validator & Extractor

Created a Utility folder under src and created a file named Yaml Processor. The concept of this file was simple, when you get an output from LLM, from whichever Service or Function you pull this from this will extract the YAML and give it to you.

Here it uses this : use Drupal\Component\Serialization\Yaml

This under the hood uses Symfony which helps to validate and extraction. Symfony is the underlying PHP framework that powers modern Drupal ( this is just one of the usecase)

<?php

namespace Drupal\ai_recipe_generator\Utility;

use Drupal\Component\Serialization\Yaml;

/**
 * Utility class to parse and extract YAML from AI responses.
 */
class YamlProcessor {

  /**
   * Cleans a response down to YAML text when possible.
   *
   * @param string $response
   *   The raw model response.
   *
   * @return string
   *   A normalized YAML string or the response with code fences removed.
   */
  public static function normalize(string $response): string {
    $parsed = self::extractAndParse($response);

    if (is_array($parsed)) {
      return trim(Yaml::encode($parsed));
    }

    $cleaned = preg_replace('/```

(?:yaml|yml)?\s*|

```/i', '', $response) ?? $response;
    return trim($cleaned);
  }

  /**
   * Attempts to extract and validate YAML from a given string.
   *
   * @param string $response
   *   The raw string response.
   *
   * @return array|null
   *   The parsed YAML as an array, or null if no valid YAML could be extracted.
   */
  public static function extractAndParse(string $response): ?array {
    // First try parsing the entire response as YAML.
    try {
      $parsed = Yaml::decode($response);

      if (is_array($parsed)) {
        return $parsed;
      }
    }
    catch (\Exception $e) {
      // Not valid YAML, continue with extraction.
    }

    // Extract YAML from markdown code blocks.
    $pattern = '/```

(?:yaml|yml)?\s*(.*?)

```/is';

    if (preg_match($pattern, $response, $matches)) {
      $yaml = trim($matches[1]);

      try {
        $parsed = Yaml::decode($yaml);

        if (is_array($parsed)) {
          return $parsed;
        }
      }
      catch (\Exception $e) {
        return NULL;
      }
    }

    return NULL;
  }

}

Reusable YAML Previewer

If you have seen my previous blog, the older YAML previewers they were not upto the mark. So improved that with having better parsers and lines. What I used for this was a template, using a html.twig format which helped to render properly anywhere, anyhow!

This is slightly difficult to think and then implement (tedious slightly) but since highly reusable, highly useful!

{#
/**
 * @file
 * Template for the fluid YAML previewer component with line numbers.
 */
#}
<div class="ai-yaml-preview-container" {{ attributes }}>
  <div class="ai-yaml-preview-header">
    <span class="ai-yaml-preview-title">{{ title|default('YAML Output Preview') }}</span>

    <button class="ai-yaml-copy-btn" onclick="
      const container = this.closest('.ai-yaml-preview-container');
      const code = container.querySelector('code').innerText;
      navigator.clipboard.writeText(code);
      const originalText = this.innerText;
      this.innerText = 'Copied!';
      setTimeout(() => this.innerText = originalText, 2000);
    ">Copy YAML</button>
  </div>

  <div class="ai-yaml-preview-body">
    {# This empty div will be filled with numbers by the JS below #}
    <div class="ai-yaml-line-numbers" aria-hidden="true"></div>

    <pre class="ai-yaml-preview-content"><code class="language-yaml">{{ yaml_string }}</code></pre>
  </div>
</div>

{# Inline script to generate line numbers based on the code length #}
<script>
  (function() {
    // Find all preview containers on the page
    const containers = document.querySelectorAll('.ai-yaml-preview-container');

    containers.forEach(container => {
      const codeBlock = container.querySelector('code');
      const linesContainer = container.querySelector('.ai-yaml-line-numbers');

      // Only process if it hasn't been filled yet
      if (codeBlock && linesContainer && linesContainer.innerHTML === '') {
        // Split by newline to get total lines
        const lines = codeBlock.innerText.split('\n');

        // Handle the case where the AI leaves a trailing empty line at the end
        const lineCount = lines[lines.length - 1] === '' ? lines.length - 1 : lines.length;

        let numbersHTML = '';
        for (let i = 1; i <= Math.max(1, lineCount); i++) {
          numbersHTML += i + '<br>';
        }
        linesContainer.innerHTML = numbersHTML;
      }
    });
  })();
</script>

Code Reduction

Let's understand the problem, we had 3 files for calling the LLM models & providers. All of them had separate functions. So if I ever wanted to change anything, I would have to change in all the three files : (

So we changed the calling part. for 2 (ArenaService & RecipeGenerationService) of them as they were the same replicas the third one at BenchmarkDashboardService was a different one. Clubbing them was fairly simple, just had to change the function calls.

Started fixing the Pipeline

Did the cspell checking and then the phpcs checking which was initially failing but then started fixing the same. For fixing the cspell introduced a file called: .cspell.json. This needed to have all the words in the document which I wanted to exclude form the checking.

Will write a separate blog on testing!

{
    "version": "0.2",
    "language": "en",
    "words": [
        "ai_recipe_generator",
        "chartjs",
        "crosshairs",
        "dalal",
        "fontawesome",
        "hrishikesh",
        "llm",
        "llms",
        "multichat",
        "onclick",
        "Starshot",
        "tempstore",
        "unconfigured",  
        "xaxis",
        "xmark",
        "yaml",
        "yaxis"
    ],
    "ignorePaths": [
        "vendor/**",
        "node_modules/**",
        "*.min.js",
        "*.min.css"
    ]
}

Thank you & catch you up next time!

Follow me at https://www.linkedin.com/in/hrishikeshdalal/
Portfolio: https://www.hrishikeshdalal.dev/
Alt Portfolio: https://hrishikesh-dalal.vercel.app/

Google Summer of Code (GSoC) x Drupal: Week 2 - Mapping the Dashboards

Hrishikesh Dalal — Tue, 07 Jul 2026 07:09:11 +0000

WELCOMMMEEEE to another episode of Weekly Recap of my project

This week we have built two things: LLM Benchmarking Dashboard & LLM Arena to show you which ones are the best. Both of these will be super useful while building our final product.

The Offical Issue Tracker: Week 2 Issues Tackled
Let me give you a glipmse of what our output will look like.

https://www.youtube.com/watch?v=FWhz2f81urQ

Dashboard (Part 1)

Dashboard (Part 2)

The Benchmarking Dashboard

In order to capture the true essence of which model performs the best in the long run, had made a LLM benchmarking dashboard. Someone just by looking at charts can capture which model is most suitable for their usecase.

Metrics that provided the overall picture

1). The Top Banner: It had the total runs so far, along with the average response time and the average accuracy for the recipe generated.

2). The Visuals: Any dashboard is incomplete without a good visual. The first graph which shows the latency for the previous runs mapped across models is useful for finding the trend for model hits. The second graph is for using a bar graph for visualising the model avg. latency to compare which model is the faster as compared to others. Used the Chart module for the same.

3). Key Metric Table: This is the detailed table for per prompt summary. It covers: the provider, the model, the speed, whether the YAML is valid or not, whether the Schema proper or not as per Drupal Symfony, & finally tells us about the accuracy along with timestamps.

What is useful in this is that you can filter it along with sort the columns in ascending or descending order. Is if further colour coded so that you can quickly view the page at a glance.

Things I used to build this:

Chart.js / Drupal Chart Module: To render the responsive, interactive graphs.
Custom Database Schema (.install): To reliably save and query the historical benchmarking data.
Drupal AJAX API: To ensure the table filters and dynamic sorting update seamlessly.
Font Awesome Library: To have cool icons in the dashboard

LLM Arena

The LLM Arena

This was particularly fun to build as this was for comparing the different responses. You get to type the custom prompt and then fire it across all the different models and providers.

You can have all the different models & providers, there is NO LIMIT!!

Further these is also an option to store the responses in the database so that they reflected in the schema. There is also a delete button for the same. If you want to remove some model-provider. Further you will see a very familiar screen that, while firing the prompts, it will look like new module install screen, this is because of the Batch API Screen.

Sources I used:

AJAX API: Model - Provider dropdown
Batch API: For firing all the prompts together
Font Awesome Icons: For the icons there

Laying out the Structure

*System Diagram *

Just like a good Drupal Practice (have to mention), have used AI to generate the image above.

1. Client (User Browser) Layer

Handles the user interface and visual presentation.

User (Arena/Dashboard Interface): Renders the comparison forms, interactive data tables, and metrics dashboards.
Frontend Components:
JavaScript: Uses Chart.js to render interactive line and bar charts for model latency trends.
Icons: Integrates Font Awesome for immediate visual cues (success/failure statuses).
CSS: Uses css/arena.css and css/dashboard.css via .libraries.yml for custom, polished layouts.
Client-Server Communication:
AJAX API: Controls non-blocking form updates, dynamic filtering, and column sorting without page reloads.
Batch API (Client-Side): Drives the real-time progress bar (similar to the module installation screen) during execution.

2. Drupal Application Logic Layer

The PHP backend that processes requests and orchestrates module logic.

Form API (ArenaForm.php, BenchmarkDashboardForm.php): Handles form submissions and handles backend execution triggers.
Services Layer (ArenaService.php, BenchmarkDashboardService.php): Houses decoupled, reusable core logic registered via ai_recipe_generator.services.yml.
API Integration Engine:
Drupal Batch API: Splits concurrent LLM requests into isolated chunks to prevent gateway timeouts and server lockups.
Drupal AJAX API: Manages seamless, lightweight data passing between backend services and frontend components.

3. Data & External Integrations Layer

Manages persistent storage and outbound network requests.

Local Database (.install): Uses a custom schema defined in the install file to save historical run stats, latency, timestamps, and schema validation flags.
External LLM APIs: Handles outbound calls to external models (OpenAI, Anthropic, Gemini). Isolated by the Batch API so a timeout on one provider doesn't crash the session.

Thanks a lot for reading!!

Follow me at https://www.linkedin.com/in/hrishikeshdalal/
Portfolio: https://www.hrishikeshdalal.dev/
Alt Portfolio: https://hrishikesh-dalal.vercel.app/

Drupal x GSoC: Week 1 - Building the Base

Hrishikesh Dalal — Tue, 07 Jul 2026 07:02:24 +0000

WELLLLLLCOMMEE To Week 1 of GSoC x Drupal.

Over the first week my focus was on establishing a proper base for the project. This was particularly fun as you can see your project come to life. These are some other chapters of the journal that you should definitely read!

I created a project: Creating a Module Project on Drupal (NO CODE) (With BONUS Section)

I learnt about PIRLS - Drupal's Core .yml files

Before you proceed any further, you should have a drupal project set up. If not, you can check it out here: Installing Drupal

Have added a bit more changes too, you can check it our here: Week 1 Official Tracker

https://www.youtube.com/watch?v=2IcKTPBoyqc

Week 1 Issues Tackled

Let's zoom out and see what we have built. UI might not be that great yet but that was not the focus of the first week.

You should clone the basic repo of the module and paste it in: web/modules/custom/ai_recipe_generator.

You might need to create this folder & add all the files. We use custom as we haven't made a deployment of the project yet. So once I did this I made. Now I have added ai_recipe_generator.info.yml, ai_recipe_generator_services.yml, ai_recipe_generator.routing.yml. I have made a blog on these files and what do these mean, you can check that out too.

I then created 2 things in src folder - Form & Services.

So we have two pages as you saw above. Let's understand the routing or the file urls

Our File Structure

ai_recipe_generator.test_form:
  path: '/admin/config/development/ai-recipe-test'
  defaults:
    _form: '\Drupal\ai_recipe_generator\Form\RecipeGeneratorTestForm'
    _title: 'AI Recipe Generator (Test UI)'
  requirements:
    _permission: 'administer site configuration'

ai_recipe_generator.settings:
  path: '/admin/config/ai-recipe/settings'
  defaults:
    _form: '\Drupal\ai_recipe_generator\Form\SettingsForm'
    _title: 'AI Recipe Generator Settings'
  requirements:
    _permission: 'administer site configuration'

Each entry has the following

1 The URL Path

2 The Form File which it should render

3 The title of the Page

4 Permission Requirements

We have dependecies as well. This module as of now depends on the AI Module, Gemini Provider Module as well as the Key Module for managing all the keys. You have to install and enable all these modules for the AI Recipe Generator to function. This is actually cool as we are using the Drupal Ecosystem to do our tasks.

Flow Diagram

Phase 1: The Setup (Settings Form)

Before a user can generate a recipe, an administrator sets the rules.

Setting the Ground Rules: An admin visits the "AI Recipe Generator Settings" form and enters the System Instructions (e.g., "You are a senior Drupal developer...").
Saving to the Database: When the admin clicks "Save configuration," Drupal uses its configuration service (@config.factory) to safely store these instructions in the database for later use.

Phase 2: The User Request (Test UI Form)

This is where the actual generation happens.

User Input: A user opens the "AI Recipe Generator (Test UI)" form. They select their preferred AI Provider (like Gemini) and type exactly what they want to build into the Recipe Prompt box.
Triggering the AJAX Call: The user clicks the Generate Recipe button. Instead of reloading the whole webpage, the browser sends a quiet, background message (an AJAX Request) to the Drupal server containing the user's prompt and their chosen AI provider.

Phase 3: The Backend Brain (Drupal Services)

Once Drupal receives the AJAX request, it hands the work over to the custom services defined in your .yml file.

Gathering the Pieces: The main service (RecipeGenerationService) goes to work collecting three crucial pieces of information:
The Rules: It pulls the saved "System Instructions" using @config.factory.
The Context: It asks the ContextExtractor service to pull any relevant background information about your specific Drupal site.
The Request: It takes the user's specific "Recipe Prompt" from the AJAX call.
Talking to the AI: The RecipeGenerationService combines the rules, the context, and the user's request into one massive prompt. It then uses the @ai.provider service to send this combined package over the internet to the external AI (e.g., Gemini).

Phase 4: The Result (AJAX Response)

Receiving the Recipe: The external AI processes the prompt, generates the Starshot Recipe YAML file, and sends it back to your Drupal server.
Updating the Screen: Drupal packages this generated recipe into an AJAX Response and sends it back to the user's browser. The browser reads this response and instantly displays the new recipe on the screen, completing the process without ever forcing the user to refresh the page.

Adding your first piece of code to Drupal Project!

Hrishikesh Dalal — Tue, 09 Jun 2026 02:33:54 +0000

Setting up the codebase on Drupal is EASY! Only you need a little bit of patience. Let's dive deep into it.

So previously we had set up a project. Now we are going to initialise the git repo and add a few changes. First if you have created your project, you can move on into the Version Control section. This will contain instructions of what we should do further.

This was my link: Version Control

Version Control

mkdir ai_recipe_generator

cd ai_recipe_generator

git init

git checkout -b 1.0.x

echo "AI Recipe Generator" > README.txt

git add README.txt

git commit -m "Initial commit."

git remote add origin git@git.drupal.org:project/ai_recipe_generator.git

git push origin 1.0.x

They are the explicit instructions of what we are going to do.

Copying without understanding is useless. Let's go through each step one by one.

Command	What it does	Why we do it
`mkdir ai_recipe_generator`	Creates a new directory named `ai_recipe_generator`.	Allocates a dedicated local space for your project files.
`cd ai_recipe_generator`	Moves your terminal path into the new folder.	Ensures all future commands execute inside the project context.
`git init`	Initializes a hidden local `.git` repository.	Turns the plain folder into a version-controlled project.
`git checkout -b 1.0.x`	Creates and switches to a new branch named `1.0.x`.	Bypasses standard `main`/`master` to match Drupal's release branch rules.
`echo "AI..." > README.txt`	Generates a `README.txt` file with project text.	Creates an initial asset to track, as Git cannot track empty folders.
`git add README.txt`	Stages the file to the Git index.	Explicitly marks the new file to be included in the next snapshot.
`git commit -m "Text"`	Saves the staged file with a historic log message.	Establishes the official baseline/first snapshot of your codebase.
`git remote add origin <url>`	Links your local Git setup to the Drupal.org repository.	Establishes the secure target destination path on Drupal's servers.
`git push origin 1.0.x`	Uploads the local branch and commit to the server.	Publishes your code online so your mentors can access and review it.

Post this we had committed 3 more files of out own, which are equally crucial for the module development.

1 ai_recipe_generator.module.info

2 composer.json

3 .gitignore

Resources

Module Creation & .info.yml Documentation Creating Custom Modules (Main Hub): This is the central landing page for all module development tutorials in modern Drupal, covering everything from routing to creating custom blocks.

Defining the .info.yml File: This page provides the exact specifications, required properties, and core version requirement syntax for your module's metadata.

Composer Documentation for Modules Adding a composer.json File to a Module: This explains exactly why and how to add a composer.json file to your custom or contributed module, including the composer init steps specifically tailored for Drupal package types.

name: AI Recipe Generator
description: Creates recipes using AI.
package: AI

type: module
core_version_requirement: ^10.5 || ^11.2

dependencies:
  - ai:ai

{
    "name": "drupal/ai_recipe_generator",
    "description": "Creates recipes using AI.",
    "type": "drupal-module",
    "license": "GPL-2.0-or-later",
    "authors": [
        {
            "name": "Hrishikesh Dalal",
            "email": "204620-hrishikesh-dalal@users.noreply.drupalcode.org"
        }
    ],
    "require": {}
}

Somewhere where I struggled and made mistakes

If you have seen the video, you would know I had made a mistake initializing the git repo 😅. I made a commit to the main brand before setting up the 1.0.x which is crucial for creating forks and deployments. Well it sucked but it was a great source of learning.

Understanding the Concept of Remote in Git

Git Remote

Think of Git Remotes as a Cloud Backup or a Shared Office.

Imagine you are writing a book on your own private desk at home (Local Repository). You can write, delete, and organize pages however you want.

However, your publisher and co-authors are in a different building. To show them your work, you have a Shared Drafting Table (Remote Repository) in their office.

1. A "Remote": It's just a bookmark or a "saved contact" in your computer's address book that tells Git exactly where that Shared Table is located on the internet.

2. Origin: This is just the default nickname for that Shared Table. (But you could call it anything, backup, publish etc)

Managing Remotes: The Commands

Sometimes you need to change where your code is going (e.g., commit to a different fork or repository).

1. Check your current remotes

Before changing anything, see where your project is currently "talking" to.

The -v stands for "verbose." It shows you the URLs for fetching (downloading) and pushing (uploading).

git remote -v

2. Change a remote's URL

If the server location changes, but you want to keep the same nickname (origin), use this command:

git remote set-url origin https://git.drupalcode.org/issue/ai_recipe_generator-3592994.git

When to use: Use this if you accidentally typed the wrong URL during setup or if the project moved to a new server.

3. Add a second remote

You can have more than one! You might have one for a private backup and one for the public Drupal project.

git remote add backup https://git.drupalcode.org/issue/ai_recipe_generator-000001.git

Rename a remote

If you don't like the name origin and want to call it something else: (here drupal_server)

git remote rename origin drupal_server

5. Remove a remote

If you want to cut ties with a specific server:

git remote remove backup

Pro-Tip: If you ever get an error saying "Remote origin already exists," it means your project is already linked to a server. Use set-url to update it instead of add.

Eventually....

So after taking a short detour, we finally pushed our initial code to gitlab! 🎉🎉

Final Code Push

Follow me: https://www.linkedin.com/in/hrishikeshdalal/

My portfolio: https://hrishikeshdalal.tech/

Creating a Module Project on Drupal (NO CODE) (With BONUS Section)

Hrishikesh Dalal — Mon, 08 Jun 2026 07:51:00 +0000

Hey there!

Welcome to my GSoC journey where in I am going to take you through an adventure of events. This blog is for the Level 1. Or rather I should saying learning about how to "make the dish". We are going to create our very own Drupal Module Project!!

I will also append a Youtube link for the same if it does suit you better. Lets get into it!

Step 1: Understanding what all types of Projects you can create

When you head over to this site for project creation - Drupal Project Create. You will have 4 options.

Drupal offers a few different project types:

1. Module project: Contains PHP code that extends Drupal or adds new features.

2. Theme project: Changes the look and feel of a Drupal site.

3. General project: Contains code, but isn't a module, theme, or specific type.

4. Community project: Non-code projects used to manage groups or camps.

Since our aim is to build an AI Recipe Generator that adds brand-new functionality to the site, selecting the Module project was the clear choice.

Types of Drupal Projects

Step 2: Have Git on your computer

The absolute bare minimum as all the code changes everything should be done by this. But if you reading this and are a techie, you must already be having git : )

Step 3: Creating a project

Now when you go over this link: Project Creation, you will have a ton of options. Let us go through each one of them one by one.

Drupal core: The foundational software that runs the entire Drupal platform.
Distribution project: An all-in-one starter kit that bundles Drupal with pre-selected features to quickly launch a specific type of website.
Community project: An organizational space for managing Drupal groups, events, and people rather than website code.
General project: A catch-all category for miscellaneous code, tools, and libraries that don't fit into the standard module or theme categories.
Module project: A functional plugin that adds new features or changes how your website works.
Theme project: The design package that controls the colors, layout, and overall visual appearance of your website.
Theme Engine project: The behind-the-scenes system that translates your theme's visual design into something the Drupal platform can understand.
Translation project: An outdated archive for language translations, which are now managed on a separate, dedicated website.

Step 4: The Nitty Gritties

All the things you can do in a snap

Now when you go to the next page, there is this huge form that you need to fill. Let me take you across each filed one by one.

The Basic Identity

Name: AI Recipe Generator

What it is: The project's human-readable title.
Why I chose it: It clearly tells users exactly what the tool does right away.

Short name: ai_recipe_generator

What it is: The machine-readable system name used for URLs and codebases.
Why I chose it: It matches the readable name using standard Drupal convention (lowercase and underscores) for consistency.

Project type: Full project

What it is: Defines if it's a temporary "Sandbox" or an official "Full project."
Why I chose it: To get end-to-end control and official release packaging for this GSoC module.

Status and Classification

Maintenance status: Actively maintained

What it is: Shows the community how much attention the project gets.
Why I chose it: I will be actively monitoring, updating, and managing this code for the next 12 weeks and beyond.

Development status: Under active development

What it is: Indicates the codebase's current maturity.
Why I chose it: The module is currently being built from the ground up and evolving daily.

Module categories & Ecosystem: Artificial Intelligence (AI)

What it is: Tags used to organize and filter Drupal projects.
Why I chose it: Since the module relies on generative LLMs, this ensures the right audience finds it.

Dependencies: AI module

What it is: Other modules required for this to work.
Why I chose it: We are leveraging the existing Drupal AI core module to securely handle API configurations and process prompts.

Issue Tracking and Releases

Components: Code, Documentation, Miscellaneous, User interface

What it is: Categories for issue queue tickets.
Why I chose it: Granular tags keep the project organized and make bug triage much easier.

Enable issue tracker: Checked

What it is: Allows the community to report bugs and submit patches.
Why I chose it: Open source thrives on collaboration, and this is essential for community contributions.

Version options: Tagged releases, Development branch releases

What it is: How Drupal packages the code for download via Composer.
Why I chose it: It gives users the choice between a stable "Tagged" release or the bleeding-edge "Development" version.

The Description that I put is below.

<p>The AI Recipe Generator is a module designed to accelerate site building by utilizing Artificial Intelligence to generate Drupal Recipes dynamically.</p>

<p>By integrating with the Drupal AI ecosystem, this tool allows developers and site builders to input natural language prompts and automatically generate the necessary configuration, module dependencies, and structure required for a functional Drupal Recipe.</p>

<h3 id="module-project--features">Features</h3>
<ul>
  <li>Integrates directly with the Drupal AI module to process prompts.</li>
  <li>Dynamically generates <code>recipe.yml</code> files and associated configurations.</li>
  <li>Streamlines the creation of standard site features (e.g., blog setups, event content types) without manual YAML writing.</li>
</ul>

<h3 id="module-project--post-installation">Post-Installation</h3>
<p>Once installed, you will configure the generator through the AI module's interface. You must have an active AI provider configured via the core AI module to process prompts and begin generating recipes.</p>

<h3 id="module-project--additional-requirements">Additional Requirements</h3>
<p>This module requires the following dependencies:</p>
<ul>
  <li>AI (Artificial Intelligence) module ecosystem</li>
</ul>

<h3 id="module-project--recommended-libraries">Recommended modules/libraries</h3>
<p>There are currently no additional recommended modules beyond the required AI ecosystem dependencies.</p>

<h3 id="module-project--similar-projects">Similar projects</h3>
<p>While standard Drupal site-building tools exist, this project uniquely leverages generative LLMs and the new Drupal Recipe API to architect configurations via natural language.</p>

<h3 id="module-project--support">Supporting this Module</h3>
<p>This project is currently being developed as part of <strong>Google Summer of Code 2026</strong>.</p>

<h3 id="module-project--community-documentation">Community Documentation</h3>
<p>Weekly progress, architectural breakdowns, and documentation for this GSoC 2026 project are being documented under the <em>Engineering in the Wild</em> series.</p>

Further you can also add your logo here. It was also confusing for me to find out where the logo is.

Where to put Drupal Logo

You are almost done!!! You can review and see the details what they are. And then finally you can save and your project is successfully created! You can view my module here:AI Recipe Generator

Bonus: How to Add Maintainers

Most probably, you will be working with someone else. And it will be necessary to add someone there. Head over to the Maintainers tab and select whom you want to add in the search box. You can select the necessary changes to be made and then press enter!

For adding Maintainers

Follow Along for my next journey

Hrishikesh Dalal | Portfolio | Engineer, Innovator, Hackathon Winner

Official website of Hrishikesh Dalal – Computer Engineering student, Hackathon winner, and tech enthusiast.

hrishikeshdalal.tech

The AI Ghostwriter Experiment

Hrishikesh Dalal — Sun, 17 May 2026 11:48:08 +0000

Over the past few months, I ran an experiment on this blog.

Balancing engineering projects, open-source contributions, and university means deep-focus writing is a luxury I rarely have. I wanted to test a hypothesis: Can a developer leverage LLMs to fully automate content creation without losing technical depth?

I launched my "Engineering in the Wild" & "System Design" series to find out. Here is what I learned from letting AI ghostwrite my blog, and why I’m officially pivoting my strategy.

The Workflow

It wasn’t just mindless prompting. I built a specific pipeline to ground the AI in reality:

Input: Raw notes on architectural decisions (like sync APIs vs. Pub/Sub) or details from my ongoing projects.
Generation: Prompting the LLM to structure an engaging, DEV.to-optimized article.
Output: Flawless markdown, clean code snippets, and accessible analogies.

On paper, it worked perfectly. I shipped consistently, and the articles read like polished, textbook overviews that explained complex concepts exceptionally well.

The Flaw: Sanitized Engineering

While the explanations were solid, the experiment revealed a fatal flaw in fully automated content: it completely sanitizes the reality of writing code.

Reviewing the generated articles made a few things glaringly obvious:

Loss of Signal: AI outputs the statistical average of human knowledge. It produces clean, pristine ideals. But real engineering is chaotic and messy.
Erasure of Friction: The real value of a dev blog isn't just the final architecture—it’s the friction it took to get there. AI erased the edge-case geofencing bugs in my attendance platform, the legacy codebase constraints at my enterprise internship, and the brutal code reviews from merging open-source AI modules.
The Commodity Trap: A flawless explanation of a protocol is useful, but if anyone can generate it in ten seconds, it loses its unique edge. It didn’t show how I think; it showed how the model thinks.

The Pivot: Authentic Grit

The foundational overviews the AI helped me build serve their purpose, and AI remains a phenomenal tool. But going forward, the workflow for "Engineering in the Wild" & "System Design" is evolving.

The best documentation isn’t just a flawless essay; it’s a collection of genuine experiences from the trenches of development. It’s time to bring the grit back to this blog.

Even this meta-analysis was generated by AI :) but the pivot is 100% human.

EP 15: Pub/Sub - Stop Chaining Your Services

Hrishikesh Dalal — Wed, 18 Feb 2026 11:20:06 +0000

You just launched your dream startup, "DevEats"—a food delivery app for developers who need serious fuel while debugging. Your signature item? The "Triple Stack Smash Burger with Truffle Fries."

In the beginning, life was simple. You had one backend service (a monolith). A user ordered a burger, your code saved it to the database, and life was good.

But you grew fast. Now, YOU are the owner of a scaling platform, and your code is turning into a tangled mess of spaghetti (pun intended).

Here is why you need the Pub/Sub pattern, explained through the lens of your own burger empire.

1. What is the Need? (The "Smash Burger Panic")

Let’s look at your current codebase. When a user clicks "Order Burger", your backend does this strictly in order:

Payment Service: Charge the credit card $25.
Order Service: Save the order to the database.
Notification Service: Send a receipt email.
Kitchen Service: Print the ticket for the chef.
Analytics Service: Update your admin dashboard sales graph.

The Problem:
One Friday night, your Email Provider goes down.
Because your code is sequential (A -> B -> C -> D), the entire process crashes at Step 3.

The payment went through (Step 1), but the kitchen printer never got the ticket (Step 4).

Now you have a hangry developer who paid for a Triple Stack Burger that isn't being made. They are angry, and your support inbox is flooding.

The Need:
You need a way for your system to say, "Hey, a burger was just ordered!" without caring who is listening or if the email service is currently online. You need to decouple the sender from the receivers.

2. The Solution: Pub/Sub Architecture

In a Publish/Subscribe (Pub/Sub) model, we split your architecture into three parts:

The Publisher (You/The Order Service): You simply shout a message ("Order #505: Triple Smash Burger!") into a channel. You don't know who is listening. You don't care.
The Topic (The Channel): A dedicated lane for specific types of messages (e.g., events.burger_ordered).
The Subscribers (The Listeners): Independent services that have signed up to listen to that topic.

The New Flow:

User orders the burger.
You (Order Service) publish a message to the events.burger_ordered topic.
Done. You return "Success" to the user immediately.

Meanwhile, in the background:

The Kitchen Service hears the message and instantly prints the ticket on the grill station.
The Notification Service hears the message and tries to send an email. If it fails (because the provider is down), it retries later. Crucially, it does not stop the kitchen from cooking.
The Rewards Service hears the message and adds 50 points to the user's account.

3. When to Use It?

You shouldn't use Pub/Sub for everything. Use it when:

1-to-Many Relationships: One event (Burger Ordered) triggers multiple, unrelated actions (Email, Kitchen Display, Inventory Check).
Decoupling is Vital: You want to add a new "SMS Service" next week without rewriting your existing Order Service code.
Asynchronous Processing: You don't want the user staring at a loading spinner while your server generates a PDF invoice.

4. The Pros and Cons

✅ The Pros

Scalability: You can add 50 new subscribers (e.g., a "Surge Pricing Bot") without touching the original Publisher code.
Reliability: If one subscriber crashes (e.g., the Email service), the others (Kitchen, Analytics) keep working perfectly. The burger still gets made.
Speed: The Publisher fires the event and moves on. The user gets a "Your Order is Placed!" screen instantly.

❌ The Cons

Complexity: You are introducing a new component (a Broker like Redis, Kafka, or Google Pub/Sub) to manage.
Debugging is a Nightmare: You can't just follow a linear stack trace anymore. You have to trace messages flying across a network.
Consistency Issues: What if the message is delivered twice? (Does the customer get charged twice? Does the chef make two burgers?). You have to write code to handle these edge cases.

5. Pub/Sub vs. Message Queue (The Confusion)

This is where most devs get tripped up. Both use "Brokers," but the intent is different.

Scenario A: Pub/Sub (The "Megaphone")

Use Case: You launch a New limited-edition Ghost Pepper Burger.
Logic: 1 Message -> Many Receivers.

Publisher: The Menu Manager Service.
Subscribers:
App Notification Service: Pushes "New Burger Alert!" to all users.
Inventory Service: Reserves spicy peppers in the warehouse.
Marketing Service: Posts automatically to Twitter/X.
Why? Everyone needs to know about this event to do their own specific job.

Scenario B: Message Queue (The "Grill Line")

Use Case: It's lunch rush. You have 500 burger orders coming in.
Logic: 1 Message -> 1 Receiver (Load Balancing).

Producer: The Order Service pushes 500 tickets to a Queue.
Consumers (Chefs): You have 5 Chefs (Chef A, B, C, D, E).
The Flow: Chef A grabs Ticket #1. Chef B grabs Ticket #2.
Why? If Chef A is grilling the burger for Ticket #1, you do not want Chef B to grill the same burger. That’s a waste of meat. You want to distribute the work, not broadcast it.

The Cheat Sheet

Feature	Pub/Sub	Message Queue
Philosophy	"Everyone needs to know this happened."	"Someone please do this job."
Distribution	Broadcast (One-to-All)	Point-to-Point (One-to-One)
Burger Example	"New Menu Item Launched!" (Tell everyone)	"Grill this patty" (One chef does it)

Final Words

As the owner of DevEats, switching to Pub/Sub saved your Friday night rush. When your Email Service crashed, nobody noticed. The orders kept flowing, the smash burgers kept sizzling, and the emails were just queued up and sent an hour later.

That is the power of decoupling. 🍔 code responsibly!

The Jungle Protocol: Turning my Professional Journey into an Adaptive Quest

Hrishikesh Dalal — Sun, 01 Feb 2026 13:58:07 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

About Me

I’m Hrishikesh Dalal, a Computer Engineering student at Sardar Patel Institute of Technology (SPIT), Mumbai. I don't just write code; I build experiences. Currently, I’m engineering a Jumanji-themed gamified portfolio that turns the standard resume into an adventure.

My focus lies in Full Stack Development (Next.js, React) and creating developer tools—I recently published envalyze and env-fault to the NPM registry to help devs manage environments better. When I'm not pushing commits to Open Source projects like Drupal or contributing to MDN Web Docs, I'm exploring the intersection of AI and law with projects like VerdictAI.

I write about system design, open source, and the reality of building software.

Portfolio

Link: https://hrishikesh-dalal-portfolio-571902073238.europe-west1.run.app

How I Built It

My Tech Stack

To build an experience this immersive, I needed a stack that balanced performance with high-end visuals:

Frontend: Next.js & Tailwind CSS
Animations: GSAP (for that cinematic feel)
3D Elements: Three.js (for the interactive globe and hero patterns)
AI:Gemini API (powering the NPC-style chatbots)

The Process: From Chaos to Clarity

Building a portfolio is a trap. You want to show off everything, but if you're not careful, you end up with a bloated mess.

1. The Affinity Mapping Phase

Initially, I was drowning in ideas from my UI/UX course. I had a laundry list: a full 3D world, a terminal, hidden easter eggs, business-centric project stats, and a Jumanji-themed game. I used Affinity Mapping to dump every "cool" idea onto a board and then ruthlessly segregated them.

2. The "Reality Check"

I had to ask the most important question: Why is someone here?
Hiring managers are busy. They might be tech-savvy, or they might not be. They might want to play a game, or they might just want to see my resume and leave in 30 seconds.

The Decision: A "Clean & Clear" landing page with a defined Call to Action (CTA) is non-negotiable. The "wow" factor should enhance the info, not hide it.

Design Breakdown: Section by Section

The Hero (The First 5 Seconds)

I treated the Hero section like a movie opening. I implemented a preloader with a cinematic transition that drops you into an interactive dot pattern. It’s meant to grab attention immediately.

The Impact (Big Numbers & Open Source)

Instead of just saying "I build tools," I used big, bold typography to showcase my NPM stats. I wanted the real-world impact of envalyze and env-fault to be unavoidable. I also dedicated space to my Open Source journey—showing my Hacktoberfest badges and my role as a project admin.

The Experience Timeline

I used a scroll-triggered timeline with GSAP micro-interactions. When you hover over an entry, there’s a slight movement—just enough to feel alive, but not enough to be distracting.

The Terminal (For the Geeks)

I built a fully functional terminal for my projects. You can change themes, run an echo, or see animations.

Pro Tip: Try typing sudo. You’ve been warned.

The Accessibility Switch: If you aren't a terminal person, there's a toggle to switch back to a standard grid. No one gets left behind.

The "Jungle" Experience

This was the hardest part to get right. My first version was just a collection of games, and the feedback from friends was brutal: "It’s disconnected. I don't see YOU in this."

I went back to the drawing board and turned it into a narrative. I added:

A Prologue & Epilogue: To give the "quest" a purpose.
Level 2 (The Jumper): While you play, the character narrates my tech stack and experience journey.
Secret Cheat Codes: Because what's a game without them?

Bringing it to life with AI

My main chatbot you have different answers queries, sample questions that you can ask to make it better.

While the game chatbot is like NPC character answering you.

The Architecture

The diagram below shows how the game chatbot is integrated to handle context-aware queries, ensuring it knows where you are in the game and who I am as a developer.

The User Interaction Layer
User Sends Message: The process begins with the user interacting with the interface.
Frontend App (NEXT JS): The core UI is built using React. It features a React Markdown Renderer, which ensures that the AI's responses—often containing code snippets or formatted text—are displayed cleanly and professionally to the user.
Security and Traffic Management
Backend API Gateway & Security Layer: Instead of calling the Gemini API directly from the frontend (which would expose your API keys), the app calls a secure backend gateway. This layer handles authentication and protects your credentials.
Load Balancer: To prevent any single server from becoming overwhelmed, a load balancer sits in the middle. It analyzes incoming requests and routes them efficiently across multiple active instances.
The Processing Core
Chat Model Instances: The system uses multiple parallel instances (Instance 1, 2, and 3) to process requests.
Least Used Routing: The load balancer is shown routing a request specifically to "Instance 1" because it is currently the "Least Used," ensuring optimal performance and low latency.
Google's Gemini API: These instances act as the bridge to Google’s infrastructure. They send the processed user prompt to the Gemini API and receive the raw AI generation in return.
The Response Loop
Forwards Response: Once a chat instance receives the data from Google, it forwards that response back through the secure backend.
Final Display: The message is sent back to the NEXT JS app, where it is rendered as Markdown, completing the loop and appearing on the user's screen.

Easter Eggs

I have a game at the start where the user can press the "?" button and play that simple.

"Stay Hungry, Stay Foolish." My portfolio ends with this quote because it sums up my approach to engineering. Whether it's deep-diving into the Drupal source code or building a terminal from scratch, I’m always looking for the next thing that feels slightly impossible to build.

What I'm Most Proud Of

If you’re a developer, you know the feeling: you spend 10% of your time on the features people see and 90% of your time on the "over-engineered" systems that make you feel like a wizard. Here are the pillars of this portfolio that I obsessed over.

1. The Terminal (Because real devs use a CLI)

I didn't want a static "Projects" page; I wanted something that felt like home. I built a fully functional, web-based Terminal where you can actually interact with my work.

The Experience: It’s a working CLI where you can navigate projects, change themes, or trigger animations.
The "Sudo" Trap: I’ve hidden easter eggs for people who like to poke around—try typing sudo.
The Hybrid UI: I know recruiters aren't always looking to type commands, so I built a "safety net" toggle that instantly switches the terminal into a standard project grid.

2. Projects with a "Business First" Logic

Most portfolios just show a screenshot and a GitHub link. I decided to treat my projects like real products.

Beyond the Code: When you click into a project, I don't just list the tech stack. I break down the Business Perspective, the Impact, and the Stats.
The "Why" Factor: I included the reasoning behind my architectural choices so that a non-technical stakeholder can understand the value I created, not just the code I wrote.
Deep Dives: Each project page is designed to show the journey from a pain point to a scalable solution.

3. The Jumanji Game Engine

I turned my professional experience into a narrative quest. This wasn't just about putting a game on a website; it was about making the resume playable.

The Narrative: I added a full prologue and epilogue to make sure it felt like a real quest, not just a random mini-game.
The Career Jumper: In Level 2, the character literally narrates my tech stack and my journey through different roles while you play.
Recruiter Mode: I even made the game adaptive—a recruiter can upload a job description, and the game will fine-tune the information it highlights to match what they need.

4. The Chatbot Architecture

I’m most proud of what’s happening "under the hood" here. I built a production-ready pipeline for the Gemini-powered Chatbot.

The Load Balancer: My system uses three different chat model instances. I implemented a load balancer that routes traffic to the "least used" instance to keep things snappy, no matter the traffic.
Security & Scalability: I kept the logic on the backend. The React frontend talks to a secure API Gateway, which handles the Gemini API calls to keep my keys safe.
The NPC Persona: I used the Gemini API to give the bot a specific "In-game NPC" persona—it knows it’s in the Jungle, but it also knows my GitHub stats.

System Design: EP 14 - The Coffee Shop Guide to Understanding Message Brokers

Hrishikesh Dalal — Wed, 21 Jan 2026 11:17:47 +0000

If you are a developer moving from a monolith to microservices, you’ve probably hit The Problem. Service A calls Service B, but Service B is slow, or down, or just busy. Suddenly, Service A hangs, the user sees a spinning wheel of death, and you get paged at 3 AM.

The solution? Stop making your services talk directly. Introduce a Message Broker.

If that sounds abstract, let's talk about coffee.

The "Bad" Coffee Shop (Synchronous)

Imagine a coffee shop where the person taking your order is also the only person allowed to make your coffee.

You (The User) walk in and order a latte.
The Cashier (Service A) takes your money.
The Cashier then walks over to the espresso machine, steams the milk, pulls the shot, pours the art, and hands it to you.
Only then do they return to the register to take the next person's order.

The Result: A massive line out the door. If the espresso machine breaks, the cashier is stuck waiting, and nobody can even place an order. This is Synchronous Communication (like HTTP REST calls). It creates tight coupling and bottlenecks.

The "Good" Coffee Shop (Asynchronous with a Broker)

Now, let's look at how a Starbucks or a high-volume cafe actually works.

You (The User) order a latte.
The Cashier (Service A / Producer) takes your money and writes your order on a cup (or a ticket).
The Cashier places the cup on the Counter/Ticket Rail (The Message Broker).
The Cashier immediately turns back to you and says, "Next please!"
The Barista (Service B / Consumer) sees the cup on the rail, picks it up, and makes the coffee.

The Result: The cashier never stops working. They can take 50 orders in the time it takes the barista to make 5 drinks. The "Ticket Rail" acts as a buffer.

The Technical Translation

That "Ticket Rail" is your Message Broker (like RabbitMQ, Kafka, or AWS SQS). Here is the mapping for your next system design interview:

1. The Producer (The Cashier)

This is the service that sends the data. In the coffee shop, the cashier "produces" the order. They don't care who makes the coffee or when it gets made; they just need to know the order has been safely placed on the rail.

Dev Term: Publish

2. The Message Broker (The Ticket Rail)

This is the middleware that sits between your services. It holds the messages (orders) until a consumer is ready to take them.

The Queue: The line of cups waiting on the machine. If the baristas get overwhelmed, the queue grows, but the cups aren't lost. They are safely stored until the backlog clears.

3. The Consumer (The Barista)

This is the service that processes the data. The barista "consumes" the order from the rail.

Dev Term: Subscribe
Scaling: If the line of cups gets too long, what do you do? You don't clone the cashier; you add a second barista. Message brokers allow you to scale your processing power (Consumers) independently of your intake power (Producers).

Why use a Message Broker?

Using the coffee shop model, the benefits become obvious:

Decoupling: The cashier doesn't need to know which barista is working today. If the barista quits (Service B crashes), the cashier can keep taking orders. The cups just pile up on the rail until a new barista is hired (Service B restarts). No data is lost.
Throttling (Load Leveling): If 100 people rush the store at once, the cashier takes all the orders quickly. The baristas continue working at their normal, safe speed. They don't explode from stress; they just work through the backlog.
Asynchronous Processing: Heavy tasks (like roasting beans or baking pastries) don't block the customer from paying and leaving.

Summary

Direct HTTP calls are like a cashier making every drink themselves. It works for a lemonade stand, but it fails at scale.

A Message Broker is the ticket rail that lets your services work at their own speeds, independently and reliably.

So, the next time you're architecting a system, ask yourself: Are we building a lemonade stand, or are we building a coffee empire?