Hello, I see this pattern very often. Usually when there is a high rate of interactivity required and people rely on the backend too much.
Loops and database actions
Currently, you’re doing a lot of calls. From what I see, I’d solve the first part first though, as loops (front-end) and Database Actions are never good. This can lead to high time complexity of your workflows, so you should either:
- Simplify your query, I’ve recorded a video about this case yesterday for an another post
- Move your (looping) logic to the backend - if you’re unable to simplify it in the front-end
This should reduce the latency and increase the speed by quite a lot, because in both cases, it will reduce the amount of request, thus reducing the amount of the idle while you’re awaiting the responses of those requests.
Relying on the backend too much
As for this second part, I usually suggest what I call a “Redux-like Pattern”, this is a pattern which is actually used in the standard web development - but don’t be frightened, no coding required - and I actually often teach it on my 1:1 no-code coaching sessions.
As we already successfully found out, the issue is the latency of the calls between Supabase and WeWeb and this is a normal thing, nothing wrong with the two. This pattern I mentioned, solves this issue by relying on the state of your app’s state which you’d store on the front-end. But… what does this mean?
What is even “the state”
WeWeb actually is pretty powerful in this, because it has something called “the state”, which basically you can immagine as a storage which remembers the current state of your app, this can be variables, widths, heights, but also, as in your case, it can be more complex stuff, such as the cards in your kanban, which in simpler terms is just an array of objects with some properties.
Using the Redux-like pattern in WeWeb
To kinda bring all of these concepts together, and of course improve your app, you want to rely on the above mentioned state of your WeWeb application. You can do this, by creating variables, that will store the state, such as an array for your kanban items, which you will, with a workflow on page load set to be your initial database’s information. After that, you no longer re-fetch this, unless strictly necessary. Instead, you will be updating this state, stored in your array.
So in your case, you would go and Update the items by Add approver
or Database | Update
and instead of hitting the Load active invoices
, you’d simply use a Change variable value
workflow action, to go and update the object, in the array in your state, thus having a faster feedback and eliminating the last call - thus saving time and having again a faster feedback.
This simply means, that you should use the variables, to store informations in your app, and change those variables after successful changes to the db, instead of relying to over fetching the database each time, because it’s slow and inefficient. Also - don’t do loops with Database Actions, it collects so much latency that you can’t immagine.
Edit: By the way, it’s not a performance issue of WeWeb, it actually is the latency of the calls, if you for example had 0.00X latency (NASA’s 10000 Gbit internet) you’d have instant feedback, but that’s not realistic, so you have to optimize for it.