Never sort by yourself

Preamble

Sorting is a staple action in coding. The demand to organize data in either ascending or descending order is frequent, and often, we are faced with the challenge of morphing the same data to match different sorting needs before displaying it to the user.

Sorting becomes more complicated when dealing with massive volumes of data; however, we can’t do this client-side. So, we must resort to performing this action server-side. But is it something we should be handling on our own?

Let’s explore it further.

The problem

Imagine this scenario, you have a basic REST endpoint that return a list of users:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

[
  {
    "id": 1,
    "name": "John",
    "age": 20,
    "email": "john.doe@gmail.com"
    },
    {
    "id": 2,
    "name": "Jane",
    "age": 25,
    "email": "jane.doe@gmail.com"
    },
    {
    "id": 3,
    "name": "Bob",
    "age": 30,
    "email": "bob.doe@gmail.com"
    }
]

You’ve also got client software that utilizes this endpoint to show the user list. The issue? This list has to be sorted by the name field in ascending order. So you’ve got two choices:

• Sort data on the client side.
• Sort data on the server side.

The first approach is relatively straightforward, but it carries a significant disadvantage:

• Sorting on the client side can be extremely slow or even impossible when dealing with large datasets.

The second option may appear ideal, but carries its own shortcomings:

• Additional endpoints are necessary for every unique client application view.
• New endpoints will be needed for every field/order sorting requirement.

The solution

The solution revolves around the utilization of a query parameter that allows us to indicate the preferred sorting field and order. Let’s denote this as sort. The request might then appear like:

1

GET /users?sort=name:asc

Or if you need to sort by age field in descending order:

1

GET /users?sort=age:desc

By adopting this approach, you can sort data server-side and deliver sorted data to the client without the need for creating new endpoints for every field/order sort.

What about multiple-field sorting?

For multi-field sorting, you may consider the following format:

1

GET /users?sort=name:asc,age:desc

Alternate Query Parameter Representations

There exist differing yet commonly adopted methods to represent sorting in query parameters:

• sort=name:asc,age:desc - This is undoubtedly the most comprehensible and highly adopted method, offering flexibility in adding more order directions (like asc-null-first, desc-null-last, etc.). You can choose any delimiter in place of :.
• sort=name,-age - Although this method is also well-liked, it offers less flexibility in adding more order directions. Nonetheless, it’s compact and quite readable, with the - sign, optionally replaceable with < or > signs. The + sign is always redundant.

Conclusion

Sorting data is a staple action in coding, but it can pose challenges when dealing with large volumes of data, especially when different client-side applications require different sorting needs.

Sorting data on the client-side can be slow or even impossible with large datasets, and server-side sorting often necessitates the creation of additional endpoints for unique client-side views.

However, the use of a query parameter for indicating the preferred sorting field and order can offer a solution. By using this approach, data can be sorted server-side and delivered sorted to the client without the need to create new endpoints for every field/order sort. This provides a flexible, efficient, and scalable solution for sorting data in coding.