DEV Community: Rohan Yeole

How I Built a Free Online Grocery List Tool with Django — and What the Backend Actually Looks Like

Rohan Yeole — Wed, 15 Apr 2026 07:53:45 +0000

Managing groceries sounds trivial. It isn't.

Most grocery list apps are bloated, require account sign-ups, and push you toward subscriptions. As a Django and Python developer, when I needed a quick tool for myself, I did the sensible thing: I built one. It lives at rohanyeole.com/grocery-list/ — free, no login, no install, works immediately in any browser.

This post is about the engineering decisions behind building a clean, fast utility tool using Django. It's also about the patterns I use repeatedly across every tool page I ship — patterns that are useful whether you're building a grocery list, a cron generator, a diff checker, or any other developer utility.

The Problem with Most Grocery List Apps

They're Overkill for a Simple Task

Todoist, AnyList, OurGroceries — great apps, genuinely. But they all share a common failure mode: they try to do too much. Shared lists, meal planning integrations, barcode scanning. Meanwhile, you're at the supermarket at 8pm trying to remember if you need milk.

The tool I built has one job: let you type items, check them off, clear the list. That's it.

You Shouldn't Need an Account to Make a List

This is a real design decision, not a limitation. The grocery list tool requires zero authentication. No database record per user. No session cookie abuse. State lives in localStorage on your device. The server doesn't need to care.

This is the right call for a utility tool. It's also the only call that lets the page be fully cacheable on the CDN edge.

What the Grocery List Tool Does

Core features:

Add items to a list instantly
Check off items as you pick them up (visual strikethrough)
Remove individual items
Clear the entire list in one tap
Persists across browser tabs and page refreshes via localStorage
Mobile-first layout — usable with one thumb No:
Account required
App install required

- Internet connection required after first load (once cached)

The Backend Architecture

Django View: Serving a Static Tool Page

The view for a utility tool like this is intentionally minimal:

# views.py

from django.shortcuts import render
from django.views.decorators.cache import cache_page

@cache_page(60 * 60 * 24)  # Cache for 24 hours at the Django layer
def grocery_list_view(request):
    return render(request, 'tools/grocery_list.html', {
        'page_title': 'Free Online Grocery List',
        'meta_description': 'Plan your shopping with a fast, free grocery list tool. No login required.',
    })

# urls.py

from django.urls import path
from .views import grocery_list_view

urlpatterns = [
    path('grocery-list/', grocery_list_view, name='grocery_list'),
]

That's the entire backend. One view. One URL. The tool is self-contained in the template.

Why Cache at the Django Layer?

For pages with no dynamic server-rendered content, you absolutely should be caching. Django's cache_page decorator is the first layer. The second layer is Nginx or a CDN like Cloudflare. I cover this pattern in depth in my post on caching data in Python strategies that scale.

Template + JavaScript: State Without a Database

This is where the real work happens. The entire application state is managed in the browser.

<!-- templates/tools/grocery_list.html -->
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>{{ page_title }}</title>
  <meta name="description" content="{{ meta_description }}">
  <meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>

<div id="grocery-app">
  <h1>Grocery List</h1>

  <div class="input-row">
    <input type="text" id="item-input" placeholder="Add an item..." autocomplete="off">
    <button onclick="addItem()">Add</button>
  </div>

  <ul id="item-list"></ul>

  <button onclick="clearAll()" id="clear-btn">Clear All</button>
</div>

<script>
  const STORAGE_KEY = 'grocery_list_items';

  function loadItems() {
    return JSON.parse(localStorage.getItem(STORAGE_KEY) || '[]');
  }

  function saveItems(items) {
    localStorage.setItem(STORAGE_KEY, JSON.stringify(items));
  }

  function renderList() {
    const items = loadItems();
    const ul = document.getElementById('item-list');
    ul.innerHTML = '';

    items.forEach((item, index) => {
      const li = document.createElement('li');
      li.className = item.checked ? 'checked' : '';
      li.innerHTML = `
        <span onclick="toggleItem(${index})">${item.text}</span>
        <button onclick="removeItem(${index})">✕</button>
      `;
      ul.appendChild(li);
    });
  }

  function addItem() {
    const input = document.getElementById('item-input');
    const text = input.value.trim();
    if (!text) return;

    const items = loadItems();
    items.push({ text, checked: false });
    saveItems(items);
    input.value = '';
    renderList();
  }

  function toggleItem(index) {
    const items = loadItems();
    items[index].checked = !items[index].checked;
    saveItems(items);
    renderList();
  }

  function removeItem(index) {
    const items = loadItems();
    items.splice(index, 1);
    saveItems(items);
    renderList();
  }

  function clearAll() {
    saveItems([]);
    renderList();
  }

  // Allow Enter key to add items
  document.getElementById('item-input').addEventListener('keypress', function(e) {
    if (e.key === 'Enter') addItem();
  });

  // Initial render on page load
  renderList();
</script>

</body>
</html>

This is clean, zero-dependency JavaScript. No React, no Vue, no build step. Just the DOM and localStorage. The entire tool weighs under 10KB uncompressed.

Common Mistakes When Building Utility Tool Pages in Django

1. Over-Engineering the Data Model

I see this constantly. Developers immediately reach for a GroceryList model with User foreign keys, created_at, updated_at, sync APIs. For a personal utility tool — stop. You don't need it. The client browser IS the database for ephemeral user state.

If you ever need multi-device sync, add it later. YAGNI is real.

2. Forgetting to Cache Static Tool Pages

A Django view that just renders a template with no dynamic data should never hit your database or application server on repeat requests. Use cache_page, configure Nginx proxy_cache, and put Cloudflare in front.

3. Ignoring Mobile UX

Over 70% of tool page traffic comes from mobile. If your <input> is 12px, your buttons are tiny, and you have no viewport meta tag — you've already lost. A grocery list is inherently a mobile use case. Design for thumbs first.

Performance and SEO Tips for Django Tool Pages

Caching Strategy

# nginx.conf — cache tool pages at the proxy layer
location /grocery-list/ {
    proxy_cache my_cache;
    proxy_cache_valid 200 24h;
    proxy_pass http://django_app;
    add_header X-Cache-Status $upstream_cache_status;
}

For a full Django + Nginx production deployment pattern, check my guide on building and deploying a Django REST API in production.

Structured Data

Add WebApplication schema markup for better rich result eligibility:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "Free Online Grocery List",
  "url": "https://rohanyeole.com/grocery-list/",
  "applicationCategory": "UtilitiesApplication",
  "operatingSystem": "All",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}
</script>

Core Web Vitals

No JavaScript framework = faster LCP
Inline critical CSS = zero render-blocking stylesheets
localStorage = zero server round-trips for state

- Django `cache_page` = low TTFB on repeat visits

Final Checklist

✅ Django view with cache_page decorator
✅ URL registered in urls.py
✅ Template with inline JS for state management
✅ localStorage for persistence (no database needed)
✅ Enter key support on input
✅ Mobile-first layout
✅ Nginx proxy cache configured
✅ schema.org WebApplication markup
✅ Meta title and description in template context
✅ Core Web Vitals optimized (no JS framework)

Conclusion

Building a clean, fast utility tool in Django doesn't require a complex architecture. It requires restraint. One view. One template. Zero unnecessary dependencies. State in the browser.

The grocery list tool is exactly that: a focused tool that does one thing well. And the same patterns — minimal views, aggressive caching, client-side state — apply to every tool page I've shipped on this site.

If you're building a Django or Python web app and need a backend engineer who ships clean, production-ready systems — feel free to reach out. I'm Rohan Yeole, a Django and Python developer available for hire, with experience across clients in India, the US, and Germany. Check out my work and developer tools.

How the Flappy Bird Browser Game Actually Works — Physics, Loops, and a Playable Demo

Rohan Yeole — Mon, 13 Apr 2026 07:07:44 +0000

Flappy Bird is one of the most-cloned games on the internet — and for good reason. It's a near-perfect beginner project: simple physics, one input, instant feedback. But most tutorials stop at "here's the code." Let me walk through how the actual browser mechanics work, and link you to a live version you can play right now.

▶ Play it live → rohanyeole.com/flappy-bird

The Core Physics Loop

Every frame of Flappy Bird runs the same operations in order:

Apply gravity to vertical velocity
Apply vertical velocity to bird's y position
Move all pipes left by pipeSpeed pixels
Check rectangle collision between bird and each pipe
Check floor/ceiling collision
Draw everything

That's it. The entire game is a loop over those six steps.

const gravity = 0.45;
const jumpForce = -8.5;

let birdY = canvas.height / 2;
let birdVel = 0;

document.addEventListener('keydown', (e) => {
  if (e.code === 'Space') birdVel = jumpForce;
});

canvas.addEventListener('click', () => {
  birdVel = jumpForce;
});

function update() {
  birdVel += gravity;
  birdY += birdVel;
}

Gravity tuning is the whole game design. Too high and it's physically impossible; too low and it's trivially easy. The sweet spot is around 0.4–0.5 with a jump force of -8 to -10 for a canvas height of 600px.

Pipe Generation

Pipes come in pairs (top and bottom) with a gap between them. The gap position is randomised, but the gap height stays fixed:

const GAP = 150;
const PIPE_WIDTH = 60;
let pipeSpeed = 3;

function spawnPipe() {
  const topHeight = Math.random() * (canvas.height - GAP - 100) + 50;
  pipes.push({
    x: canvas.width,
    topHeight,
    bottomY: topHeight + GAP
  });
}

// Called every N frames
setInterval(spawnPipe, 1800);

As score increases, you can increase pipeSpeed by 0.1–0.2 every 10 points for a difficulty curve.

Collision Detection

AABB (Axis-Aligned Bounding Box) collision is all you need here:

function collides(bird, pipe) {
  return (
    bird.x < pipe.x + PIPE_WIDTH &&
    bird.x + bird.size > pipe.x &&
    (bird.y < pipe.topHeight || bird.y + bird.size > pipe.bottomY)
  );
}

The bird is treated as a square for collision purposes. The visual is a circle or sprite — the slightly forgiving hitbox is intentional and feels right to players.

Python Flappy Bird (Pygame)

If you want to build this in Python instead, pygame is the standard choice. The physics loop maps 1:1:

GRAVITY = 0.5
JUMP_FORCE = -9

bird_y = 300
bird_vel = 0

while True:
    for event in pygame.event.get():
        if event.type == pygame.KEYDOWN:
            if event.key == pygame.K_SPACE:
                bird_vel = JUMP_FORCE

    bird_vel += GRAVITY
    bird_y += bird_vel
    # clamp to screen, check pipe collision...

The logic is identical. The only difference is the rendering layer: canvas.drawImage() in JS vs pygame.draw.* in Python.

Play the Live Version

The version on my site runs entirely in the browser — no login, no install. It's part of a collection of free developer tools I maintain:

What I Learned Building Browser Games as a Backend Dev

I mostly build Django REST APIs and Celery task pipelines — server-side Python. Browser games are an interesting inversion: all state lives in the client, the loop has to run at 60fps, and you can't make a server round-trip mid-frame.

The constraint of requestAnimationFrame teaches you something about deterministic loops that applies back to backend work too. A game loop where state corrupts silently is exactly like a Celery task that swallows exceptions — you need predictable, inspectable state transitions.

If you're a backend developer who hasn't tried building a small canvas game, I'd recommend it as an afternoon project. The fundamentals transfer.

I'm Rohan Yeole — Python/Django developer. If you're building a SaaS backend, REST API, or need Celery + PostgreSQL architecture work, I'm available for hire.