DEV Community: Aditya

Biryani, With Love: A Deccan-Inspired Interactive Atlas

Aditya — Sun, 02 Aug 2026 11:31:41 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing.

What I Built

Biryani, With Love is an interactive editorial atlas about the many regional traditions that share the name biryani.

I chose biryani because comfort food is rarely only about flavour. It can hold a city, a family ritual, a migration story, a celebration, and a memory of home in the same pot. The landing page follows that idea from Hyderabad through India and across the Indian Ocean.

The experience includes:

A research-led map of eight Indian biryani traditions
A method lab comparing kachchi, pakki, and one-pot cooking sequences
A guided loop through fourteen traditions across nine countries
A comparison tool for grain, method, flavour, heat, perfume, tang, and richness
A historical route connecting language, court kitchens, regional grains, and Indian Ocean migration
A research shelf that makes the supporting sources visible

The visual system is inspired by a contemporary Deccan pavilion. Saffron, peacock green, pomegranate red, plum, brass, and ivory create the palette. The hero uses CSS-built arches, minarets, jali panels, steam, rice grains, garnish, and an open copper handi.

Demo

Open the full CodePen

Journey

Finding the right metaphor

My first version treated the page like a clean editorial index. It was readable, but it did not carry enough of the warmth, ceremony, and visual richness of the subject.

The breakthrough was to stop treating biryani as a list of recipes and instead design an edible atlas. Each section became a different way to read the same dish: geography, cooking sequence, migration, flavour, and memory.

Researching the architecture

The heritage direction was grounded in specific references rather than a generic ornamental style.

I studied the Charminar architecture described by Hyderabad District, particularly its four-sided arches, minarets, carved rings, and Qutb Shahi lotus details. I also looked at a sixteenth-century Indian jali in The Metropolitan Museum of Art, where stars, hexagons, and interlocking geometry create a play of light and pattern.

Those ideas became solid-color architectural frames, small lattice details, geometric rules, and the central handi illustration. I kept the interface modern by using strong editorial typography, square cards, clear hierarchy, and restrained motion.

Correcting the map

The first map used a simplified world dataset and looked noticeably wrong. I replaced it with the official Survey of India 1:16m outline vector, including the island territories.

The eight city points are projected from geographic coordinates instead of being positioned by eye. The map remains a cultural navigation device, but its outline and locations now have a defensible source.

Building the interactions

The project is a single responsive HTML document with inline CSS and vanilla JavaScript. CodePen separates those same three layers into its HTML, CSS, and JavaScript panels.

JavaScript is used purposefully for:

Switching regional map stories
Updating cooking method diagrams
Running and pausing the global biryani loop
Filtering traditions by geography
Comparing two traditions
Updating the historical route
Respecting reduced-motion preferences

The page contains no raster food photography. The hero, diagrams, decorative architecture, and interface details are created with HTML, CSS, and inline vector geometry.

Accessibility and usability

I wanted the atlas to remain useful beyond its visual impact. It includes:

Semantic sections and heading structure
Keyboard-operable SVG map points
Visible focus states
A skip link
Live regions for changing content
Reduced-motion support
Responsive layouts for narrow screens
Source links for the research claims
Clear notes where flavour scores are interpretive rather than scientific measurements

What I Am Proud Of

I am most proud that the page does not rank biryanis or declare one authentic winner. It gives each tradition enough context to feel distinct while showing the shared ritual underneath: rice, patience, adaptation, and memory.

The final result feels like a love letter, a research object, and a modern landing page at the same time.

AI Collaboration

I used OpenAI Codex as a collaborative coding, research, and iteration tool. I directed the concept, selected the biryani theme, reviewed each visual pass, identified inaccuracies, and made the final design decisions. The implementation and research sources were checked and refined through that collaboration.

DUM: Breaking the Seal on Hyderabadi Biryani with Pure CSS

Aditya — Sun, 02 Aug 2026 06:19:47 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

Hyderabadi dum biryani is more than a dish to me—it is a ritual. The sealed handi, the slow charcoal heat, the suspense before the atta crust is broken, and the first rush of saffron, mint, birista, and spice all feel inseparable from the experience.

I wanted to turn that moment into an interactive midnight poster: Hyderabad’s skyline behind a copper handi, with the food hidden until the viewer breaks the seal.

Demo

Click BREAK THE SEAL to lift the lid and reveal the four biryani layers.

How it works

The artwork is built with HTML and CSS only:

A native <details> / <summary> control stores the open and closed states.
CSS :has() coordinates the seal crack, lid lift, layer reveal, steam, labels, embers, and state-aware copy.
Rice grains, mint leaves, birista, spices, meat, copper patina, flour dust, the skyline, and the moon are all CSS shapes.
There are no images, SVGs, canvas, JavaScript, gradients, or frameworks.
A mobile composition and prefers-reduced-motion keep the piece responsive and accessible.

The reveal is deliberately choreographed:

seal cracks → lid lifts → layers separate → labels arrive → steam settles

Journey

The hardest part was keeping the illustration detailed without losing the strong poster silhouette. I iterated on three areas:

Material: hammered copper marks, soot, flour residue, dough cracks, and print texture.
Depth: curved food layers, overlapping grains, steam arches, and ingredient silhouettes.
Motion: a staged opening sequence rather than making every element animate at once.

The most satisfying decision was using a semantic HTML control for the interaction. The artwork still works with a keyboard, and disabling motion does not hide the final state.

I used Codex as an iterative coding and visual-critique partner. I directed the concept, cultural references, composition, and final decisions, while the agent helped implement and test the CSS system.

What I’m proud of

The finished piece stays intentionally constrained: one HTML file, one CSS file, a small palette, and no image assets. The interaction adds drama, but CSS remains the star of the submission.

Thanks for taking a look—and remember: patience is the final ingredient.

AI Storyline Generator

Aditya — Sun, 14 Sep 2025 21:49:45 +0000

This is a submission for the Google AI Studio Multimodal Challenge

What I Built

I created AI Storyline Generator, a web app that turns a set of images and a short text prompt into a cohesive narrative. It helps writers and artists quickly build stories or prototypes by offering three modes: Surprise Me (short story with optional cover art), Light Novel (full chapter with illustrations), and Manga (panel art).

Demo

Demo Video

Screenshots

LINK

Applet Link 🌱
Note: I was not able to publish the app due to billing issues. Please accept the published app link. Thankyou.

How I Used Google AI Studio

Used gemini-2.5-flash-image-preview for vision–language tasks like story generation and all image outputs.
Used gemini-2.5-flash for Manga mode to reliably create structured JSON scripts.

Multimodal Features

Image-to-Story Generation: Combines multiple images and text into a connected plot.
Narrative-Aware Illustration: Generates key-scene illustrations directly from the AI-written story.
Automated Manga Pipeline: Creates a full manga page by chaining image analysis, JSON scripting, and panel art generation

Efficient Architecture 101: Is Your Upload Strategy Actually Efficient?

Aditya — Tue, 26 Aug 2025 17:15:06 +0000

Before we start...

So, why this series? I've recently jumped straight into the complexities of system design, and I think the best approach to learning is by writing blogs and sharing what I have learned. My goal is to create simple blogs with humor and a lot of diagrams. Please note, I'm still learning, so if you're experienced and find something that can be improved or is incorrect, please share your thoughts.

The Challenge: A Real-World Bottleneck

Not long ago, I was digging through a codebase and found a classic file upload setup. The user would select a file in their browser, the browser would send it to our backend server, and then the server would upload it to a cloud storage bucket like AWS S3.

It worked, but it was far from efficient. The architecture looked something like this:

So, approach has some serious drawbacks

It's Slow for the User: The file has to make two trips over the internet. The user is stuck waiting for both to complete.
It Hogs Server Resources: Imagine 100 users uploading large videos at once. Your server is suddenly trying to process gigabytes of data, choking its memory, CPU, and bandwidth. This is a classic scalability nightmare.
It Can Be More Expensive: You're paying for the bandwidth twice – once for the data coming into your server, and again for it going out to the cloud storage. Ouch.

A Slightly Better Approach (That's Actually Worse)

So, to fix the speed issue, why not just upload directly from the browser? Modern tools like the AWS SDK for JavaScript let you do just that. The flow seems simpler and faster.

But this comes with a giant, flashing, red security warning. To allow the browser to upload, you have to embed your secret access keys directly in the frontend code. This is like leaving the master key to your entire house under the doormat.

Anyone with a little know-how can open their browser's developer tools, find your keys, and gain full, unrestricted access to your storage bucket. It's a disaster waiting to happen.

The Real Solution: Pre-Signed URLs

This is where we get the best of both worlds: the speed of a direct upload and the security of a server-managed process.

A pre-signed URL is a special, temporary, and secure link that your server generates. It gives a user permission to perform a specific action (like uploading a file with a specific name) directly to your cloud storage, but only for a limited time.

the browser first asks the server for permission. The server then generates a temporary, pre-signed URL and sends it back. The browser uses this special URL to upload the file directly to cloud storage. The server's only job is to authorize the request, not to handle the heavy file transfer itself.

So, Why prefer pre-singed url for uploads?

Enhanced Security: Your cloud storage credentials are never exposed on the client-side.
Improved Performance: Files are uploaded directly to cloud storage, reducing latency for the user.
Increased Scalability: Offloads the bandwidth and processing load from your server, allowing it to handle more application requests.
Cost Optimization: Reduces egress bandwidth costs from your server.

Best Practices

Use Short-Lived URLs: Always configure pre-signed URLs with the shortest possible expiration time (e.g., 5-15 minutes) to minimize the risk of misuse.
Utilize Multipart Uploads: For large files, leverage multipart uploads. This involves generating multiple pre-signed URLs to upload the file in chunks, which improves reliability.
Implement Resumable Uploads: In case of network interruptions, a robust implementation should allow the upload to resume from the last successfully uploaded part, rather than restarting the entire process.