Our sorting is done on a per model basis and is dependent on the unique attributes that every model has. On a high level, the user is given the initial, default page of the model. On this page there is a "Sort By" dropdown which allows the user to select which unique attribute of the model will be used for the sorting. Upon selection, a GET request is sent back to the server with a parameter called
sort that describes which characteristic will be the primary sorter for the webpage. The backend server then sorts the database based on this parameter (defaulting to
name) and returns the sorted query to the webpage. In this way, the backend does all of the work and the frontend can treat the data the same as if it is any other data.
On the back end, the parameter is retrieved from the request (defaulting to
name), and then used to order the query that we use to retrieve each individual model. This is done by altering the SQlAlchemy query before retrieving the results. The results, once ordered, are then simply fed into the generic template such as
gyms.html and placed in each individual card. In this way, we can easily have the frontend ignore any kind of difference between a sorted and unsorted page. All of the data is already sorted for it and it just has to display it in the order in which it's given.
The benefit of doing all sorting in the backend was ease of deployment. Sorting is just a few additional lines to an SQLAlchemy query, and adding in the addition of reversing the order is similarly trivial. On the front end we would have to implement our own sorting algorithm or leverage some other sorting algorithm with a unique comparison algorithm with little benefit to the user. Our queries are fast enough that the user might not even notice that the data is changing behind them.