1
Example: We’re designing a tab component with four different statuses: applied, current, upcoming, and archived. The current design requirement is to group “current” and “upcoming” into a single tab while displaying the rest separately.
This leads to a debate:
Frontend Team’s Position: They want the backend to handle the grouping logic and send the data already grouped, like this:
``` [ { "title": "Applied & Current", "count": 7 }, { "title": "Past", "count": 3 }, { "title": "Archived", "count": 2 } ] ```
The goal is to reduce frontend redeployments, especially for minor UI changes. This is because 2/3rds of our frontend will be mobile apps (both Android and iOS), and we've had trouble getting app updates approved by the app stores in a timely manner.
Additionally, we're white-labeling the apps with small modifications (color themes, logos, etc.), and we plan to scale to 150-200 tenants over the next 2 years. With so many tenants, reducing redeployments would save us from having to push updates to multiple app origins.
Backend Team's Position: They believe grouping logic and UI decisions should be handled on the frontend, with the backend providing raw data, such as:
``` [ { "status": "applied", "count": 4 }, { "status": "current", "count": 3 }, { "status": "past", "count": 3 }, { "status": "archived", "count": 2 } ]
```
Their argument is that adding UI-specific logic to the backend increases complexity and violates separation of concerns. Backend should remain data-centric, delivering raw data, and avoid being tied to UI presentation decisions.
They also pointed out that server-driven UI could create unnecessary technical debt, especially as frontend needs evolve over time. For example, changing UI elements like tabs to something else (e.g., a scrolling view) would require backend changes, adding overhead.
Another concern is the risk of backend decisions limiting frontend flexibility, especially if other UI teams or platforms need to consume the same data differently. Changes for one frontend could affect others unnecessarily, making the system harder to maintain.
Additional Context: - Server-Driven UI: Server-driven UI has been gaining popularity as a way to solve some of these challenges. Companies like Airbnb, PhonePe, and Swiggy have implemented server-driven UIs to make large sections of their apps dynamically configurable. However, the current approach we’re discussing isn't a fully generic server-driven UI—it’s more like implementing dynamic UI behavior for some parts while leaving the rest static. - Startup Constraints: As a startup, speed and resource efficiency are critical for us. We're trying to balance agility and scalability while minimizing technical debt.
The Dilemma: Should the backend take on the responsibility of managing grouping logic and sending the frontend grouped data, or should the frontend handle all UI logic and just receive raw data from the backend?
Given the additional complexity we have with mobile apps, app store approvals, white-labeling, and scaling, I’d really appreciate your thoughts as frontend architects. How would you approach this to balance flexibility, scalability, and maintainability? Are there alternative solutions (like a Backend-for-Frontend (BFF) layer) that might work better in this situation?
Thanks in advance for any insights you can provide!