Wefy

So this all started with Flave, the project I built during my final year for codesters.club — right in the middle of a mountain of deadlines, exams, and general senior-year chaos. The app and development itself were solid (good enough, at least), but somewhere in the middle of all that, I kinda got annoyed with fetch...like seriously.

I mean, really. Every single request was an annoying routine: check if anything came back, check response.ok, parse the body, then check if the data was even usable. It felt like I was writing the same boilerplate in every file. So I thought, “Surely there’s a better way.”

And then I remembered Axios!

Except… Axios wasn’t quite it either. It worked, yeah, but it didn’t feel right. It used XHR under the hood, which just didn’t play nice with a Next.js (fetch-first) stack. Stuff like caching, streaming, and all the things Next.js has under the hood were basically redundant.

So instead of just forcing everything into the square hole (iykyk), I wrote my own.

In Flave, I started with a utility I called defaultFetch. Nothing fancy — just a thin wrapper around fetch to cut down the noise. But of course, that didn’t last. It grew. I added automatic parsing, timeout logic, scoped methods, retries... the freaking bathtub. The moment we finished with Flave — that is, the presentation — I turned defaultFetch into a full-blown library and changed the name to Wefy (’cause it felt like I was weaving requests into structured, predictable flows and stuff... I have a bad naming sense ik 💀).

Anyway, since Flave taught me how annoying testing can be — we kinda tested after building everything — which is kinda the worst time to do it… because there was like NO TIME. So when I started working on Wefy, I decided to try doing it the "right" way: test-driven development :]]

And OMG, it sucked.

It was slow. It got in the way... it wasn’t my first time testing like this, but it was the first time I had to be in charge of the tests too. But looking back, I realize it forced me to understand how my wrapper behaved in different scenarios — and to actually think about edge cases ahead of time.

I used Vitest, and eventually I even ended up using Proxy() to trap access patterns and shape flexible client behavior (because I got really into scopes and inheritance). I could predict how the client would respond to different kinds of inputs.

I got deep into tooling — bundling, tree-shaking, plugin architecture, release strategy. I was learning Java at the same time and getting into OOP, so Wefy became this playground for abstract patterns. I started mimicking Fastify’s plugin system: scoped clients, decorators, isolated logic, extension hooks. It was over-engineered as hell. It felt like an SDK for an imaginary enterprise. And I was lowkey into it.

Eventually, the abstractions collapsed in on themselves. The structure went kabloosh and I achieved spaghetti code. But like by that point, I had already learned everything I needed.

Looking back, yeah... if I had known about ky() or TanStack Query, maybe I would've saved myself a lot of trouble. But not knowing forced me to build everything from scratch — and that’s what made it kinda worth it.

Wefy never made it to production. But it taught me how to predict, control, and structure API behavior. It taught me how far I could push an idea before it snapped. And yeah, sometimes it is okay to build something just to throw it away. Most of my code is actually just in the hellscape of GitHub repos or Replit anyways so... 💀

Would I use Wefy in a real app? Absolutely not. Would I build it again? Definitely — just leaner, cleaner, and hopefully with a better naming sense 💀