How do you deal with front end devs being blocked waiting for back end?

Question

When working on new products, it is often the case that most of the frontend work that needs to be done has a direct dependency on the backend functionality that it will be integrating with. But BE work takes time, obviously. During that time, I've found that FE engineers are often looking for work as they wait for the BE functionality to be delivered. Do you have suggestions for how to deal with this? Do you stagger work so that BE is ahead of FE so that FE always has stuff to work on? Do you decide on an API in place first even if it doesn't function so that FE can simply plug in with that API even if they need to use dummy/mock data for the time being?Appreciate any thoughts.

java-man · Accepted Answer

Here is what works, from my experience:Any development which involves multiple teams (or multiple developers for tjhat matter) must start with definition of the API. Write a Word document, assign a version, distribute to all involved.Then, create mock calls and mock data according to the specification (this answers your question). FE devs can work in parallel while the back end implement.Any modifications to the interface result in a new revision of the API spec. Repeat.Swagger is not an API spec, as it does not allow to see what changed from 2.1 to 3.3, for example. Use Word, discuss the changes before committing to modification of the API.

smt88 · Answer

Design the API first. If you're talking about web, you can use OpenAPI spec.From there, you can mock your APIs very easily and frontend is unblocked.

lhorie · Answer

I've worked in settings where frontend development happens concurrently w/ backend, as well as settings where frontend development starts before backend development.
You don't need to have API finality to start work on frontend. There's plenty of things to do in terms of UI that can be done without a APIs being ready. You just implement the skeleton first and fill in the data on a second pass, as it becomes available.
Another alternative that other have brought up is agreeing on an API. This, in my experience, is a "best practice", but in actual practice, schemas change, backend devs don't always honor what they promise, and some bad apples just don't care about/aren't capable of coding to a specification. Pragmatically, it's easier to just consider the entire schema as a blackbox and implement the bulk of the UI with the assumption that the data will attempt to destroy your layout (e.g. by being too big, or having large unbreakable strings like URLs, or stretching things vertically in some way that makes nested scrolling suboptimal).
When you look from that angle, there's plenty of work to do in anticipation for when the data flood gates open, and there's arguably more dependency on effective communication with designers/UX to ensure that the UI can adapt to data with dynamic/unpredictable nature.