When your API will become public and someone will consume it, you’ll face dilemma. Should you introduce client-side filtering or server-side filtering.
Client-side and Server-side are concepts well known in Web Applications. It’s choice, where should you do the work, in client browser or your server. In general it’s better to send to the client only data he needs, but in cases, where there isn’t too much data, it’s acceptable to send everything and let client application do the rest. Additionally there are cases when client would like to get whole data to process it, its common when your API is consumed by another API.
This post will focus on Controller Action, we’ll learn about implementation details next time, but I’ll cover some basic theory.
Client-side
We’ll start from something natural for people. Client-side filtering, paging or sorting is process of data that is already in your browser. So WebAPI send you some data, but you want to display only part of them or in different order. It doesn’t take too much time, because every operation is done in memory on data that is already there. Additionally it’s easy to implement, or to say it other way, almost every component in Frontend frameworks has it implemented.
The only problem of this approach is that you need whole data, because with only portion of data you might display incorrect results. Only with whole data you can filter it. If you have a lot of data then it may take some time to load it. But when you want to display some dictionary table that has only couple entries it’s the best approach.
Server-side
When you open some website you want to see information as quickly as possible. Maybe list of documents is really big, maybe there are billions of entries, but why should you care? You don’t want to see billion at once, for you 30 entries is enough. Here comes server-side loading.
Server-side loading means that whole process will happen on server before it’s send to client. That means we can send to client only 30 row instead of whole database. At the same time it introduce additional problems, client will have to keep state like which page does he see or if he filtered or sorted data. Our API will get that information from client
Additionally now we don’t need to think about slow loading from database, we will load only small part of data. Now we have to pay attention on response time. Every time user requests another batch of data it will need to be passed again. Using server-side loading your server will have more requests with smaller data.
General approach
No matter which case do you have it’s better to have server-side loading implemented everywhere. Client-side filtering may kill your server in worst case scenario. Additionally right now server responses are quick enough so you don’t really suffer from long passing data from server to client. Additionally implementing Server-side loading can be made generic.
How does it work?
Server-side loading works pretty much the same way as client-side. You will need couple of parameters, page size and page number if you want to use server-side paging additionally sort field for sorting and filter field for filtering. Then you need to create endpoint which will accept all these parameters.
Finally use parameters to create query to your persistent storage. You need to use page size and number to calculate offset, then use those values to load only wanted number of rows and skip rows that user already have. The same thing with sorting and filtering, you’ll see example later. At the end of the day everything is just additional query parameter in request. Url may look like this /api/students?pageNumber=1&pageLimit=3&Name=Martin&sort=CourseId,Name-, where Student object looks like that
Student {
Name: string,
Surname: string,
CourseId: number
}
Filter field is key value dictionary where key is property from class you want to filter and value is value you’re looking for. Sort field is simple string with properties. When you specify property it means you want to sort by it ascending, if you want to sort descending you need to add “-“ at the end. Additionally order is important, results will be sorted in specified order.
Outro
It is introduction to the topic, next time, we’ll start coding. Now you should know that working on server is way to go, unless you want to display some dictionary.
Server-side filtering, sorting, paging cost more time, but will protect you from overloading your database with big queries.
Client-side lets you create functionality faster and is great solution for loading small amount of data, but may slow down responses if there is too much information in database.