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:
@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 firstname.lastname@example.org to your ap? We’ll have a look at what is going wrong
@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