If you're a front-end developer, chances are you've used JSON-Server at some point. It's one of those tools that just works. You spin it up, create a quick API, and move on. I’ve used it for years in my own projects. But there’s one thing that always bothered me: Why do I still need to run it locally every single time? Every time I start a new project, I have to: create a db.json file run the server keep it running in the background restart it when something breaks Everything works… as long as you're running it locally. And that's where it starts to feel limiting. I started wondering: What if I could get the same experience… but without running anything locally? So I decided to build it and that’s how fastdb.io was born. So what is fastdb.io? fastdb.io is a simple way to create and use mock APIs instantly — without running anything locally. You define your data, and your API is ready to use. No setup. No server. No configuration. A quick example Let’s say you want to create a users API. With JSON-Server, you would create a db.json file like this: "users": [ "id":1, "name":"John" , "id":2, "name":"Jane" ] Then you run: json-server--watch db.json And your API is available at: http://localhost:3000/users With fastdb.io, the idea is similar — but without the local setup. You define your data, and your API is instantly available through a public URL. Something like: https://ryfksmvr.fastdb.io/api/todo-app/users No server running. No setup. No extra steps. Just your API, ready to use. What else can you do? Beyond just creating APIs, fastdb.io gives you a few tools that make the whole development process smoother. Model your API visually You can model your resources and relationships using a canvas. Instead of manually structuring everything, you can map your API in a more intuitive way — especially useful for more complex flows. You can also generate realistic fake data using faker.js, or define static values like strings, numbers, and booleans. This gives you flexibility to quickly simulate real-world scenarios or keep things simple when needed. Test endpoints instantly There’s a built-in API tester, so you can quickly test your endpoints without leaving the app. Of course, you can still use tools like Postman or Insomnia if you prefer. Copy TypeScript types Each endpoint can generate TypeScript types that you can copy and paste directly into your project. It’s a small thing, but it speeds up integration a lot. Manage your data with a table editor You can update your data using a simple table interface. No need to manually edit JSON files — just change the data and your API reflects it instantly. Control authentication You can define which requests require authentication. For example, you might allow public GET requests, but require authentication for POST, PUT, or DELETE. You can also simulate real authentication flows, like a login endpoint. For example: POST https://ryfksmvr.fastdb.io/api/todo-app/auth/login Request body: "username": "Earnestine66", "password": "Fastdb@123" Response: "user": "id": "82a9ca99-47d7-4325-9ee8-f5aa2f879384", "name": "Damian", "email": "[email protected]", "avatar": "https://avatars.githubusercontent.com/u/22576171", "authentication": "password": "Fastdb@123", "username": "Earnestine66" , "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." This allows you to test authentication flows in your frontend without needing a real backend. Simulate real-world scenarios You can apply custom throttling to simulate slow APIs. This is great for testing loading states, splash screens, and real user experience. You can even mark an API as offline and return a 503 status. All of this is designed to remove friction and let you focus on what actually matters: building your frontend. Looking forward fastdb.io is still evolving, and there’s a lot I want to improve. I’m building this mainly based on my own workflow as a front-end developer — but I know there’s a lot more that can be done. If you’ve ever used JSON-Server (or similar tools), I’d really love to hear your thoughts. What features would you expect? What problems do you usually face when mocking APIs? What would make your workflow easier? Feel free to drop a comment or share your experience. I’m building this in public — and your feedback really matters. -- fastdb.io