What Frontend Devs Want (From Backend Devs)

This one goes to all the backend developers who create APIs for the frontend developers and want their team to succeed, become more productive, and rock everybody’s socks. Here are a few simple things that can decrease your time-to-market or improve other fancy metrics your managers want you to improve.

I will tell it from the web developers’ point of view, but from what I remember, the same works for mobile development. I will use my experience working with a guy who made perfect APIs and with whom we literally understood each other without words. Okay, yes, it was me: I used to be a full-stack dev. But I firmly believe that people can understand each other just as a frontend-me and a backend-me did.

I’m not going to tell you about readability, consistency, stability, and stuff like that: you know what makes a great engineer without my advice. I want to discuss those things that will help your frontend colleagues work with your API more efficiently and ship the product with as little friction as possible.

Data Structure Before Everything

Most of the time, our first task is to map the data we will have to the design. And that’s where your future structure might come in handy: if you start your development with the data model, feel free to share it with the frontend devs before the actual API is ready. Because—surprise!—we start with the data model as well.

Translating these interfaces into Typescript (hello, Copilot) is a good kickstart. And the devs who use pure JS, God help them all, will also benefit from knowing the names of fields. I understand that some names can change later, but it is better to fix the naming after than guess it before. This way, we can discuss and change it before it is too late.

We can agree on naming and avoid having a method getUsers that calls the GET /accounts endpoint (different entity naming is painful in the long term). Moreover, we can mock the data on our side to test how different enum values and optional fields are displayed, check the edge cases and whatnot.

It will be even better if you get access to Figma and create a model by looking at the result. And it’s not a typo: I suggest that backend developers have access to Figma to make the data structure that solves the actual needs of the frontend part.

One Call to Rule Them All

Another good reason for looking at the design at this stage is the possibility of thinking about optimizing the number of calls. In a perfect world, I’d like to have one call that shows all the visible data on the page. Of course, there might be pagination, infinite scroll, common cached data, and micro-optimizations on loading crucial parts before the rest of the page. But the primary data getter should reflect the final result.

I’m not saying it’s impossible to combine the data from different sources, and I understand the situations might differ, but, in general, we want to reduce the number of calls to let the users get their data faster and make the page more robust. Once again, don’t treat it as black and white: obviously, it’s okay to have several requests if we can show the significant part quickly and then load the additional data.

The rule of thumb: each API call can fail independently without breaking the UI completely; it should only make one meaningful part hidden behind the error message.

The same applies to data manipulation requests. I can send patching requests for each object, but if the design suggests bulk editing, it’s nice to have one call for that.

Give Us Some Data

Testing the empty state is always a good idea, but frankly, when we integrate the API, we would love to see some examples of data. The more, the merrier. And by saying “more”, I also mean “more different.” If you have direct access to the dev DB or can readily test your calls, please add a few rows with different values. At this stage, it’s better to make them look like real ones, so we can find out something that wasn’t an issue in the cozy design mockups with polished data that always fits the container.

The Devil Is in the Details

Do you know that feeling when you need to add a comment so your code is understandable in a week? Life happens, and sometimes, tricky things arise from the complicated requirements. If you feel that, please share the news beforehand.

Of course, you don’t need to say that pressing the “Delete item” button should call the deletion route, but if there’s a twisted logic you had to make an additional method for, or if there are two endpoints that look similar, but used differently, or if there’s a parameter whose value should be hardcoded for some time, please let us know.

I know this one is the hardest to master because when we work on something, we dive into the tiniest details—so it feels obvious. But it is not like that from the outside, so if you had to take an unconventional approach to this API, please don’t keep it secret.

Communication Is Key

Like in every relationship, the most important thing is the dialogue. I told you a few things that I find efficient, but maybe in your team, you’ll want the frontend devs to describe the endpoints beforehand. Or you have a technical product manager who can do it themselves. Or maybe your development cycle allows you to do it in a very different way. And that’s where the good old talk comes in useful.

You can start with this list and then align the processes to make them comfortable for everyone. Don’t wait for the managers to do that, because you know better. But whatever works best for your team, I insist that the backend devs should treat frontend devs as users.

Basically, it’s like being a product manager for the API: you can do a mediocre thing that works or create something your target audience truly enjoys using. Choose wisely.

Feature image: I asked AI to make a cover for the "What Women Want" movie featuring a backend and a frontend dev