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!

  • What do the items in the list represent? Why does the user want to see them in that [reverse] order? Commented Oct 16, 2019 at 16:07
  • 25
    I'd say there's need to adapt both, frontend and backend. The API to receive the items should provide another parameter to determine the order of the items. Commented Oct 16, 2019 at 16:16
  • 1
    I think he's correct. Back-end APIs should support returning ordered elements based on the request from the front-end.
    – minseong
    Commented Oct 17, 2019 at 16:16
  • 1
    IMO the arguments your backend folk are making are incredibly short sighted. Implement one filterable order-able paginatated table in your free time and you'll find why it's a backend responsibility.
    – user142543
    Commented Oct 18, 2019 at 13:35
  • 3
    "the frontend is dumb - there should be no logic in it." Oh boy, just recently I have witnessed an application like that. Clicking on a combobox (or doing anything at all) makes a 1.8MB request to the server sending the whole UI state, the backend changes it and sends back an other 1.8MB to render. So not only frontend has 0 logic, but the backend is practically stateless! It just keeps passing the whole state back and forth.
    – Bakuriu
    Commented Oct 18, 2019 at 19:26

4 Answers 4


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:

  • parameters for ordering (ASC or DESC) based on some field criteria;
  • parameters for pagination;
  • parameters for the search query (i.e. filtering the list to request only a subset of records).

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.

  • 13
    I agree with this answer. Unless there's some technical reason against it, sorting is usually best done at the source of data retrieval, but how the data needs to be sorted is up to the presentation layer. So, provide a way for the UI to indicate its sorting needs, and have the backend do the sorting.
    – Eric King
    Commented Oct 16, 2019 at 17:04
  • 2
    I agree as well, assuming the back end isn't simply making and passing along a nosql query -- adding deserialization and sorting by certain property values could add a fair amount of cost if the back end is a very thin layer around a nosql DB, and the front end is already consuming/deserializing that data. It depends on which side of the equation is dumb/smart IMO.
    – Will P.
    Commented Oct 16, 2019 at 17:09
  • 2
    @Chris the number will not increase since there are physical boundaries. They represent steps in the production, each of them has its own physical place. Even if it would increase to 15, we would still have to display all of them on the screen (and enlarge the production hall ;) ). But i absolutely get your point, thanks!
    – Sn0bli
    Commented Oct 17, 2019 at 6:46
  • 4
    I disagree. A pagination-supporting API is different and more complex than one which doesn't support pagination. The two use cases shouldn't be conflated, and may have different design points. A reason why the frontend should do the ordering, in the non-pagination case, is that specifying ASC/DESC to the backend isn't sufficient: it doesn't take into account ordering due to locale. So are you going to pass the locale too? And, are time fields passed with respect to the local time zone? If so, TZ has to be passed too. And etc. etc. This argues for the front end taking care of it.
    – davidbak
    Commented Oct 17, 2019 at 17:01
  • 6
    And to the comment about that in 2 years or so this list of 10 items might grow to something requiring pagination: Perhaps. The OP needs to evaluate his use case: what this list is, and whether or not it will grow to such sizes. Designing now an API for pagination for this particular list might be wasteful overengineering.
    – davidbak
    Commented Oct 17, 2019 at 17:04

Your edit adds some context, which IMO is important — this isn’t an abstract data source that can be displayed in any order or will be ordered by various attributes. This is a physical process with a definite sequence.

Which means that the backend, which should know the most about the process, should be giving the information in the correct order. The frontend should not have to worry about the backend giving the process steps in reverse or random order.

The front ends needs to display the steps in the order received, what it does in order to do so (no pun intended), is up to it.

  • Is this an answer? I'm not sure if you're saying that the backend is currently wrong and needs to adjust to the frontend's way of doing things, or that the backend is right and the frontend needs to handle this itself. imo it sounds like the backend is giving the steps in the correct order, but the frontend wants to display them differently.
    – Yay295
    Commented Oct 19, 2019 at 3:50

You and your colleague are both essentially correct in terms of "what you're thinking." What you've missed is a third core component of modern programming, the Model. In the Model-View-Controller (MVC) architecture, the Model is a series of data files, database tables, or other some sort of "data" that describes the fields, how they are laid out, the order of selection values, etc.

The View is what you've called the "front-end", and indeed, it should contain a minimal amount of logic, as your colleague contends. In fact, originally, connections to a mainframe occurred through a "dumb terminal." They were called so because they had virtually no logic and just showed whatever the server displayed without modification. However, there could be exceptions made here; perhaps one View might have the "default" option at the top of the list, or something else, but that should be on a per-case basis.

The Controller is what you've called the "back-end", and it should be responsible for validation of required fields, enforcing business rules, etc. It should not specifically be dictating the order of the selection values either. It should consult the Model and return whatever the Model defines. In this case, your Controller is incorrect by returning the Model in "reverse" order.

By adding a third component, you allow Systems Administrators to modify the selection values without having to affect business rules or updating the front-end logic. In fact, the SA doesn't even need to be a programmer in this situation, as the files that need to be modified are typically exposed through an Admin app of some form. Even if you don't think you need this sort of flexibility now, it's usually a minimum amount of effort to code something now so you have the option later.

Ultimately, your system would benefit from developing a Model that both the front-end and back-end can leverage to provide a consistent experience. Neither the front-end nor back-end developers should be bickering about the order of selection values, because it should be a data file somewhere that either can potentially modify to affect system behavior without changing code. It'll be more work for you now, to be sure, but in the end, everyone will be more productive with an effective Model in place.

Source: almost 15 years of experience (as of 2019) with salesforce.com as technical support, consultant, administrator, and developer.


Thin clients

When your colleage says the client is dumb he means the idea of an thin client. When you design your API descriptive and with not just simple CRUD (Create, Read, Update, Delete) operations it is easy to write a dumb client which simply consumes the API and just displays it's result. This approach ensures both the frontend and the backend stay relativly simple.

Delegate to the client

Now when you design a bigger application whose use cases are more complicated you may want to make use of the idea of delegating cpu intensive work to the client. When your server is used by many clients it makes sense to move individual computations to the client to speed the system up.

Big data

The problem with delegating to the client is in most application designs your data layer is one of the most difficult one to optimize the performance. It makes no sense to query a huge list of data send it to the client and display it there only to then filter it. When there is a certain amout of data it is better to use the higly optimized database algorithms to order, filter and paginate your data. You also safe bandwidth.


Do whathever keeps it the most simple and addreses your performance requirements.

Addressing the edit

If there is only one correct order and there is no need to reorder the data for better visualization it's the job of the backend to do the ordering.

  • Note that client applications (and end users) hate pagination. As a user, I can easily scroll through 10,000 rows in an iOS applications, while going through 200 pages with 50 rows is an absolute pain.
    – gnasher729
    Commented Oct 20, 2019 at 8:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.