DEV Community: Cristian Rubio

FakeAPI — A Mutable, Isolated REST Sandbox for Testing and Prototyping

Cristian Rubio — Fri, 29 May 2026 15:21:18 +0000

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

What I Built

FakeAPI is a hosted REST API for testing and prototyping — real in-memory CRUD, no database, no auth. You create a workspace and get your own isolated copy of seed data with full CRUD, filtering, sorting, and pagination across Tasks, Users, and Projects.

There are other tools in this space, but none hit the exact combination I needed:

	JSONPlaceholder	ReqRes	MockAPI	FakeAPI
No signup	✅	✅	❌	✅
Real CRUD (data actually changes)	❌	❌	✅	✅
Session isolation (your data is yours)	❌	❌	❌	✅
Pre-loaded seed data	✅	✅	❌	✅
Reset to seed state on demand	❌	❌	❌	✅
Multiple resource types	✅	❌	✅	✅

JSONPlaceholder acknowledges your writes but doesn't store them. ReqRes returns hardcoded responses. MockAPI requires an account and you define the schema from scratch. FakeAPI is the only one that gives you real, mutable, isolated data without any setup.

Demo

Live: https://fakeapi-kynw.onrender.com (free tier — first request may take ~1 min to wake the server)

# Create your isolated workspace
curl -X POST https://fakeapi-kynw.onrender.com/api/workspaces/

# Browse pre-loaded tasks, users, projects
curl "https://fakeapi-kynw.onrender.com/api/workspaces/{id}/tasks/?status=pending&sort_by=-created_at"

# Reset to seed state any time
curl -X POST https://fakeapi-kynw.onrender.com/api/workspaces/{id}/reset

Interactive docs: https://fakeapi-kynw.onrender.com/docs

The Comeback Story

I built a rough first version in February 2025, deployed it to Render, and forgot about it for 15 months.

Before — a single /tasks endpoint backed by statically generated fake data using faker. No real storage, no isolation, no CRUD. Every caller saw the same global state and couldn't change anything that persisted. The README was one line. There were no tests, no deployment worth sharing beyond a proof of concept.

The core problem was that I'd solved the wrong thing: I had endpoints that returned data, but not an API you could actually use to build or test something. If you created a task, it was gone on the next request. If two people hit it at the same time, they'd interfere with each other. It was a demo, not a tool.

After — the architecture changed completely. Workspaces became the central concept: each caller gets their own in-memory copy of all seed data, isolated from everyone else. You can create, update, delete — and none of it bleeds into another session. A background loop cleans up expired workspaces hourly, each one lives 24 hours and can be extended up to three times.

On top of that: three full resources (Tasks, Users, Projects) with filtering, sorting, and pagination; nested routes like GET /users/{id}/tasks; rate limiting; a full test suite with a coverage gate enforced in CI; a GitHub Actions pipeline; and a landing page.

My Experience with GitHub Copilot

My background is backend. I'm comfortable with Python, APIs, and data modeling — but when it came to building the landing page, I was starting from scratch.

The design I had in mind was a terminal-style interface: monospaced font, a fake browser bar with colored dots, dark mode toggle that persists across sessions. I knew what I wanted visually, but I didn't know CSS well enough to build it confidently. Copilot bridged that gap. I'd describe what I wanted — "a sticky header with a theme toggle that switches between light and dark using CSS variables and saves the preference to localStorage" — and it would give me something that worked. I'd tweak, ask again, and iterate.

What surprised me was how much I actually learned in the process. Because Copilot explained the patterns it used — CSS custom properties, the data-theme attribute approach, the FOUC prevention trick with an inline script before the CSS loads — I came out understanding the code, not just having it. That felt like the right way to use the tool.

If you're building a frontend, testing an HTTP client, or just need a realistic API without the setup overhead, give it a try.

Repository: github.com/cristianrubioa/fakeapi

MeshChat — A Zero-Install Terminal Chat Room Built with GitHub Copilot CLI

Cristian Rubio — Sat, 14 Feb 2026 03:58:33 +0000

🚀 What I built

MeshChat is a terminal-based chat server written in Python (asyncio) that lets anyone join a shared chat room using nothing more than:

nc <host> <port>
# or
telnet <host> <port>

No client binaries.

No accounts.

No setup on the user side.

If you can open a terminal, you can chat.

Repository: https://github.com/cristianrubioa/meshchat

💡 Why I built it

Sometimes you just need a quick local chat room:

A small team on the same network
A classroom or lab
A hackathon
A home LAN

I wanted something that felt like an old-school LAN chat, but with:

modern async Python
a clean CLI
colorful output
basic safety (rate limits, message caps)

MeshChat turns a TCP port into a friendly shared room.

✨ Features

Zero client setup — connect via nc or telnet
Colorful UI — each user gets a unique ANSI color
Chat commands:
- /who
- /me
- /help
- /quit
Optional message history
Rate limiting (anti-spam)
Async I/O with asyncio
Typer-based CLI
Rich terminal formatting
Environment + CLI configuration
Tested with pytest and pytest-asyncio

🧠 How GitHub Copilot CLI helped

I used GitHub Copilot CLI as my “terminal pair programmer” during the entire build.

Biggest productivity wins:

1. Architecture scaffolding

Copilot CLI helped propose a clean modular layout:

network server
room state
client lifecycle
UI formatting
command handling

This let me move fast from a prototype to a maintainable package.

2. Async networking flows

Copilot CLI assisted with:

asyncio.start_server
client connect / disconnect handling
broadcast fan-out
graceful cleanup

These parts are easy to get wrong — Copilot accelerated iteration a lot.

3. UX polish

Instead of manually researching Rich + ANSI patterns, I prompted Copilot CLI for:

per-user colors
action messages (/me)
formatted system events

Result: better terminal UX with less friction.

4. Guardrails

Copilot CLI helped implement:

nickname limits
max message length
rate limiting windows
max users

This made MeshChat safer by default.

5. Tests

I used Copilot CLI to generate pytest-asyncio skeletons and refine edge cases like:

multiple clients
broadcast correctness
command parsing
reconnect behavior

Example prompts (high level)

“Generate an asyncio TCP chat server with shared rooms.”
“Add a Typer CLI with port, room name, history options.”
“Suggest a clean Python package structure for this project.”
“Write pytest-asyncio tests for multi-client broadcast.”

⚡ Quick start

Install

poetry install

Run server

poetry run meshchat

poetry run meshchat --port 2323 --room-name "My Room" --history

Join

nc localhost 2323
# or
telnet localhost 2323

💬 Chat commands

Command	Description
`/who`	List connected users
`/me <action>`	Action message
`/help`	Show help
`/quit`	Disconnect

🧱 Architecture (high level)

meshchat/
├── chatserver/
│   ├── core/        # room, client, message logic
│   ├── network/     # asyncio TCP server
│   ├── ui/          # ANSI/Rich formatting
│   └── main.py      # CLI entry point
└── test/

Flow:

TCP server accepts connections
Each socket becomes a Client
All clients join a shared Room
Messages broadcast to everyone
Formatter styles output

🙏 Inspiration

Inspired by the Go project chat-tails. repo

MeshChat is a Python-first reimplementation with its own:

async architecture
CLI UX
rate limiting
configuration system
development guide

🔮 What’s next

Optional room passwords
Multiple rooms (channels)
Docker image
Presence events (join/leave notifications)
Server-side logging

🏁 Final thoughts

This project was a great way to explore what’s possible when AI meets the terminal.

Using GitHub Copilot CLI directly from my shell made experimentation fast, fun, and surprisingly productive — especially for async networking and CLI tooling.

Thanks for reading!

Happy hacking 👋