Dear frontend developers...how do you deal with mock APIs?

The simplest way to go is to use dummy data saved in a JSON file. There are tools which help you mock data , check out https://miragejs.com/ and https://github.com/typicode/json-server. I think MirageJS offers a nice developer experience. If you are planning to do something very custom, you could run your own server locally, but then you will have to check this into version control and this adds more overhead to you team mates as well.

I'm a backend developer and although your question was aimed at frontend devs, maybe my perspective will be useful.

I work with a number of internal AP's and often the frontend team in miles further on that where the API is and therefore need the mocked interaction you're looking for.

In our case, we're using Swagger Hub (https://swagger.io/tools/swaggerhub/) to build the API and in our specification we're including samples responses the endpoints can provide.

Swagger Hub provides a URL (like https://virtserver.swaggerhub.com/MyCompany/MyApi/1.0.0) which you can use within your frontend application to continue building your application based on the mocked responses and later you can switch over the URL to an actual API server when it becomes available.

This means we can take a day or 2 out with the frontend team and define the request and response data structures and give them something they can use fairly quickly even though that part of the API might be weeks away from being ready.

The editor in Swagger Hub can be a bit clunky (it's not particularly easy to break the API down into smaller sections) and we're looking at Stoplight (https://stoplight.io) as an alternative product to write the specification in more manageable blocks and then import the full specification from Stoplight into Swagger Hub.

When I used to be in that situation 6 years ago, I just threw dummy data in a JSON file (or, in a few cases, into an XML file) and just fed that to my front-end as I built.

Open source has grown an order of magnitude since then and now there are great utilities like JSON server that will basically do it for you! https://github.com/typicode/json-server

A lot of folks have mentioned using mock json files. While this works, it can be a bit of a pain to actually get that data to where you need it in your code (e.g. mocking your network layer).

For testing, I use nock and I've thrown together some really janky code mashing jest and nock's nock-back mode together. It automatically records any API call made during tests and records the response. This lets me use prod (or, more often, and local instance of the app) to generate mock data for whatever constitutes third-parties to keep test instability down.

For actually interacting with the mock data to iterate through development, I use storybook. By treating everything from just a button all the way up to a full page as a component with stories, I can get super-specific about testing the foundational components, but I can also look at pretty much the entire application without ever hitting a server.

From there, typescript let's me mostly feel confident that when I pass API responses into those components, they'll render correctly. The key there, of course, is to either have a statically typed API or to mark all API responses as unknown so the typescript compiler forces you to write the runtime checks that would warn when unexpected data is received.

mock server on the cloud

First of all, if you are writing proper website or big applications, ALL requests should be wrapped in dedicated services (basically classes with various methods like Users.getUser(x) etc).

Why? What happens when the api gets updated? Or when backend guys decide to split their api into separate microservices? Or what if everyone drinks the cool-aid and wants to switch to graphql immediately?

You don't want this changes to be visible in your codebase. So every such change should happen INSIDE dedicated services (if it's possible obviously).

Now this immediately solves mock problem. You can have an instance of User service that serves static, json data (something like MockUsers implements Users).

That's how we did it in REAL companies. Needles to say in my own projects I just want to build as fast as possible, so I ignore these rules, like many others.

I built my own desktop tool for this: https://mockoon.com
It can mock multiple REST API locally, act as a proxy (when you only want to mock some missing routes) and many other things.

It became something bigger, and people like it apparently :)

I'm not a developer and I can't say about the mocking part, but our devs share their early stage work with we (product team) through ngrok (we use the free tier). I hope this can be useful somehow.

Cheers

Reiterating other's sentiments, I typically create a dummy JSON file. If I want to make sure my queries are proper, I've used graphcms to mock APIs before they're fully built. That being said, I'm strictly a GraphQL user 🤷‍♀️