I’ve developed several apps using AppSmith which comprise of around 8 pages, each with an infinite scrolling table that contain up to 120 columns. Each cell in the table triggers an update query to my Postgres database whenever the cell is updated, to imitate the behavior of Excel/Google Sheets.
I have a few questions regarding performance which I’ve already faced:
1 - How many rows can these tables realistically display at once? I’m experiencing major lag when a cell updates.
2 - The widget editor itself is being super laggy and glitchy. Whenever I want to change the name of a column for example, the AppSmith UI takes about 5-10 seconds to respond to my initial click to begin editing, when I’m typing, there’s a good 5 second delay too. It also takes a while to be able to enter the editor for a given column aswell. Is there anything that I can do to rectify this issue or does this just come with having 100+ columns? The same issue occurs on my smaller tables of ~20 rows.
3 - Will AppSmith be able to support having ~10 users per app editing several rows at once?
Thanks in advance, AppSmith is a great resource for those getting started!
If you need to display large data sets in your table, we recommend implementing server-side pagination to avoid performance issues. Appsmith supports responses up to 5 MB at a time. Here are some of our guides that should help:
Unfortuantely with the use case that we have, we’ll need something with infinite scrolling support. We’re looking to replicate Google Sheets’ functionality so this is a must!
I calculated how many rows of our largest Postgres table (column wise) are in 5MB and it’s equal to 1901 rows. We had ~20 rows on display and we were already facing issues.
@benjaminbialy in this case, the issue could be that you are using 120 columns. This doesn’t seem like a viable way for your users to work with the table. Have you considered only returning the columns that can be visible on the screen?
So instead of a select * statement, would it be viable to only select the columns your users need to see at a given point in time?
@benjaminbialy how many rows do those have? Typically we see that around 40k cells i.e 20 columns x 2000 rows should be fine. We’re working on improving the virtualization for columns as well here to help this.
That should not be the case unless the smaller tables are also on the same page as the large tables in which case, it’s those that are slowing the entire app down. Could you invite support@appsmith.com to your ap? We’ll have a look at what is going wrong
We are loading nowhere near 5MB of data, I should be able to display 1900 rows (with 120 columns) before running into that size of data.
At the moment I’m displaying all of my data in the table, attempting to replicate Google Sheets’ UI/UX, in the largest table there’s about 100 columns with 30 odd rows.
On the smaller ones, 12-20 columns with about 20 rows, if that.
I have several apps all containing about 7 tables each. The issue is much worse on the larger columned tables but still present on the smaller ones too.
To your understanding, do columns have a greater impact on performance compared to additional rows? I get the sense that it’s more to do with the number of columns than it does with the rows.
Upto 5MB of data is fine when you are using pagination.
In the places combined page you are rendering 160 rows with 90 columns, I believe thats the reason for slowdown you are experiencing.
Normally this would be handled by virtualization, but virtualization doesn’t work with dynamic row height.
Can you please try by setting this as table data {{get_places.data.slice(0,10}} and let us know if it makes things better for you.
When virtualization is in play, usually rows are virtualized so number of rows don’t have any significant performance impact.
@benjaminbialy regarding dynamic row height virtualisation, we haven’t been able to crack it yet. We are yet to figure out if it will work well or not, if you plan to use wrapping i suggest not to exceed 50 records on a page to be very safe.
Coming to infinite scrolling we do plan to support, but we are looking for people who can help us understand why their use-case needs infinite scrolling. Can you help us out with some details on your app, your users and why you need infinite scrolling in the table?
If you would like to have this conversation on a call instead, it would help me prioritise this better. Here’s a link to my calendar if you are willing to talk to us - Calendly - Dilip Pitchika
, does Appsmith plan to support infinite scrolling?