TekPlace – Building r/place for My School

Final Pic

Collage

I built TekPlace as a side project during my time at Epitech. The concept is simple: a shared canvas where students can place one pixel every 5 minutes, just like Reddit’s r/place.

What makes this project special isn’t the tech stack—it’s that people actually used it. That’s when the real learning started.

Why I Built This system

  • Bugs that only appeared in production

One time I pushed a “small” code change that corrupted part of the database. The canvas still worked, but the pixel history was gone—completely breaking the replay feature. That was my “oh shit” moment about production changes.

How It Works

Frontend (Next.js)

Simple React app with a canvas element. Users authenticate with their Epitech Microsoft account via Azure AD, pick a color, click a pixel, and wait 5 minutes to place another.

Backend (Express.js)

Handles authentication, validates pixel placements (coordinates, cooldown, color), and stores everything in MongoDB. The interesting part is the WebSocket layer that broadcasts updates to everyone in real-time.

Real-time Updates

Here’s where it gets interesting. My first version had no WebSocket—users had to refresh to see new pixels. It worked, but felt dead.

Adding Socket.io changed everything. Now when someone places a pixel, everyone sees it instantly. But I didn’t send individual pixel events—that would hammer the server. Instead, I batch updates every 100ms and broadcast them together. Much more efficient.

The Problem: It Doesn’t Scale

As more pixels got placed, the canvas became slow to load. Right now, I’m loading all pixels from MongoDB on every page load. When you have 10,000+ pixels, that’s a problem.

What Reddit r/place Does Better

Reddit’s r/place handles millions of pixels without breaking a sweat. How?

  1. Image-based storage: They don’t store individual pixel documents. They store the canvas as an actual image file (PNG) and serve it directly. Way faster than querying a database.

  2. Client-side caching: Once you load the canvas, it’s cached. Only new changes come through WebSocket.

  3. Chunking: They split the canvas into tiles (like map apps do). You only load the visible portion, not the entire thing.

  4. CDN: Static canvas snapshots are served from a CDN, not the application server.

Lessons Learned

Technical Stuff

  • WebSocket batching is essential for real-time apps with multiple users
  • Database design matters—storing 50,000 individual documents when you could store one image is dumb
  • Client-side caching should be built in from day one
  • Always have a way to rollback database changes

The Important Part

Building something people use is completely different from building something that “works.” Your users will find every edge case, stress test your system accidentally, and show you where your architecture falls apart.

I learned more from this project than from any tutorial or course. Not because the code is perfect (it’s not), but because I had to make it work for real people.

What’s Next?

That was a fun project, if i have the occasion to make fun project like this, il do it for sure, but for now i want to focus on software developpement and low level programming.

Try It

The code is on GitHub: TekPlace

timelapse-tekplace