Hey guys, I am Venkat and this is part 11 of web development with blazor video series. With
the arrival of webassembly we can now run server-side programming languages
on the client machine in the web browser. Any server-side programming language really c-sharp,
java, php, python etc. So, the question is, if we are building a data-driven web application should
we perform operations on the data like, paging, sorting, grouping, filtering etc on the client
machine or on the server? Well, each approach has its pros and cons. Which approache is better
depends on several factors like the volume of data, that is how many data rows you have.
Do you know how powerful your client machines are and their processing capabilities. How often these
operations that is paging, sorting, filtering etc are performed. Your application architecture etc.
In general, downloading the entire data to the client machine is okay,
if you have just a few hundred or even a few thousand rows, the benefit of this approach is,
no further connection to the server is required. Operations like paging, sorting, grouping,
filtering etc are processed completely on the client machine. So, basically we're using the
processing power of our client machines, this also means the load on the server is reduced
and which obviously allows the server to serve more clients. However, a word of caution though,
it's never a good idea to assume your clients always use high-end machines to access your
application. Your clients may use all sorts of devices laptops, desktops, tablets,mobile phones,
any type of device really. The point is, if these client machines have less RAM or CPU, I mean less
processing power, the application may not perform very well and eventually the end users may stop
using your app. Depending on the client machine processing power, the network speed and the amount
of data to download, the initial request may take a very long time. Now, server side processing.
In general, if you have lots and lots of data, maybe several thousands or even millions of rows,
I think it is better to perform processing on the server instead of the client. For example,
if paging and sorting are processed on the server, we only need to send a few rows 10, 15,
20 or maybe 100. How many rows are sent from the server to the client really depends on the page
size. There is no need to download the entire data set onto the client machine. Request and
response cycles are really quick because there are only a few rows to download from the server. Also,
database engines are much more faster than doing the same operations in code on the client machine.
Now, here's one of the very common interview questions.
I have over a million rows in a database table and I want to display them on a web page. What
approach would you take to efficiently display this huge volume of data? Well, displaying the
entire data set of over a million rows in one-go is a very bad idea, it takes too much
time to download and may explode both that is the browser memory as well as the rendering engine.
So, depending on the application requirements and what the users are trying to achieve,
there are several approaches to efficiently display huge volumes of data. One approach is to
provide a download option, maybe the end user is doing some analysis on the data and he needs the
entire data set. Provide a download option instead of rendering the data on the web page. Again,
depending on the application requirements you may provide different download options, maybe download
to Excel, CSV, PDF etc. Paging is another approach and very useful if the user does not need all the
data rows in one go. Depending on the page size, display 10, 50 or 100 rows at a time. The user can
click on the page numbers at the bottom to retrieve the next set of rows he wants. It
doesn't really matter how many rows we have in the underlying database table. Since we are retrieving
and displaying only a few rows maybe 50 or 100 at a time, performance should not be an issue.
Another approach, is to provide a search page so the end user can search, filter and retrieve
only the data he is looking for. We can even combine these three different approaches search,
paging and download. Row virtualization is another great approach. With this approach only a few rows
are initially loaded and displayed. As we scroll down on the page, rest of the rows are loaded
and rendered on demand. This is the approach used by Facebook. If you are using Microsoft.Net
to build an enterprise class data-driven web application then you may consider using Syncfusion
DataGrid component. This component supports all these features paging, filtering, grouping,
row virtualization, download to Excel, PDF, CSV and many more. The good news is, it supports
all these features both on the client side and server side. It's tested and fine-tuned to work
with a huge volume of data, so performance should not be an issue. All the sync fusion components
are free to use with their community license. Use this link shown on the screen to download
the free license, again I'll have this link available in the description box below this video.
Now, we already discussed implementing client-side paging and sorting in parts 8 and 9, server side
paging in part 10 of this video series. We'll discuss implementing the rest of the features
in our upcoming videos in this series. As usual, I'll include the link to the complete
course page in the description box. That's it in this video. Thank you for listening.