Coder Legion - Recent posts tagged githubchallenge

I Built a CLI Tool That Fixes the "Bro Send the .env File" Problem

Thu, 01 Oct 2026 12:21:58 +0000

What I Built

Every dev team has this conversation. Someone joins a project, opens their terminal, and the first message they send is "bro can you send the .env file" — and someone else pastes it raw on WhatsApp or Slack like it's nothing. API keys, database passwords, Stripe secrets, all of it flying around in plaintext on chat apps.

I built envman
a CLI tool that syncs .env files across dev teams securely. Two commands is all it takes:

envman push   # encrypts your .env and uploads it
envman get    # pulls, shows a diff, asks before overwriting

The entire .env is encrypted with AES-256-GCM on your machine before it ever leaves it. The server stores only ciphertext. Even if the database gets compromised, secrets are unreadable without the user's token. Built entirely in Go — a CLI binary and a REST API backend with JWT auth, role-based access control (owner, coordinator, member), and a full audit trail of every push.

Demo

GitHub: https://github.com/SaranHiruthikM/envman

$ envman register
Name: Saran
Email: saran@example.com
Password:
Registered and logged in successfully

$ cd myproject
$ envman init
Project name: my-app
Project 'my-app' created and linked
.envman.json created — commit this to git

$ envman push
Secrets pushed successfully

# teammate on another machine
$ envman get
Changes:
  + STRIPE_KEY=*** (new)
  ~ DATABASE_URL=*** (changed)

Apply changes? [y/n]: y
.env updated

The Comeback Story

This project lived in my head for weeks. I knew the problem was real — I had sent .env files over WhatsApp myself more times than I want to admit. But every time I sat down to build it I got stuck on questions I hadn't answered: where do secrets actually live, how do roles work, what happens when two people have conflicting values, how does encryption work without a shared key.

The project had a rough main.go and nothing else.

What changed: I forced myself to design everything before touching code. The database schema, the API endpoints, the role system, the encryption approach — all of it locked down first. Once the design was solid, the code almost wrote itself. In three weeks I went from a blank file to a working CLI with a full backend, migrations, middleware, client-side encryption, and a diff engine.

The hardest part wasn't the code. It was resisting the urge to skip the design phase and just start typing. Every hour I spent thinking before coding saved me three hours of rewriting later.

The moment it clicked was when I ran:

rm .env
envman get
cat .env

And my secrets came back perfectly decrypted. That felt real.

My Experience with GitHub Copilot

I used Copilot mostly as a thinking partner rather than a code generator. The parts where it genuinely helped were the repetitive but error-prone ones — writing SQL scan statements where column order matters, getting the AES-GCM nonce handling right, and wiring up cobra command flags.

What surprised me was how useful it was for catching things I would have missed on a first pass — like forgetting a return after an error response, or using || instead of && in a role check that would have let anyone through. Small things that would have cost me 30 minutes of debugging each.

Where I deliberately didn't use it was in the design decisions — the schema, the role model, the encryption architecture. Those needed to be mine. Copilot is good at "how do I write this" but the "what should I build and why" has to come from you. That line matters more than people admit.

envman is live, open source, and something I'll actually use on my own projects. That's the bar I set for myself — build something real enough that you reach for it yourself.

Any doubts, questions or suggestions, you can reach out to my mail.

Finishing the e-commerce app I abandoned in 2023

Sun, 30 Aug 2026 14:13:50 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

GlowStore — a full-stack MERN e-commerce store (React + Redux + Express + MongoDB).

Back in 2023 I built this as my university Web Engineering final project. I ran
out of time, handed in what I had, and never touched it again. When I reopened
it for this challenge I found something funny: the backend was basically
finished — JWT auth, products, orders, reviews, search — but the React
frontend never actually talked to it. It was a good-looking shell with fake
logic bolted on. So "finishing it" meant connecting the two halves and making it
a real store you can actually shop in.

Repo: https://github.com/hashaam-011/Web-Engineering

Demo

Before — the entire app was just a fake login screen. Typing anything (or
nothing) and clicking "Log in" flipped a boolean and "logged you in":

After — a working storefront with products from the database:

A real product detail page (was literally <h1>DetailsPages</h1> before):

You can run it yourself in two terminals (no database setup needed — it boots an
in-memory MongoDB and seeds itself):

cd backend && npm install && npm start   # http://localhost:4000
npm install && npm start                 # http://localhost:3000

Demo login: user@example.com / 123456 — or register a new account.

The Comeback Story

Here's what the project looked like before, and what I changed:

Before	After
Login dispatched a boolean and ignored your credentials	Real login/register against the API with JWT + bcrypt
Frontend never called the backend (no axios anywhere)	Axios client with token injection; products load from MongoDB
Product details page was `<h1>DetailsPages</h1>` and wasn't routed	Full details page (image, price, stock, rating) routed by slug
Cart was local-only; "checkout" button did nothing	Persistent cart → checkout → real order placed and saved
Backend had a reviews endpoint the UI never used	Product reviews: read them and post your own with a star rating
Only 3 routes; most of the app was unreachable	Home, login, register, details, account, checkout, orders
Typos baked in (`Regsiter`, `isLoggIn`), `console.log` in render, logo linked to a random site	Cleaned up, renamed, fixed scroll/header bugs
A live MongoDB password was committed in `.env`	Removed from tracking, `.env.example` added

I tracked the whole revival in 30 small commits so the before → after journey
is visible in the history, from "stop tracking node_modules" to "add the orders
page."

My Experience with AI-Assisted Development

I leaned on AI assistance heavily to finish this. The most useful parts:

Mapping the gap fast. The first win was having the codebase read end-to-end
and getting a precise list of what worked vs. what was fake — that turned a
vague "it's unfinished" into a concrete checklist.
Wiring the integration layer. Generating the axios client, the Redux
thunks for login/register, and the product/cart/order slices was where it saved
the most time — lots of boilerplate that's easy to get subtly wrong.
Filling the missing pages. The checkout form, order summary math (items +
shipping + tax), and the orders history page came together quickly.
Unblocking the environment. Docker wouldn't start on my machine, so instead
of stalling I switched the backend to an in-memory MongoDB with auto-seeding —
now anyone can clone and run it with zero setup.

The thing I'd tell other people reviving an old project: don't start by writing
code. Start by getting an honest map of what's actually there. Half of "finishing"
turned out to be deleting fake logic, not adding new features.

My First Global Hackathon: What I Learned Building Moonsu Link

Sat, 04 Jul 2026 02:55:05 +0000

This was my first global hackathon, with 500+ participants from around the world, and although I didn’t win, I’m honestly proud of how much I learned from the experience.

I worked on Moonsu Link, a project I care about deeply. It wasn’t just about building something technical. It was about trying to solve a real problem and pushing an unfinished idea all the way into something more complete, more usable, and more meaningful.

Like many hackathon projects, Moonsu Link came with its own challenges. There were moments of uncertainty, moments where the product needed more structure, and moments where it would have been easy to slow down or stop. But I kept going because I believed the idea was worth finishing.

The Power of Collaboration & Community

What made this experience special was the teamwork. Building with others, sharing ideas, dividing responsibilities, and trying to keep the momentum alive taught me a lot about collaboration. A hackathon is not just about code. It is also about communication, trust, iteration, and resilience.@alchemycodes @yvesdylane

I also learned that progress matters, even when the final result is not a win. Finishing something, improving it, and learning through the process can be just as valuable as a prize.

One of the things I’m happy about is that I received a badge from the DEVPost community. That recognition means a lot to me because it reflects the effort, growth, and persistence behind the project.

Key Takeaways

This hackathon reminded me that:

First attempts are still valuable – Every expert was once a beginner. Starting is half the battle.
Teamwork makes a huge difference – Bouncing ideas off others and distributing tasks accelerates growth.
Challenges are part of the process – Friction and bugs are inevitable; navigating them builds engineering maturity.
Not winning does not mean losing – The knowledge and connections gained are permanent assets.
Learning and finishing count – Shipping a complete product cycle is a victory in itself.

Moving Forward

Moonsu Link may not have taken the top prize, but it gave me something important: experience, confidence, and a stronger mindset for the next challenge.

I’m grateful for the opportunity, grateful for the people I worked with, and grateful that I chose not to give up.

Have you ever participated in a global hackathon? What was your biggest takeaway from your first dev challenge? Let's connect in the comments below!

From Prototype to Production: Finishing Moonsu Link, a Chat-Native Agricultural Marketplace for Cameroon

Sat, 04 Jul 2026 02:30:59 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What We Built

Moonsu Link is a chat-native agricultural marketplace built for farmers and buyers in Cameroon.

In Cameroon, agriculture is central to daily life, but the way products are bought and sold is still fragmented. In many towns, roadside markets and middlemen control access to buyers. In rural areas, farmers often depend on word of mouth, informal contacts, or market days to move their goods.

That creates real friction.

A farmer in Bamenda, Bafoussam, Douala, or Yaoundé may have produce ready, but still struggle to find a buyer quickly, get a fair price, or know where demand is strongest. At the same time, many people already use WhatsApp and Telegram every day, while mobile data costs, app installs, and complicated onboarding can get in the way. Language matters too. Cameroon is bilingual, and any useful product has to feel natural in both English and French while staying simple enough for users with different levels of digital comfort.

Moonsu Link was built to close that gap by bringing the marketplace into the chat apps people already use. The goal is to reduce friction and make trade feel more direct, local, and trustworthy.

The idea is simple:
help farmers list produce easily, help buyers search in plain language, and let both sides trade without needing a separate app.

Instead of pushing users into a dashboard-first experience, Moonsu Link works through WhatsApp and Telegram, the platforms people already know.

With Moonsu Link, a farmer can list produce with location, price, quantity, and optional photos. Buyers can search naturally, compare listings, check market prices, and express interest. The platform also supports farmer verification, community reports, farming advice, voice messages, and cross-platform use across WhatsApp and Telegram.

What began as an unfinished idea is now a real product with a clear user flow, a polished web presence, and a backend that connects messaging, AI, search, verification, and notifications into one system.

Demo

Live app: https://moonsulink.vercel.app
GitHub repository:https://github.com/yvesdylane/Moonsun-Link-api , https://github.com/yvesdylane/MoonsuLinkFrontend
Video walkthrough: https://youtu.be/6skq9w_mw-s?si=c5YCVunZ3RC5Qfqs
Screenshots:!Moonsu Telegram Bot(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/b1ewivz77iwyli4gh01a.jpeg) ,
!Moonsu Whatsapp (https://dev-to-uploads.s3.amazonaws.com/uploads/articles/op3lmh99vio6zbxu4bcl.jpg) ,
!Moonsu Admin Dahboard(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cit70l8bc84pijmworrj.jpg)

The Comeback Story

!Moonsu website before finishathon(https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2nlqiwperncglto84re2.png)
Moonsu Link did not start as a finished product. It began as a prototype built around a real problem, but like many hackathon projects, it never fully crossed the finish line.

The idea was strong, but the product needed more structure, cleaner UX, better flow, and real end-to-end functionality before it could genuinely help users.

For this challenge, We came back to it with a different mindset. We treated it like a real product, not just a demo.

That meant focusing on the things that matter most:

making the experience feel unified across WhatsApp, Telegram, and the web
refining the landing page so the product story is clear immediately
building a visual identity that reflects a Cameroon-first agricultural context
improving backend flows for messaging, listings, verification, search, and notifications
making the product feel trustworthy, usable, and ready to present to real users

The biggest difference is that the project is no longer just an idea. It now has a clear user journey, a stronger brand, and real functionality that shows what the product is supposed to do.

Our Experience with GitHub Copilot

GitHub Copilot helped me move faster and finish with more confidence.

It was especially useful for:

building repetitive frontend sections faster
cleaning up component structure
speeding up backend boilerplate and integrations
iterating on UI copy and layout
reducing friction while refactoring and finishing incomplete parts of the project

What mattered most was not just speed, but momentum.

Copilot helped us keep the project moving when we needed to turn unfinished ideas into working features and a coherent product experience.

Why This Project Matters
Agriculture is one of the most important parts of everyday life in Cameroon, but many farmers still struggle with discovery, pricing, trust, and access to buyers.

Moonsu Link tries to solve that with one simple idea:

Meet users where they already are.

No app install
No complicated onboarding
No unfamiliar workflow
Just a practical marketplace inside the chat platforms people already use

That is why this project felt worth finishing. It is not just a technical build. It is a tool that could genuinely reduce friction for farmers and buyers.

The Stack

Frontend:
Next.js 16, React 19, TypeScript, Tailwind CSS v4, Framer Motion

Backend:
FastAPI, PostgreSQL, Telegram Bot API, WhatsApp integration, AI-powered message handling, translation, voice transcription, image upload, and admin APIs

What Changed During the Comeback

The project went from unfinished to presentable by focusing on:

a clearer product story
a stronger landing page
better visual consistency
real cross-platform marketplace flows
verification and trust features
AI-assisted handling of user messages
more polished communication for farmers and buyers

Authors
Main Author: Yves Dylane @yveane
Co-Author: _Chestly Amahndong @chestlyace
Co-Author: Kanjo Elkamira @alchemycodes

I've Been Building an LMS for a Year. Finish-Up-A-Thon Made Me Actually Finish It.

Thu, 25 Jun 2026 09:42:50 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Training Theatre (TTT) is a multi-tenant LMS where instructors can build a course in three different shapes, depending on how they teach:

Story — long-form written content for instructors who teach the way essayists write.
Video — the conventional LMS path everyone already knows: upload a video, chapter it, ship it. The Udemy/Coursera shape.
Slide — composable decks built from a catalog of 20+ templates. This is where most of TTT's design budget goes, and it's the part of the product that doesn't look like every other LMS.

Before a slide is ever built, they walk through a setup flow: what they're building (a standalone course or a bundled program), how the course is structured (multi-format modules or a repeating pattern), and which teaching pattern fits their content. By the time they land in the slide editor, the course shape is already decided.

On the slide side, the workflow goes like this: an instructor opens the slide editor, picks a layout from the catalog (hero-text, three-column, comparison, team, closing-cta, and so on), and lands on a canvas. Each template exposes a set of named zones — a headline zone, an items zone, a cta zone, whatever the layout needs — and each zone declares which section types it accepts (text, list, image, callout, quote, stats, table) and how many sections it can hold. The instructor fills the zones, the editor persists the result as a SlideGroup row (template choice, zone assignments, background, accent color, speaker notes), and the learner sees that same data render through SlideCanvas inside LearnerSlideDeck. The whole catalog is declarative — adding a new template means defining its zones, building its editor canvas, and building its learner renderer.

The stack is Next.js (App Router) + TypeScript + Prisma/PostgreSQL, with Zustand and React Query on the frontend, Tiptap for rich text, and Tailwind for styling.

TTT is also my first real-world professional project. I've been building it alongside my 9-5 work as a technical support — for over a year now, and most of what I currently know about shipping software I learned by getting it wrong here first: the bad schema choices I had to migrate out of, the audit logging I retrofitted across the codebase, the moderation flow I rebuilt twice. So finishing the half-done parts isn't just about cleaning up the codebase — it's about turning TTT into the portfolio piece I can confidently point to when I'm pitching for contracts or interviewing for a full-time engineering role. Finish-Up-A-Thon was a deadline I was glad to have.

For the challenge, I focused on the slide template system — the part of the product I'm proudest of. The goal was to give instructors more layout options to design with, so I worked on three templates: closing-cta, feature-list, and agenda-grid. Some were new builds, some were modifications to existing templates to support layout patterns the original implementations couldn't handle.

Demo

Project: Training Theatre on GitHub

Live URL: Training Theatre

Before & After — Slide Templates

Before	After

Video Walkthrough

Before
After

The Comeback Story

The shape of the problem

TTT's slide system has an opinionated architecture. Every template is a triple:

A config schema that declares the editable zones (headline, body, items, icons, tags, CTA, etc.) and feeds the editor's PerItemConfigSlot so each item gets its own inline controls.
An editor canvas that renders the same component the learner will see, but wired to the Zustand store so edits are live.
A learner renderer consumed by SlideCanvas inside LearnerSlideDeck, with preserveAspect for desktop, single-column stack on mobile, and accent/background tokens pulled from getSlideColors(group).

All three of the templates I worked on had to fit this triple pattern. For some, that meant building all three pieces fresh; for others, it meant going back into the existing config schema or renderer and extending it to support layout shapes the original implementation hadn't planned for. Either way, the shape of the work was the same: zones, canvas, renderer, ship.

What I built for each

closing-cta — A closing slide built around three zones: a two-part headline (main statement + subhead), an optional call-to-action with an instructor-set button label, and optional contact info that can render as a single line or a list of items. The kind of slide a course ends on when the instructor wants the learner to enroll in the next thing, book a session, or just walk away with a way to reach them.

feature-list — An image panel alongside a scrollable vertical list of 3–8 feature rows, each with an icon, a heading, a short body, and pill tags for stats or labels. The right pick when an instructor wants to walk through a set of features, plan inclusions, or capabilities and has a screenshot or visual to anchor the slide. It sits between feature-grid (which tiles features into a grid) and split-image (which works for mixed prose rather than uniform itemized rows).

agenda-grid — A denser cousin of the existing agenda template. Where agenda is a vertical list, agenda-grid is a card grid: up to 8 agenda items, each card carrying a topic heading, a description, and a list of meta lines (durations, presenters, room numbers — whatever the instructor needs). It also exposes a header-bar title and a dual footer (left and right text), so it works equally well as a session agenda, a workshop schedule, or a module table-of-contents.

Each one slots into the existing system without special-casing: the editor picks them up via the registry, the moderation preview renders them via the same SlideCanvas, the learner deck navigates through them with the same keyboard handlers, and the mobile breakpoint collapses them the same way every other multi-column template collapses.

Why this is the finish

The catalog was solid but had thin spots — places where instructors were forcing a layout that didn't quite fit what they were trying to say. There wasn't a clean way to end a course on a strong call-to-action, the feature list couldn't carry the kind of structured content people were trying to put in it, and there was no good dense-grid layout for agendas with a lot of items. These three templates close those gaps. Instructors have more shapes to design with now, and that's all I wanted from this work.

My Experience with GitHub Copilot

I used Copilot in two places for this: Copilot Web for generating the new templates, and the Copilot VS Code extension for fixing TypeScript errors as they came up. They played different roles, and the honest version of the story is that Copilot is dramatically more useful when you stop asking it to invent your architecture and start asking it to follow one you've already built.

My Copilot Web workflow looked like this:

Show, don't tell. Before asking Copilot to write feature-list, I'd paste the entire triple for a sibling template — feature-grid's config schema, its editor canvas, and its learner renderer. Copilot needs to see the pattern before it can extend it. Without the existing files in context, it would invent plausible-but-wrong conventions; with them, it tracked my naming, my zone-assignment patterns, and my PerItemConfigSlot wiring.

Scope tightly. Instead of "build the closing-cta template," I'd ask for the config schema first, review it, then the canvas, review it, then the learner renderer. Three small, well-defined slots beats one big "build me a template" prompt every time.

Iterate against the convention. When Copilot drifted — forgetting that tagsConfig needs config.tags ?? [] as a fallback, or returning a hardcoded color instead of pulling from getSlideColors, or skipping the mobile stack breakpoint — I'd quote the convention back and ask for a fix. That's much cheaper than rewriting from scratch.

The VS Code extension played a different role: TypeScript triage. TTT has its share of generic-heavy types — Prisma's generated types, Zustand stores with typed slices, discriminated unions on section types — and when something didn't compile, having an inline assistant that could read the actual error against the surrounding types saved a lot of context-switching to the browser. Most of my use there was on the order of "why is this SlideSection not assignable to that SlideSection" or "how do I narrow this discriminated union without writing five type guards by hand." Quick, targeted, in-the-flow.

The main friction across both surfaces was token usage. Pasting the full triple for a sibling template — config schema, editor canvas, learner renderer — plus the registry, plus the type definitions, plus the helper utilities, adds up fast. I burned through context faster than I expected on the first template, then learned to trim ruthlessly: just the one most-relevant sibling, just the types I'd actually reference, just the helper I was about to call. By the third template the prompts were leaner and better-targeted, and the responses got sharper too. The constraint forced better prompt discipline — a roundabout win.

What Copilot did for me was speed up the typing. I still had to figure out what each template should look like, what to make configurable, what it should do on mobile. Those weren't decisions the tool could make for me. But the boilerplate moved faster.

Simple Auth Service to a Distributed Authentication Platform with Kafka, Debezium, and Observability

Wed, 17 Jun 2026 18:53:34 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

I built a Distributed Authentication System as a long-term learning project to explore real-world backend and distributed systems concepts through a familiar use case: user authentication.

The project started as a simple authentication service with signup and login functionality. Over time, it evolved into a distributed architecture that incorporates event-driven communication, change data capture (CDC), observability, horizontal scaling, and performance testing.

The current system consists of:

PostgreSQL as the primary source of truth for user credentials
Redis for refresh token storage and session management
Kafka as the event streaming platform
Debezium for Change Data Capture (CDC) from PostgreSQL
MongoDB for materialized user profile documents
Nginx for load balancing across multiple service instances
Prometheus and Grafana for monitoring and observability
k6 for load testing and performance analysis

When a user signs up, the authentication service writes user data to PostgreSQL. Debezium captures the database change and publishes it to Kafka. A separate profile service consumes the event and creates a corresponding profile document in MongoDB. This allows services to communicate asynchronously while keeping the architecture loosely coupled.

Beyond implementing features, the main goal of this project was to understand the trade-offs involved in building distributed systems. Throughout development I conducted load-testing experiments, measured replication lag, analyzed bottlenecks, and documented the architectural decisions that shaped the system.

This project has become my personal distributed systems playground where I can experiment with new ideas, evaluate design decisions, and learn how real systems behave under load.

Demo

GitHub Repository

Repository:
https://github.com/c0d3l0v3r-HeHe/distributed-auth-system

The repository contains additional architecture diagrams, performance experiments, load-testing results, observability metrics, and detailed documentation covering the design decisions and trade-offs explored throughout the project.

Rather than reproducing all of those results here, I've kept this submission focused on the project's journey and evolution. If you're interested in the deeper technical details, bottleneck analysis, replication lag measurements, scaling experiments, or observability setup, you'll find them documented in the repository.

The Comeback Story

This project was not originally intended to be a standalone distributed authentication platform.

In May, I started building it as the authentication backend for a larger job portal project. The initial goal was fairly straightforward: implement signup, login, token management, and the supporting infrastructure needed for user authentication.

After building the core authentication service and setting up the initial infrastructure, I shifted my focus to other work and the project was left unfinished. While the foundation existed, many of the ideas I wanted to explore—distributed systems patterns, observability, scalability, and performance analysis—were still missing.

A few weeks later, I came across the GitHub Finish-Up-A-Thon Challenge and decided to revisit the project instead of letting it remain another abandoned repository.

Rather than simply cleaning up old code, I used the opportunity to significantly expand the project and turn it into a distributed systems playground.

During the revival, I:

Added Redis-based refresh token management
Implemented a CDC pipeline using PostgreSQL, Debezium, and Kafka
Added a dedicated profile service backed by MongoDB
Introduced Prometheus metrics and Grafana dashboards
Added k6 load-testing infrastructure
Scaled the authentication service horizontally behind Nginx
Conducted multiple performance experiments and documented the results
Created architecture diagrams and expanded the project documentation

One of the most valuable outcomes of revisiting the project was discovering bottlenecks that only became visible under load. While scaling the authentication service improved CPU utilization, load testing revealed that MongoDB and the CDC pipeline became the primary bottlenecks. Investigating these trade-offs taught me far more than simply building the original authentication service.

By the end of the challenge, the project had evolved from an unfinished backend component into a fully documented distributed authentication system that I can continue using to explore distributed systems concepts, scalability patterns, and performance engineering.

My Experience with GitHub Copilot

GitHub Copilot acted as an implementation and exploration partner throughout the revival of this project.

For many components, I first designed the architecture and wrote the interfaces, function signatures, and high-level implementation plan. I then used Copilot to generate boilerplate code, suggest implementations, and accelerate repetitive development tasks.

Copilot was particularly useful for:

Generating service scaffolding and repetitive CRUD logic
Assisting with Docker Compose configuration
Helping configure Prometheus metrics collection
Suggesting Kafka consumer and producer implementations
Writing integration and infrastructure tests
Explaining configuration options for Debezium and Kafka Connect
Speeding up refactoring and cleanup work

One workflow I found especially effective was defining the architecture and API contracts myself, leaving implementation placeholders, and then using Copilot to generate an initial implementation. This allowed me to focus more on system design decisions and less on repetitive coding.

I also used Copilot while setting up and validating the distributed architecture. It helped me troubleshoot configuration issues, understand service interactions, and quickly iterate on infrastructure changes during development.

The biggest benefit wasn't code generation itself—it was the ability to move from an idea to an experiment much faster. Since this project is intended as a distributed systems learning playground, that rapid feedback loop allowed me to spend more time investigating architectural trade-offs, performance bottlenecks, and scalability challenges.

Feedback Welcome

This project started as a learning exercise and has evolved into my personal distributed systems playground.

If you're an experienced backend or distributed systems engineer and happen to read this submission, I'd genuinely appreciate any feedback on the architecture, design decisions, bottlenecks, or trade-offs discussed throughout the project.

Some areas I'm currently thinking about include:

Improving the CDC pipeline under higher load
Reducing replication lag and read amplification
Better approaches to profile materialization
Scaling strategies beyond the current setup
Observability improvements and production-readiness considerations

Constructive criticism, alternative approaches, and architecture suggestions are all welcome. One of the main goals of this project is to learn from engineers who have solved these problems in real systems.

Reviving a 12K+ Star Abandoned Library: toastr-next v3

Sun, 14 Jun 2026 03:30:38 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

toastr-next v3 a complete revival of CodeSeven/toastr, one of the most-starred abandoned JavaScript libraries on GitHub with 12,000+ stars and no meaningful commits since 2016.

toastr was the go-to notification library for millions of developers. But time wasn't kind to it. it required jQuery, had no TypeScript, no dark mode, no accessibility, and its Gulp + LESS build chain was completely dead. It was a library everyone knew but nobody could use in a modern project without guilt.

I picked it up, stripped it to the bones, and rebuilt it from scratch for 2026.

From this :

// 2015 — drag in jQuery just to show a toast
<script src="jquery.min.js"></script>  // 30 KB
<script src="toastr.min.js"></script>  // 5 KB
// Total: ~87 KB of dead weight

toastr.success('Hello!');

To this :

// 2026 — zero dependencies, full TypeScript, ~4 KB gzipped
import { toastr } from 'toastr-next';

const toast = toastr.success('Hello!');
await toast.dismissed; // Promise API!

~4 KB gzipped. No jQuery. No bloat. Just toasts.

Demo

Dark mode — toasts firing with progress bar

Light mode — same demo, toggled with the ☀️ button

Live Demo: toastr-next.vercel.app/

npm: npmjs.com/package/toastr-next

GitHub: github.com/Divyesh-5981/toastr-next

The Comeback Story

Where it was

The original repo — abandoned since 2016, 12k stars, zero recent activity

Problem	Detail
jQuery required	~87 KB overhead just to show a notification
No TypeScript	No types, no IntelliSense, no safety
No dark mode	Hard-coded colors, no CSS variables
No accessibility	Screen readers couldn't detect toasts at all
JS-driven animations	Layout thrash, janky on low-end devices
No Promise API	No way to await a toast dismissal
No keyboard support	Couldn't dismiss with Escape key
Dead build toolchain	Gulp + LESS, completely unmaintained since 2016
No ESM support	Global UMD only, no tree-shaking

What I built

TypeScript Rewrite (Zero Dependencies)

No jQuery: 100% strict TypeScript with full JSDoc.
Universal Formats: Ships in ESM, CJS, UMD, and IIFE (works from Vite to raw <script> tags).

CSS-First Theming

Modern CSS: Uses CSS variables instead of inline JS styles.
Themes & Motion: Auto dark mode (prefers-color-scheme), manual toggle (localStorage), and prefers-reduced-motion support.
Layouts: 4 pure CSS animation presets (Fade, Slide, Bounce, Flip) and native RTL support.

♿ Accessibility (built to WCAG 2.1 AA practices)

Screen Readers: Dynamic ARIA live regions role="alert" (assertive) for errors/warnings and role="status" (polite) for success/info, with aria-atomic.
Keyboard Navigation: Toasts are focusable and sit in the natural tab order; pressing Escape while a toast is focused dismisses it, and auto-dismiss pauses while a toast holds focus.

Modern API

Async & Events: Promises (await toast.dismissed) and lifecycle event subscriptions (toastr.subscribe, which returns an unsubscribe function).
DX & Security: Automatic CSS injection (no separate stylesheet import), native React wrapper (useToastr), and built-in XSS protection.

Production Ready

Lightweight: ~4 KB gzipped (~2 KB JS + ~2 KB CSS) vs the original ~87 KB jQuery version.
Live: Available on npm as toastr-next with a live Vercel demo.

Size comparison

	toastr v2 (old)	toastr-next v3
Total size	~87 KB (with jQuery)	~4 KB gzipped
Dependencies	jQuery required	Zero
TypeScript	✕	✓
Dark mode	✕	✓ Auto + manual toggle
Accessibility	✕	✓ WCAG 2.1 AA practices
Promise API	✕	✓
React support	Third-party only	✓ Built-in
Animations	JS (jQuery)	✓ CSS @keyframes
Bundle formats	Global UMD only	✓ ESM, CJS, UMD, IIFE
CSS import	Required	✓ Auto-injected

My Experience with GitHub Copilot

I used GitHub Copilot as a pair programmer throughout the entire revival not for autocomplete, but as a genuine collaborator at every architectural decision.

Here's exactly how it helped, step by step.

1. Deciding what to keep

Before writing a single line, I needed to know what was worth saving from 14 years of jQuery-tangled code.

Prompt:

"Here is the original toastr v2 source. What's worth keeping
for backward compatibility and what should be completely rewritten?"

Copilot identified the API surface success, error, info, warning — as the only thing worth preserving. Everything underneath needed to go. This became the guiding rule for the entire rewrite.

2. TypeScript interfaces

With the API surface locked, I needed a clean type system built around it.

Prompt:

"Design TypeScript interfaces for ToastrOptions, ToastResponse,
and ToastEvent. I want every toast call to return a Promise
that resolves when the toast is dismissed."

Copilot designed all three interfaces. The standout was the dismissed: Promise<void> pattern on ToastResponse making every toast awaitable:

const { dismissed } = toastr.success('Changes saved');
await dismissed;
// runs after the toast closes

I didn't ask for this pattern specifically. Copilot suggested it unprompted, and it became the most-loved feature of the rewrite.

3. Theming system

I wanted dark mode to work automatically and be manually overridable without JavaScript touching the CSS side.

Prompt:

"I need a CSS theming system that supports auto dark mode via
prefers-color-scheme AND manual override via a data-theme attribute
on the html element. No JavaScript should be needed for the CSS side."

Copilot proposed the [data-theme] + @media (prefers-color-scheme) layering pattern. The media query handles auto mode; a single attribute flip handles manual override. No JS. No flicker. Just CSS doing its job.

4. Accessibility

I had applied role="alert" to all four toast types, assuming it was correct. I asked Copilot to review before shipping.

Prompt:

"What ARIA roles and aria-live values should toast notifications use
to be WCAG 2.1 AA compliant? Should all toasts use the same role?"

Copilot flagged that role="alert" is assertive it interrupts a screen reader mid-sentence. That's right for errors and warnings, but jarring for a success message. The fix:

Type	Role	Behaviour
`error`, `warning`	`role="alert"`	Interrupts immediately
`success`, `info`	`role="status"`	Waits for a pause

A subtle WCAG 2.1 distinction I would have shipped wrong without this review.

5. CSS auto-injection

Early users kept asking why they had to import the CSS separately. That broke the drop-in promise. I needed the stylesheet bundled inside the JS, self-injecting on import.

Prompt:

"Write a Vite generateBundle plugin that reads the extracted CSS asset
and injects it into every JS chunk as a self-executing style injector.
Add a guard so it only injects once even if the module is imported
multiple times, and make it safe to run during SSR."

Copilot drafted the generateBundle plugin — CSS-to-string conversion plus a self-executing injector that appends a <style id="__toastr_next_css__"> to <head>. The guard checks document.getElementById(...) so it only injects once even if multiple bundles (core + React) load on the same page, and it bails out when document is undefined (SSR-safe). I later refactored it into one shared plugin reused across the core, IIFE, and React builds.

This was the most technically complex Copilot collaboration in the project and the one that impressed me most.

6. Demo page

The final piece was a demo site that actually showed off everything that changed.

Prompt:

"Build a demo page for toastr-next with a quick fire section,
a live playground with dropdowns for type/animation/position,
an animation showcase, a before/after comparison, and a light/dark
theme toggle that persists to localStorage."

Copilot built the full index.html iteratively playground, comparison table, custom ARIA dropdown, and the light/dark toggle with localStorage persistence. I directed; it executed. The entire demo came together in an afternoon.

What I took away

Copilot wasn't writing boilerplate it was catching real bugs, proposing patterns I hadn't considered, and solving problems I didn't know how to start. The dismissed: Promise<void> feature, the WCAG role distinction, and the CSS-injection plugin were all things I got from Copilot that I wouldn't have shipped on my own.

That's the kind of collaboration this challenge is designed to reward.

After the main rewrite, I ran the entire codebase through GitHub Copilot to audit for hidden anti-patterns and code smells. It helped me spot subtle optimizations and edge cases, allowing me to refine the code into a truly polished, production-grade architecture.

The audit - for hidden anti-patterns and code smells.

Improvements - for hidden anti-patterns and code smells.

Working with Copilot felt less like using a tool and more like having a senior developer who knew every API, caught every edge case, and never got tired. The revival that would have taken weeks took days.

Acknowledgements

Huge respect to the original authors — John Papa, Tim Ferrell, and
Hans Fjällemark - who built something so good that developers were still reaching for it a decade later.

This revival exists because their original work was worth finishing ❤️

Coder Legion - Recent posts tagged githubchallenge

I Built a CLI Tool That Fixes the "Bro Send the .env File" Problem

What I Built

Demo

The Comeback Story

My Experience with GitHub Copilot

Finishing the e-commerce app I abandoned in 2023

What I Built

Demo

The Comeback Story

My Experience with AI-Assisted Development

My First Global Hackathon: What I Learned Building Moonsu Link

The Power of Collaboration & Community

Key Takeaways

Moving Forward

From Prototype to Production: Finishing Moonsu Link, a Chat-Native Agricultural Marketplace for Cameroon

I've Been Building an LMS for a Year. Finish-Up-A-Thon Made Me Actually Finish It.

What I Built

Demo

The Comeback Story

The shape of the problem

What I built for each

Why this is the finish

My Experience with GitHub Copilot

Simple Auth Service to a Distributed Authentication Platform with Kafka, Debezium, and Observability

What I Built

Demo

GitHub Repository

Signup Flow

Login Flow

The Comeback Story

My Experience with GitHub Copilot

Feedback Welcome

Reviving a 12K+ Star Abandoned Library: toastr-next v3

What I Built

Demo

The Comeback Story

Where it was

What I built

TypeScript Rewrite (Zero Dependencies)

CSS-First Theming

♿ Accessibility (built to WCAG 2.1 AA practices)

Modern API

Production Ready

Size comparison

My Experience with GitHub Copilot

1. Deciding what to keep

2. TypeScript interfaces

3. Theming system

4. Accessibility

5. CSS auto-injection

6. Demo page

What I took away

Acknowledgements