Searching on the client side instead of the server?

Semi-hypothetical question/idea here.

Imagine you have a server that uploads a JSON file of one of its database tables’ contents every X amount of minutes, let’s say 30 for example. This table is not too large, maybe 20k docs with 5-6 fields each. It puts this in a public directory.

When a user searches, instead of performing a query on a server, it loads and searches the JSON file all on the client-side, then populates the loaded web page with any relevant results.

Once you click on a result, it takes you a page that is loaded normally via the database with up-to-date information.

What would the implications of this setup be? Would this actually be viable in some scenarios, to save on heavy database usage? Would fetching the JSON file from the server each time actually be more demanding to the server than just using a database?

I look forward to hearing your thoughts 😊

Sure, you could do that, but it'd only be a reasonable choice on some client devices.

For example, if a client has a very old phone without a great processor, making the client download the 20k records and then go through each of them when making a query could make the app feel very sluggish to the user (depending on what exactly the query entails). Another issue is that storing 20k records on a small device could be a problem.

Client-side filtering would work better on desktops. Desktops have more power and more storage capacity; IndexedDB is a common approach used when a site wants to store a good deal of information on the client-side.

But just because it's possible in some circumstances doesn't mean that it's a good choice. In most situations, the professional approach would be to put the server to work to do the filtering needed, and to serve the results to clients. If the server isn't up to the task of filtering itself, you may as well upgrade the server.