DEV Community: Artemy

I got tired of waiting for the backend, so I built a free fake REST API

Artemy — Wed, 16 Sep 2026 10:52:41 +0000

Three years on the frontend, and nearly every project started the same way. Designs are ready, the data model has been discussed, the backend doesn't exist. It'll be ready "in a couple of weeks". Sometimes that was even true.

What do you do for those couple of weeks? You create src/mocks/, drop some JSON in there, add a setTimeout of 300 ms so you can at least look at your loaders. Then the backend arrives and it's user_name instead of userName, the list comes wrapped in { items, meta } instead of a plain array, pagination works differently altogether. And you sit down to rewrite the API layer you thought you had isolated so neatly.

I went through this enough times that I ended up building a service for myself. It's called mockly, it's free. Here's how it works and why.

Why not use something that exists

I did. For a few years I sat on one mock-hosting service. Convenient, simple, exactly what I needed. But it went down. Regularly, and at the worst moment: I sit down to build a page, hit the endpoint, 502. Message the author, silence. Updates twice a year, and a handful of small things just didn't fit how I work.

Every time it was down I thought: how hard can it be, store some JSON and serve it over REST. Turned out a bit harder than I thought. But I finished it.

What it is

mockly hosts fake REST APIs. Sign up (GitHub login works), create a project, add a collection called products, paste an array of JSON. Done, you have an endpoint:

https://api.m0ckly.site/m/<publicId>/products

It behaves like a real API. Returns a list and a single record, accepts POST, PATCH, PUT, DELETE. The server assigns id. No keys, no headers, CORS is open, call it straight from the browser. There's a public demo project, so this snippet works as is:

const res = await fetch('https://api.m0ckly.site/m/demo/products?limit=2')
const { items, meta } = await res.json()
// items: [{ id: 1, title: 'Compact Mechanical Keyboard', price: 89, ... }, { id: 2, ... }]
// meta:  { total_items: 40, total_pages: 20, current_page: 1, per_page: 2 }

The whole point: one line in .env

This is the idea I built the thing around.

Data model agreed with the backend team? I put JSON into mockly in the exact shape production will return. Then I write the frontend the normal way: services/api.ts, react-query hooks, forms, types. All of it real, with real HTTP requests, loaders, errors, empty states.

// src/services/api.ts
const BASE = import.meta.env.VITE_API_URL

export const getProducts = (params: ProductsParams) =>
  fetch(`${BASE}/products?${new URLSearchParams(params)}`).then(r => r.json())

// src/queries/products.ts
export const useProducts = (params: ProductsParams) =>
  useQuery({ queryKey: ['products', params], queryFn: () => getProducts(params) })

Backend is ready. I change one line:

- VITE_API_URL=https://api.m0ckly.site/m/9f2c1e0a
+ VITE_API_URL=https://api.your-company.com

The api, queries and mutations layers stay untouched. This is how I've worked for the last few months and it has saved me a lot of nerves.

What it can do

I didn't want "JSON behind a URL". I wanted the behaviour I'm used to from decent backends. Every example below runs against the demo project.

Filters: ?title=mouse is a case-insensitive substring match, ?title=*mouse* is a wildcard (anchored at both ends, so Vertical* matches titles starting with "Vertical"), ?price_gte=20&price_lte=90 is a numeric range. There's also ?q=mouse, which searches across every field of a record at once.

Sorting and pagination: ?sortBy=price&order=desc, numbers compared as numbers, not strings. Pass page or limit and the response gets wrapped:

{
  "items": [ ... ],
  "meta": { "total_items": 40, "total_pages": 4, "current_page": 2, "per_page": 10 }
}

If you always want the envelope, turn it on in the collection settings, along with a default page size.

Relations. A record has a userId? Then ?_relations=user embeds the object from the users collection right into the response:

curl "https://api.m0ckly.site/m/demo/posts/1?_relations=user"

{
  "id": 1,
  "title": "Why we moved search back to Postgres",
  "userId": 1,
  "user": { "id": 1, "name": "Ada Whitfield", "username": "adaw", "city": "Lisbon" }
}

Works in reverse too: GET /users/1?_relations=posts returns the user with all their posts. Several relations, comma-separated: ?_relations=posts,todos.

Forced responses. Want to see how the frontend survives a 500 or a 429? Set a fixed response on the collection with any status from 100 to 599 and any body. Remove the status and the collection is back to normal. For debugging error boundaries and react-query retries this is hard to live without.

Methods are toggled per collection: read, create, update, delete. A disabled one answers 405. Disable the whole project and the endpoints answer 403, data stays put.

Private resources. Everything is open by link by default. If you need to mock a login flow, a collection can be locked: without a valid token you get 401. It's mock-grade protection, not real security, but enough to debug auth on the frontend.

Ready-made data. Don't feel like inventing JSON, there are datasets in the spirit of jsonplaceholder so you can start in a minute.

Quick start

Try it right now, no sign-up. The demo project has users, posts, comments, todos and products, writes are allowed, data resets every hour:

curl "https://api.m0ckly.site/m/demo/users/1?_relations=posts"

For your own data: go to m0ckly.site, sign in with GitHub. A default project is created for you. Create a collection, paste JSON, array or object, any shape. Copy the publicId from the project page and hit it:

curl "https://api.m0ckly.site/m/<publicId>/products?sortBy=price&order=asc&limit=3"

Honest about the limits

This is a tool for prototypes and development, not production. Up to 25 collections per project, 500 records per collection, 500 objects per import. Treat data in open collections as public: no real personal data, no production dumps. If a link leaks, disable the project and the endpoints immediately answer 403.

Under the hood: Fastify, TypeScript and PostgreSQL with JSONB on my own VPS, Next.js on the frontend. If there's interest I'll write about the architecture separately.

This is d2d

There's b2b, there's b2c. mockly is d2d, dev to dev. I'm a frontend developer, so I built it for my own workflow first, but it's for anyone who needs a working API before the real one exists. I use it myself every day. There's no sales team, no pricing tiers, no quarterly roadmap. There's me, my VPS and your bug reports.

That's why it's free and will stay free. And that's why what I need most right now is feedback: what's missing, what's annoying, which scenario isn't covered. Drop a comment or ping me on Telegram. It's me answering, not a bot.

Site: m0ckly.site
Docs: m0ckly.site/docs
Service channel: t.me/mocklyapi

I shipped my first npm package with AI — and it's already in production

Artemy — Wed, 01 Jul 2026 10:13:27 +0000

I'm a frontend developer with about three years of experience. Until a few months ago, "publish an npm package" lived on my someday list — the kind of thing you assume requires a deeper relationship with build tooling than you actually have. Then I built one. It's called daterly, it's a React date picker, and it's already running in internal projects at the company I work for.

The twist: I wrote most of it with AI — specifically Claude Code and the wider Claude toolset. This is the honest version of how that went. Not "AI built my startup overnight," but a real account of where the AI carried me, where it slowed me down, and what I'd actually keep from the experience.

Why build another date picker

The internet does not need another React date picker. I know. But we needed this one.

At work (sima-land) we lean on react-hook-form everywhere. It's the backbone of how we handle forms across projects. The date picker we were using — react-datepicker — kept getting in the way of that. Two things drove us up the wall:

Styling was a fight. Overriding its look to match our design system always felt like wrestling specificity rather than setting a few variables.
The react-hook-form integration was awkward. Wiring it into RHF cleanly took more glue code than it should have, every single time.

When the same papercut shows up in project after project, it stops being a papercut. We use one tech stack on purpose — a shared, repeatable way of building things so any of us can move between projects without relearning the basics. A date picker that fought both our styling approach and our form library was a crack in that consistency.

So the real motivation wasn't "wouldn't it be cool to publish a package." It was: we want one tool that speaks our stack fluently. First-class RHF support, styling that bends without a struggle, and the locale/format behavior we actually need (Russian market: ru locale, dd.MM.yyyy by default). That's the takeaway I keep coming back to — the package exists to protect a way of working, not to chase npm downloads.

What it ended up being

daterly is built on react-day-picker v9 (headless) and date-fns v4. The headline features:

Single date and range picking, controlled or uncontrolled
A masked text input so people can type a date instead of only clicking a calendar
Arbitrary locales and formats via props — the input mask regenerates itself from the dateFormat you pass
Optional time selection
Zero-overhead react-hook-form integration via a separate daterly/rhf entry point — if you don't use RHF, you don't pay for it
Styling through --daterly-* CSS variables and data-* state attributes, so you can theme it without touching JavaScript

The RHF wrappers are generic over your form's value type, so name gets autocomplete and type-safety:

import { RHFDatePicker } from 'daterly/rhf';

<RHFDatePicker<BookingFormValues>
  name="checkIn"
  label="Check-in date"
  rules={{ validate: (v) => v !== undefined || 'Pick a date' }}
/>

That snippet is the whole reason the project exists, honestly.

Building it with AI: the good parts

I worked almost entirely inside Claude Code, with Claude Design for the visual side. The parts where the AI genuinely shone were the fiddly, self-contained algorithms — the stuff that's annoying to write by hand but easy to specify.

The input mask is the best example. We implemented our own digit-only mask instead of pulling in a masking library, and there's real subtlety in it:

Rebuild the masked string from raw digits on every keystroke.
Restore the cursor position with requestAnimationFrame after React re-renders the input — otherwise the caret jumps to the end and typing feels broken.
Skip over separators when you press Backspace on one.
Strip non-digits on paste before masking.
Validate via a round-trip check: format(parse(masked)) === masked. That elegantly catches things like 32.01.2024 — it parses, but it doesn't format back to the same string, so you know it's invalid.

That round-trip trick is the kind of thing the AI proposed that made me go "oh, that's nice." Describing the edge cases in plain language and getting a working first pass back was a real accelerator. Same with boilerplate-heavy work: dual ESM/CJS build config, TypeScript declaration setup, test scaffolding. Tedious to set up from scratch, quick to generate and then review.

Building it with AI: the not-so-good parts

It wasn't magic, and pretending otherwise would be dishonest.

The limits and the lag. I was on the Pro plan, and I hit usage limits more than once mid-flow — exactly when you've built momentum and don't want to stop. On top of that, it noticeably slowed down on a larger context, which broke the rhythm. If you're going to lean on AI for a real project, budget for the friction of waiting and rationing, not just the writing.

It needs a driver, not a passenger. The AI is great at producing a plausible chunk of code. Whether that chunk is correct, fits the existing patterns, and doesn't quietly reinvent something three files over — that's still on me. The most valuable skill wasn't prompting; it was reading every diff like a code reviewer who doesn't trust the author. A junior who can't evaluate the output would have shipped subtly broken behavior here.

From "it works on my machine" to an actual package

This is the part I underestimated, and the part I'm most glad I didn't skip. Going from a working component to something installable and maintainable is a whole second project:

Dual ESM + CJS output with proper type declarations, built via tsup.
Versioning with Changesets, so every change is intentional and the changelog writes itself.
CI, code coverage, and a bundle-size budget (size-limit) so the thing doesn't quietly balloon.
Component tests with Playwright and Vitest — a masked input has enough edge cases that you really want them locked down.

None of this is glamorous, but it's the difference between a gist and a package other people can depend on.

The 0.4.0 incident

A small, very human lesson. Early on, I ran the Changesets CLI interactively and — distracted — picked minor instead of patch. The version jumped to 0.4.0 instead of 0.3.1. No undo on a published version; you just live with the gap.

The fix was a process change I now recommend to anyone: don't bump versions interactively. I have it written into the project's instructions for the AI too — create the changeset file by hand, decide the bump deliberately (patch for fixes, minor for new backwards-compatible props, major for breaking changes), and only then publish. A thirty-second mistake taught me more about release discipline than any tutorial.

What I'd actually take away

If you're a frontend dev sitting where I was, three things:

Build for your stack, not for the stars. The best reason to make a library is that it removes friction you hit every day. daterly's whole job is to make our standard stack — react-hook-form, our styling approach, our locale defaults — feel native. The npm badge is a side effect.
AI compresses the boring parts, not the judgment. It wrote a lot of correct code fast. It also needed me to catch what it got wrong, ration limited usage, and wait out the slow moments. Treat it as a fast junior pair, not an autopilot.
The packaging is the real work. The component took days. The build config, versioning, CI, tests, and docs took longer — and that's what makes it usable by anyone other than me.

daterly is MIT-licensed and on npm. Code and docs are on GitHub. If you're fighting your date picker's styling or RHF integration, give it a look — and if you build your own thing instead, even better. That's the point.

I'm also open to freelance work and collaboration. If you've got something you're building and want a hand, or you just want to see what else I've made, it's all at artemy.tech.