Why I Built This

A simple, recurring frustration: every time I needed to shorten a URL, share a file, or paste a code snippet, the tools available were either bloated with ads and accounts I didn't want, or paywalled behind a "pro tier" for features that should be basic. So instead of settling for one more compromise, I built the tool I actually wanted to use — three dev essentials in one clean app: a URL shortener, file sharing, and code paste. No accounts. No tracking. Just fast, reliable, and free.

This was also a deliberate push to build something full-stack, end-to-end — not a frontend demo with a fake API, but a real layered architecture: React + Vite on the client, Node.js + Express on the server, MongoDB for durability, and Redis for sub-100ms redirects. PWA support so it works offline too. The kind of project where every layer actually has to work together, not just look good in a screenshot.

The Story Behind It

It started small — just wanting a personal short-link tool. But the more I used existing services, the more annoyed I got at how much friction they added for something that should be instant: an account wall here, a tracking pixel there, a paste tool that forgot your snippet the moment you closed the tab.

So the scope grew naturally. URL shortening needed analytics and expiry. File sharing needed password protection and download caps. Code paste needed syntax highlighting across enough languages to actually be useful — and a burn-after-read mode for the genuinely sensitive stuff, where the paste hits MongoDB directly and is destroyed the instant it's viewed, no caching, no second chances.

Then came the offline question: what happens if someone's connection drops mid-paste? That's what pushed the PWA layer — IndexedDB queues actions locally, and the moment the connection returns, background sync flushes everything automatically. Nothing lost mid-session.

By the end, it wasn't a side project anymore — it was a proper four-step pipeline: paste or drop → Express validates and writes to MongoDB → Redis caches it with a TTL → you get your link, with analytics and visitor deduplication running automatically via Redis Sets.

Behind the Scenes

• Redis vs Mongo race conditions — early on, writes went to Redis first for speed, but a crash before the Mongo write meant losing data permanently. Flipped the order: Mongo first for durability, Redis second purely as a cache layer.
• Burn-after-read had to bypass caching entirely — the obvious bug: if a "burn" paste got cached in Redis, a second read was still possible from the cache even after the DB copy was destroyed. Fixed by routing burn pastes to hit MongoDB directly, no Redis involvement, ever.
• IndexedDB sync conflicts — figuring out what happens when a queued offline action and a fresh online action both try to write at once. Solved with a proper queue-then-flush pattern instead of firing requests immediately on reconnect.
• Deployment split headaches — frontend on Vercel, backend on Render, meant chasing down CORS errors, environment variable mismatches, and API base URL issues until the two sides actually talked to each other cleanly.
• Visitor deduplication — using Redis Sets to count unique clicks instead of just raw hits, so analytics actually mean something instead of inflating every refresh into a "new visitor."

MIT licensed, self-hostable, and built specifically so it could be forked, broken, and improved by anyone who's tired of paying for things that should just work.

🔗 GitHub for verification: https://github.com/ivengexnce/NextShare