Overview​

Scandals are not just stories—they’re structured data. I wanted to capture every major political controversy in Nepal since 2040 B.S. as structured content that can be sorted, filtered, visualized, and linked.

This post covers how I modeled scandals with:

• Timeline consistency
• Hierarchical parent-child links
• Multilingual titles and content
• Source citations and metadata
• Relation to multiple political entities (leaders, parties, governments)

Schema Design​

Overview​

Once data is live, platforms become conversations. In this post, I’ll explain how I created a resource-aware content and feedback engine where users can:

• Read and write multilingual content
• Rate political entities (parties, leaders, governments)
• Comment on historical events and scandals
• Attach feedback directly to any model in the system

The system is powered by polymorphic content linking, a unified comment engine, and approval metrics.

Design Goals​

Overview​

Supporting multiple languages isn’t just about translating strings—it’s about designing your entire platform to speak more than one language from day one. For a civic-tech system targeting Nepali audiences as well as English-speaking researchers and diaspora users, bilingual support was non-negotiable.

In this article, I’ll explain how I implemented multilingual support across:

• Database models and schema
• API structure
• React frontend rendering
• SEO and routing strategy
• Dynamic content like polls, charts, and tooltips

The Challenge: Making Multilingual the Default​

Overview​

When building a platform that relies on statistical analysis and deep comparisons, response time can quickly become a bottleneck. In this article, I’ll walk through how I integrated Redis with NestJS to reduce computation time and database load on performance-heavy endpoints.

I implemented caching on frequently accessed data like:

• Party trends across elections
• Leader performance history
• Poll summaries
• Government composition data

Overview​

Polling seems simple on the surface—ask a question, tally responses—but in a public-facing, multilingual, political data platform, the requirements grow fast. I needed to build a polling system that was:

• Reusable and flexible (attach polls to leaders, parties, elections, etc.)
• Localized (bilingual support)
• Honest (no spam or duplicate votes)
• Insightful (results usable in trends and analytics)

This post covers how I approached it with NestJS, Prisma, and a clean frontend API.

Overview​

Visualizing data isn’t just about plotting numbers—it’s about telling stories that users can grasp at a glance. In this post, I’ll break down how I used Recharts in combination with Tailwind CSS and Mantine to create responsive, branded, and insightful charts for political and historical datasets.

My goal was to make charts that could:

• Compare performance across time (votes, seats, etc.)
• Use party logos as data points
• Display multilingual tooltips
• Work on mobile and large screens without losing meaning

Overview​

Once the schema and core features were taking shape, I needed a scalable way to manage both frontend and backend in a single codebase. My goals were:

• Reduce context switching
• Share types between API and UI
• Optimize for developer speed and clarity

I chose a monorepo setup using PNPM workspaces. This let me keep backend (NestJS), frontend (Next.js), and shared types/utilities in separate packages—but in one unified repository.

Monorepo Structure​

Here's the high-level layout I landed on:

apps/
  ├── frontend/     # Next.js app (SSR, client, UI logic)
  └── backend/      # NestJS API with Prisma
packages/
  ├── shared/       # Common interfaces, enums, helper functions
  └── config/       # Shared tsconfig, eslint, env loaders
prisma/             # Central schema, migrations
scripts/            # Utility scripts for seeds, exports

Overview​

Designing a database schema that reflects real-world complexity is one of the most important architectural decisions in any data platform. In this post, I share how I modeled complex relationships using Prisma ORM with a focus on extensibility, multilingual support, and practical backend integration.

The system supports elections, leaders, parties, governments, scandals, polls, and more—each with overlapping relationships, dynamic behavior, and historical timelines.

Overview​

This post outlines the architectural foundation I laid for building a real-world fullstack platform from scratch. The goal was to support a growing, data-rich application while keeping development modular, testable, and extensible.

I chose a stack centered around NestJS and Next.js with Prisma ORM and MySQL, aiming for type safety across the stack and a clean separation between backend services and the frontend UI.

Why I Built This​

The platform was designed to serve as a public data explorer for civic and political datasets. It needed to:

• Display complex relationships (leaders, parties, elections, content)
• Scale across time (historical data, future updates)
• Be multilingual (English and Nepali)
• Allow feature layering (polls, ratings, approval metrics)
• Expose secure APIs for multiple clients

Rather than using off-the-shelf CMS tools, I opted to build a bespoke platform tailored to domain logic and long-term extensibility.

Key Concepts and Challenges​

1. Modular Backend Design (NestJS)​

NestJS made it easy to separate services by domain: elections, leaders, parties, polls, contents, and so on. I used feature modules, each with its own DTOs, services, and controller layer. This enabled:

• Independent testing and caching
• Cleaner route control
• Ability to extend domains (e.g. attach content to any resource)

2. Type-Safe Data Layer (Prisma + MySQL)​

The Prisma schema models were written to reflect real-world civic and political relationships:

• Polymorphic fields via resourceType + resourceId
• Soft deletes and timestamps
• Dual-language fields: name, nameLocal, titleLocal, etc.

3. Frontend and API Contracts​

The UI is powered by Next.js with Mantine + TailwindCSS. I ensured strong alignment between frontend and backend through shared types and predictable endpoints, like:

• /api/v1/parties/:id
• /api/v1/elections/:id
• /api/v1/polls/:id

4. Multi-Channel Architecture​

The platform is designed to serve:

• Static SSR frontend (Next.js)
• Admin dashboard (coming soon)
• Public API consumers (researchers, journalists)

Real Implementation Examples​

Prisma Example (Polymorphic Content)​

model Content {
  id           Int      @id @default(autoincrement())
  resourceType String   // LEADER, PARTY, ELECTION, etc.
  resourceId   Int
  title        String
  content      String
  titleLocal   String?
  contentLocal String?
  createdAt    DateTime @default(now())
}

NestJS Module Structure​

src/
  └── elections/
        ├── elections.service.ts
        ├── elections.controller.ts
        ├── dto/
        ├── elections.module.ts

Next.js + Mantine UI​

<Card>
  <Title>{party.name}</Title>
  <Text>{party.descriptionLocal}</Text>
</Card>

Lessons / Takeaways​

• Build around your data, not your UI. Data modeling upfront saved major refactoring.
• Invest in multilingual support early — it's harder to retrofit.
• NestJS with Prisma and Next.js offers a highly productive fullstack foundation.
• Use polymorphic content linking sparingly and deliberately.

This architecture has held up well as I’ve expanded the platform to include polls, ratings, scandal timelines, and trend visualizations.

More details on how I structured the Prisma models and handled localization coming in the next article.

Creating a file in client side (browser) is something we may have to do frequently. Every time I have to work with it I try to google and always end up with the long solution. After digging and doing some research I found this clean way to create file and blob from data uri.