If you ever been a part of an API design process, you’ve probably been a witness to the conflict between the frontend and backend developers. In most cases, these conflicts are rather harmless, however, they can become a serious distraction for the team and create bigger issues down the line.
As a team leader, you need to everything you possibly can to avoid these situations and keep things running smoothly. Some people opt for dividing the processes, however, as we’re about to show you, that’s a pretty counterproductive strategy…
Remind Everyone that They Are Doing the Same Work
Every part of the development process is crucial to the success of your project. From early design plans and restful API documentation to frontend and backend dev work. Every single piece needs to be in place if you want your API to see the light of day on schedule.
You should simply ask your team members – what does a backend developer do that differs so much from what a frontend developer does and vice versa? Some people think that backend devs do more “serious” work while the front-enders only try to make things look more appealing.
But that just isn’t the case. The matter of the fact is, frontend devs do a lot of serious coding and they have to deal with almost exactly the same problems as their backend colleagues. And they don’t just share the same problems – they also solve them in the same way.
Resolving the Argument through Layered Design
While the explanation we talked about above may help you change the mind of a couple of your colleagues, it certainly won’t make everything go right magically. Two problems that often arise during the design process are:
- Frontend developer trying to reduce their burden of coding that payloads fit the UI design while limiting API calls where they deem appropriate
- Backend developers desperately trying to optimize the endpoints of your API for both quick development and reuse
If you want to avoid these problems, you need to find a way to keep both parties satisfied. The best way to do this is to use what’s known as layered design. This design process is more commonly known as the Back-for-Frontend pattern or for short – BFF.
This pattern is perfect for resolving these kinds of conflicts, because it allows the API backend to remain completely the same with a new one constructed to meet the UI needs. When it comes to applying the BFF design in practice, there are two specific approaches
- The App-centered one: The first approach if driven by end-user use cases, which are realized by combining small compostable endpoints into a brand new API
- The Device-centered: This approach is mainly driven by the functionality of the device and it encourages the repeating of the code across device APIs
Now, both of these approaches push the orchestration close the server tier. There, the backend APIs reside and the latency of the network are noticeably lower. In turn, this reduces the traffic of the client network to one or two API calls. And that works perfectly for mobile apps.
Be Careful About Applying the BFF Pattern
As you can see, the BFF pattern may be just the tool you need to resolve a conflict within your team and help you make sure your API will be able to solve problems. The problem with this pattern is that it requires you to create another API that will need to be maintained over the App’s life.
This won’t be a problem for bigger teams. However, micro-teams might have some trouble keeping up with all the changes to the API backend and frontend. But with a little bit of planning and organization, even a small will be able to handle all of this.
Never take any shortcuts in the API design process – and always treat your API as a product itself.
