<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[My Publication]]></title><description><![CDATA[My Publication]]></description><link>https://narnonymous.hashnode.dev</link><image><url>https://cdn.hashnode.com/res/hashnode/image/upload/v1593680282896/kNC7E8IR4.png</url><title>My Publication</title><link>https://narnonymous.hashnode.dev</link></image><generator>RSS for Node</generator><lastBuildDate>Mon, 07 Sep 2026 17:08:42 GMT</lastBuildDate><atom:link href="https://narnonymous.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Ditching SQL: How I Built a 293k-Word Bilingual Lexicon on a Serverless Edge Network]]></title><description><![CDATA[Every developer knows the standard template for building a searchable application: spin up a relational database, put a backend API server in front of it, deploy a framework-heavy frontend, and hope y]]></description><link>https://narnonymous.hashnode.dev/ditching-sql-how-i-built-a-293k-word-bilingual-lexicon-on-a-serverless-edge-network</link><guid isPermaLink="true">https://narnonymous.hashnode.dev/ditching-sql-how-i-built-a-293k-word-bilingual-lexicon-on-a-serverless-edge-network</guid><category><![CDATA[Web Development]]></category><category><![CDATA[serverless]]></category><category><![CDATA[cloudflare]]></category><category><![CDATA[architecture]]></category><category><![CDATA[JavaScript]]></category><dc:creator><![CDATA[Naruttam Boruah]]></dc:creator><pubDate>Thu, 02 Jul 2026 04:36:53 GMT</pubDate><content:encoded><![CDATA[<p>Every developer knows the standard template for building a searchable application: spin up a relational database, put a backend API server in front of it, deploy a framework-heavy frontend, and hope your cloud budget doesn't explode under heavy traffic.</p>
<p>But when I set out to build a modern, bidirectional English-Assamese digital dictionary—<a href="https://assamesedictionary.org/"><strong>AssameseDictionary.org</strong></a>—I wanted to break away from traditional server overhead. I had a massive dataset of over <strong>293,000 words</strong> containing complex synonym mappings, phonetic transliterations, and context examples.</p>
<p>If I used a traditional SQL setup, lookup latencies and server hosting costs would become a constant bottleneck. Here is how I built a blazing-fast, serverless lexicon that handles massive queries entirely at the edge.</p>
<h3>🏗️ Architectural Topology: The Power of Key-Value Cache</h3>
<p>The core constraint of a digital dictionary is simple: read operations scale exponentially, while write operations are incredibly rare. Users expect a definition to load the exact millisecond they finish typing.</p>
<p>To solve this, I decoupled the data layer entirely from standard database hosting:</p>
<ol>
<li><p><strong>The Data Engine (Cloudflare Workers + KV):</strong> Instead of pointing lookups to a central database server, I compiled, cleaned, and programmatically validated the 293,000+ word matrix into a global Key-Value (KV) memory store. When a query hits the API, a serverless worker fetches the payload instantly from memory at an edge data center closest to the user.</p>
</li>
<li><p><strong>The Zero-Framework Frontend:</strong> To keep rendering times near zero on mobile devices, I built the user interface close to the metal using pure vanilla HTML5, modern ES6 JavaScript, and a production-minified Tailwind CSS layout. No heavy virtual DOM, no massive hydration cycles.</p>
</li>
<li><p><strong>Progressive Caching (PWA):</strong> Language learning tools are often needed most when cell connectivity is at its worst. By leveraging background service workers, the platform functions as a Progressive Web App (PWA) that caches accessed paths dynamically, allowing offline lookups.</p>
</li>
</ol>
<h3>🔍 Engineering Clean SEO Routing</h3>
<p>A dictionary lives or dies by its long-tail SEO performance. If Google cannot index individual words, your app doesn't exist to the outside world.</p>
<p>While query parameters (like <code>?word=excavate</code>) work fine for localized application state, search engine spiders heavily favor clean directory structures (like <code>/word/excavate</code>) to treat entries as unique landing pages.</p>
<p>To achieve this over a Single Page Application (SPA) architecture on Cloudflare Pages without throwing ugly server-side 404s, I implemented a global routing rewrite rule inside a root <code>_redirects</code> file:</p>
<pre><code class="language-text">/*  /index.html  200
</code></pre>
<p>This intercepts any deep-link navigation, pushes the client cleanly to <code>index.html</code> with a success status, and lets a specialized frontend router split the <code>window.location.pathname</code> to fetch the specific word index programmatically.</p>
<h3>🚀 Scaling Next</h3>
<p>By eliminating heavy server logic, the operational costs are virtually non-existent, and query responses snap back near-instantly. Phase 2 is already underway, focusing on rolling out a native Android client wrapper that hooks directly into this exact serverless edge API pipeline.</p>
<p>Check out the live build: 👉 <a href="https://assamesedictionary.org/">https://assamesedictionary.org/</a> I’d love to hear how you handle high-volume text datasets or scale localized language applications over edge infrastructure in the comments below!</p>
]]></content:encoded></item></channel></rss>