javascripthtmlnode.jstemplate-engineclient-side-templating

For a website with high user interaction, is it better client side rendering or server side renderin?


I'm developing a website in which a user logs into their user account, enters data to a table (i'm using Tabulator) and then the data in the table is saved (i'm using MongoDB Atlas for data storage). The website has different subpages in which the data interacts with other data stored in another subpage (for example the website has a "Sales" and an "Inventory" subpages, so when the user makes a new sale the inventory will decrease by the sales amount). Basically it's a website in which users constantly perform CRUD operations on their data.

Today the website is rendered on the client side. Every subpage of the website has their own individual HTML file and individual Javascript file, with one Node file to handle all the backend communication with Atlas for all the subpages. I have only been using and testing the webpage from my local PC with one or two different user accounts, and it's all working fine the way it is (each user saves and works with their own data).

Now, considering that i'm planning to deploy the website (to a domain or to Heroku), and potentially getting hundreds or thousand of different users, I've been looking into this options:

Which option would you recommend considering the scalabilty?


Solution

  • Yours is a good question, but it has an answer that's almost impossible to predict. Taking a web app from a handful of users to a few thousand always uncovers surprising performance bottlenecks.

    Will a bottleneck be on raw downbound bandwidth? Will there be a big gain to be had by slimming down your response to api calls and page requests? It's possible, but Heroku and other good host vendors do a good job of bandwidth. Plus, https compresses data as it encrypts it, so repetitive html isn't as costly as it seems. So getting your server to render lots of html is probably acceptable.

    Will some bottlenecks be at the app-database interface? It's likely if large amounts of data and complex filtering criteria are in play. Every successful web app needs vigilance on its database. You'll have to add indexes or develop less elegant workarounds for problems you can't presently imagine.

    Will you have contention between processes that ingest your data and processes that use it? Probably. But the details of that contention are hard to predict.

    tl;dr. You have this thing working. There's no need to rework it now. Deploy what you have. Invite your users, and listen to them. Pay attention to how it performs, and concentrate your tuning and refactoring on areas where they prove necessary.