40

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!

Sn0bli
  • 541
  • 1
  • 4
  • 7
  • What do the items in the list represent? Why does the user want to see them in that [reverse] order? – Nick Alexeev Oct 16 '19 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. – πάντα ῥεῖ Oct 16 '19 at 16:16
  • It's a visual representation of steps to be done in production. Backend provides it in the "normal" order (1., 2., 3.,). Since it's a website, frontend has to render from top to bottom. The last step is at the very top so it's the wrong order. We also thought about the extra parameter, but frontend thinks, that he still has the knowledge of the order which he shouldnt have in his oppinion – Sn0bli Oct 16 '19 at 16:23
  • @Sn0bli _"The last step is at the very top so it's the wrong order."_ Sorry, I don't get that requirement well. Can you add an example into your question please? – πάντα ῥεῖ Oct 16 '19 at 16:42
  • I'm sorry, I changed it in the edit. In short, frontend renders from top to bottom and needs 4. 3. 2. 1. as 4. at the very top. Backend provides it in the other way round. – Sn0bli Oct 16 '19 at 16:53
  • 1
    I think he's correct. Back-end APIs should support returning ordered elements based on the request from the front-end. – theonlygusti Oct 17 '19 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. –  Oct 18 '19 at 13:35
  • *"if there will be changes in the presentation we don't change the frontend"* - the front-end *is* the presentation layer. – freedomn-m Oct 18 '19 at 14:41
  • 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 Oct 18 '19 at 19:26
  • For comparison, a lot of programming languages and libraries (the backend's backend) give their containers a means of being observed in normal or reverse order, so there's precedent for the frontend expecting at least two observation modes from the backend. – Justin Time - Reinstate Monica Oct 18 '19 at 21:55

4 Answers4

83

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.

Bogdan
  • 3,600
  • 10
  • 13
  • Thanks a lot for your answer! I added something in the edit for better understanding of the question. The list has 6 to 10 elements at max which all have to be rendered at the same time. It's just a matter of representation. – Sn0bli Oct 16 '19 at 16:55
  • 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 Oct 16 '19 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. Oct 16 '19 at 17:09
  • 1
    @Sn0bli it has 6-10 items *now*... but what about 2 years from now? You should provide the (very very basic) functionality in this answer in the backend API, because ordering, pagination and filtering are what databases are designed to do. Why would you force the UX guys to write a bunch of JS to do what the database can do in milliseconds with very little code? – Chris Cirefice Oct 17 '19 at 06:23
  • 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 Oct 17 '19 at 06: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 Oct 17 '19 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 Oct 17 '19 at 17:04
  • I agree with this answer, though in OP's case, it's a matter of reversing the array in the backend or the frontend. Both equally valid solution, they then just need to agree on which side should do it, taking into account the tech stack, the complexity/performance, the possible changes in the future, if multiple clients consume the API, etc. – Emile Bergeron Oct 17 '19 at 18:54
  • @EmileBergeron why reverse the array? The easiest way is to make the query return them in the reverse order. – J_rite Oct 18 '19 at 09:06
  • 1
    I agree with filtering (pagination is really just a subset of filtering), since it cuts amount of data to be transmitted, but why waste backend cycles on sorting if you can outsource it to frontend? Why have one backend sort thousands of queries if you can have thousands of clients do that themselves instead, thus freeing backend to serve each client faster? – Oleg V. Volkov Oct 18 '19 at 09:17
  • _"Ordering of items on the screen is not important, thus not architecture."_ Ehhh. The problem outset isn't architecture related, but the solution you apply can require architectural changes. I disagree more with your overgeneralized "this is not architecture" reasoning than with OP's suggestion that this is an architecture discussion. – Flater Oct 18 '19 at 11:31
  • @Jungkook you're assuming a database. I left the implementation details out of my comment. – Emile Bergeron Oct 18 '19 at 14:17
3

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.

phyrfox
  • 529
  • 3
  • 6
3

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.

Conclusion

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.

NtFreX
  • 131
  • 5
  • 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 Oct 20 '19 at 08:01
3

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.

jmoreno
  • 10,640
  • 1
  • 31
  • 48
  • 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 Oct 19 '19 at 03:50