I have a speed problem with an API. I have the following table structure:
In the first table there are customers, each customer has locations (second table) and each location has places (third table) and each place has items (fourth table). The relations are set from bottom to top. So in the items there is a link to the places.
I have now created an API where you can request a customer and you will get all locations, places and items back in one package so that they can be saved in the iOS app.
There are nested queries to collect all the data. Unfortunately, this query took a long time and sometimes we got an abort message due to timeout.
Is there a faster way in backendless (codeless)?
In the case of places and items, there can sometimes be around 100-200 entries that the user has to call up.
The idea is that the API returns the whole packet. You could also control the request individually via the iOS app, but it would be more elegant if everything was in one package, but then I get performance problems.
Well, there aren’t many entries that have to be loaded, so I’m a little surprised that it takes so long. Am I doing something wrong that it’s taking so long? Or is there a faster way?
the first potential problem I see here is the block repeat while and hard-coded condition true.
It should never stop with such a condition. Is there a reason why you’re doing so?
Yes, originally I had a variable (bool) and if the length of the list was 0, the variable was set to 0. I then changed that by always being true, but if the length of the list is 0 then there is no more data and I use the break out of loop block.
I don’t think that’s the problem either. I once logged when each item is packed into an array and it doesn’t just stop at any point, but each individual step takes a long time and then the time adds up, so that the whole process takes a long time.
I discussed this with a colleague. The main problem here is that requests happen inside loops, and each iteration blocks the next one. To avoid this, you need to use the Promise.all JS method, which runs all requests in parallel (due to which a single request does not block others, as a result of which the whole process is significantly accelerated). But there is no such thing in Codeless. The only workaround that I can advise is to use the Custom Code codeless block, where you can write javascript and implement this logic there. However, if you are not experienced with javascript, it can be a daunting task to rewrite your logic with code.
Ok thanks in advance for the help. So is it normal that the performance of such queries is not the best? Even if there are of course a few nested loops, but in total there are only 100-300 objects in total that the system has to collect together.
I’m not very familiar with Javascript. We touched on that briefly during our studies, but then concentrated more on C# and Java.
Otherwise, would it be better if you then entered the objectId of the main object in all sub-objects and then made a query about this ID? Each table still has to be queried and if there are more than 100 entries, there is a loop again, but it may be faster.
Even if there are more than 100 entries, I always have to build a loop in which I then add all entries in a separate list so that I can output all entries at once at the end. That’s exactly why I built an API, otherwise I could also call up everything with the iOS Framework.
So is it normal that the performance of such queries is not the best?
Yes, you are right, the performance is lower if the logic contains multiple loops. Each iteration of the loop sends a request, waits for a response, and only then starts the next iteration of the loop. But if queries are sent in parallel, as my colleague suggested above, the logic will work much more faster.
Otherwise, would it be better if you then entered the objectId of the main object in all sub-objects and then made a query about this ID?
If it gets rid of some logic (loops) then you should try this approach.
