In our company we recently had a discussion about which part of an application is responsible for the (re)arrangement of the items of a list.
The list is a visual representation of steps to be done in production. Backend provides it in the "normal" order (1., 2., 3., 4.). In the frontend at the very top should be the 4th element, below is the 3rd, below the 2nd…
Since it's a website, frontend has to render from top to bottom, it's the wrong order for the website. He needs the elements to be 4., 3., 2., 1., in order to render it the right way.
These are 10 items at max which are all shown each time. So no paging or filters needed.
Basically the frontend needs the items in the reverse order of which the backend is returning it.
My colleague, a frontend dev, says it's the job of the backend. In my opinion (as a backend dev), it's part of the frontend.
His points:
- the frontend is "untouchable". If there will be changes in the presentation, we don't have to change anything in the frontend,
- the frontend says what it needs and the backend has to adapt,
- the frontend is dumb – there should be no logic in it.
My points:
- it's a matter of representation. the backend should not have to worry about it at all. It doesn't care (and know) in which order he needs the items.
- wrong responsibility. I don't want to work on my cars engine if I want to change tires, so if there are changes in the UI (i.E other arrangement), the changes should happen in the UI.
- I dont want to be specific on one UI. If we choose to add an other frontend (what we are probably not going to do) and it's not gonna show the list in the same way, do we have to provide another method for that?
I guess you get the point of our views. It's not a matter of implementation since it's probably one line of code. It is an architectural question since we're planning on a new part of the system. Maybe we just need another layer in between. But on which side, frontend or backend?
Last Edit:
Thank you all for your answers, those were waaaay more and detailed than I expected. For those who are interested, here is the way we did it.
Although the majority recommended to put in in the backend, we will put the logic in the frontend.
Why? Mainly because i described it too loosely and answeres were based on fact and requirements which i have described too late. By definition this List of max. 10 elements is ordered in the right order. And since the frontend needs it in an other order which is only due to the reason that it is easier to render it on web this way, its purely a presentation thing.
Don't get me wrong, all answeres were very useful and we took a lot of information from it. I guess overengineering was the keyword we needed to realize that we never gonna need any filters, paging or anything else on this API. But hell, we learned way more than we expected!
Best Answer
Any decent back-end API should receive parameters that allow some customization or filtering of the results it gives back to the client. For something that returns a list, it's usually common to provide:
It's not always a rule, but often you find all of these three items combined.
Having a back-end API return just a list of results and then "it's front-end's problem what it does with it" is most of the times a bad idea. It causes the UI to become more complicated, to do something that the back-end can do very easily and without impact on performance.
Let's switch the discussion for one second and think about the use case of having the list paginated inside the UI. Are you going to force the front-end to retrieve the entire list, keep it in memory and do the pagination on the client side? What if someone decides to request the full list each time the user clicks on the next page?
What I'm saying is that it's a trade-off. Some things need to be done on the back-end, some on the front-end. It's not "all on back-end" or "all on front-end". Discuss it between you and agree on what the API should return and what parameters it should receive. Basically to create an API that's flexible, not one that's rigid.
And if you don't mind me being completely honest, this isn't an architectural question. Architecture is what's important. Ordering of items on the screen is not important, thus not architecture.