It takes 23 secs to load the data even if I limit it to 10 rows.
So I see two options:
Add some extra fields to the Slot thing to be able to create a faster search. I don’t know if this is really possible since the speed issue comes from filtering out based on stuff not known when the Slot thing is created.
Create a back end database trigger that does the search every time a Slot is created, thus creating a simple list that is fast to load.
Thnx for your thought on this - a new approach to me when considering speed.
I had a go at your thought, but (if I understand correctly) does not work for our use case since we need to create a lot of relations when a new user signs up. And that would take time and needed to be done back end. This takes us as back to the main problem of needing to load the slot list fast as soon as the user signs up or logs in.
My initial solution was to have a RG (visibile but not in view) to load all data. But this took so long time that the user still had to wait for it if starting the booking process directly when coming in to the page.
@JohnMark@nocodeventure Actually it turned out that the solution would be a combination of my initial points 1 and 2. But the complexity and consequences (read time and money) was not worth it, since the filters are nice, not need, to have, and we are moving the whole calendar handling to Nylas. So I simply removed the one less needed(!)