Me? Oh, I’m just waiting for the server

Photo by NordWood Themes on Unsplash


As Front-end developers, “waiting for the server (or API)” can sometimes become a daily mantra.

Whether we’re happy to get some rest from integration work or pissed off over our heads because the feature was supposed to be done yesterday but server isn’t ready yet (or broken or was just updated and changed or any one of a million other reasons), it’s never a good moment when the server stops responding.

Recently we’ve experienced this on one of our own projects and so decided to see how this situation get handled better in the future.

During the integration phase (let’s say after 50%-75% of our Front-end work is completed) there’s not much we can do except complain and maybe try the API again (and again and again).

However – as experienced FE devs we know it’s gonna happen. There’s no question about it, IT IS GONNA HAPPEN. It’s just a matter of when and how much of our work on that day / week will get blocked.

So knowing it’s headed that way, what can we do?


We’ve identified the way to tackle this as being split into 2 parallel processes:

  • Fine-grained Integration planning
  • Fallback mocks

Fine-grained Integration planning would come into being as identifying the app joint client-server flows and performing integration flow by flow.

It could be for example Login flow, Registration, load a dashboard page, edit user settings etc. – any complete user story which could be considered as a feature and that is mostly autonomous.

That way, we can complete full parts of the application full-cycle (client + server) and prevent going into a full-fledged integration phase which could easily result in frustration and missing our deadline.

While that can help making things smoother, Fallback mocks is the real deal. This means we create our own json-based simple mocks which can replace the server side on any call to the server.

This is done in many ways from light manual mocks, to semi-automated tools such as mimicjs and more.

The main idea is to spend some effort in the beginning and throughout the project to make sure that at any point, we can go “server-less” and avoid waiting for the server in order to fix the shade of that submit button deep in a modal window that only exists under certain data conditions which are either non-existent yet or hard-to-simulate with real data.


Ultimately, we discovered that by good FE + BE team collaboration and agreement on applying both principals above, we’re able to minimize costs & frustration of final integration and adhere to meeting our deadlines.

What do you think? Do you know any better ways to accomplish this? Let us know in the comments below.

Drop your info here


Like what you see?

Sign up to our newsletter to get more tips,
best practices and helpful solutions
straight out from our own experience in the Front-end world.

We won’t spam you and won’t sell your email to nobody. Scouts promise!