Hey DEV 👋
This is a short follow‑up to my earlier post introducing myapi.rest.
This post is a short follow-up to
I built a unified API toolkit so devs can stop rewriting the same utilities
A few people asked how I decide what belongs in a unified API toolkit — and just as importantly, what doesn’t.
My rule is simple
If I wouldn’t use it myself in a real production system, it doesn’t get built.
Every API in myapi.rest exists because I’ve needed it — or I’m actively needing it — while building SaaS products, internal tools, or client systems.
That single constraint keeps things:
- Practical instead of theoretical
- Focused instead of bloated
- Useful instead of impressive‑looking
On bundling utilities
The goal isn’t to build a giant “do everything” platform.
It’s to provide a small, reliable utility layer made up of independent building blocks that happen to live behind one consistent API.
If a project only needs one piece, it should still feel worth using.
Still building this in the open
I’m deliberately sharing progress early so feedback can shape things while the surface area is still small.
If you’ve got thoughts on:
- APIs you keep rewriting
- Utilities you wish existed as a service
- What makes an API genuinely pleasant to use
I’m all ears.
Top comments (0)