The /admin/members page won't revalidate at this moment because (I believe) the data for the table (1300+ members) is too large (3.57 MB). This presents a problem as the data in the table is from the static generation (build/deploy time) and won't ever be updated afterward.
- Currently, data in the table is filtered & sorted client-side, meaning the server only queries and sends the data to the client - all 1300 members are loaded into the browser's memory.
- As more members join, the number of members active and loaded into memory. Should Portal continue to exist for several more years, the number will grow to several thousand.
- It is preferable that data is not purged or deleted to combat this issue. Wouldn't it be nice to retain data on past members who graduated?
- Purging member data is a band-aid solution regardless. If ACMUTSA grows further, then purging still won't resolve the problem anyways.
The likely solution here is to do what should've always been done - sort & filter on the server. Using SQL. Like a normal person.
A solution like this would make the page load faster, cache faster, and revalidate faster. It would actually get rid of SSG and move to SSR. Server load would increase by a bit - especially if the admin page is being hit quite a lot - but all of the problems have a much clearer and more established way of working.
If anyone has some thoughts on alternative methods - you're welcome to discuss them, but given that the core of the problem revolves around 3.5+ MB of data being sent to the browser - client-side filtering is straight out. The sorting & filtering mechanisms have to be done on the server.
My only existing question is: Can we sort & filter using the current table? Or is something else required?
The
/admin/memberspage won't revalidate at this moment because (I believe) the data for the table (1300+ members) is too large (3.57 MB). This presents a problem as the data in the table is from the static generation (build/deploy time) and won't ever be updated afterward.The likely solution here is to do what should've always been done - sort & filter on the server. Using SQL. Like a normal person.
A solution like this would make the page load faster, cache faster, and revalidate faster. It would actually get rid of SSG and move to SSR. Server load would increase by a bit - especially if the admin page is being hit quite a lot - but all of the problems have a much clearer and more established way of working.
If anyone has some thoughts on alternative methods - you're welcome to discuss them, but given that the core of the problem revolves around 3.5+ MB of data being sent to the browser - client-side filtering is straight out. The sorting & filtering mechanisms have to be done on the server.
My only existing question is: Can we sort & filter using the current table? Or is something else required?