I’m confused by this error message. I’m on the Springboard plan and have a simple data table with 15 properties and 100 records in it.
I sent a GET request with a few parameters to the Backendless API that is asking to return all 100 records but with only 2 properties.
This works fine from the console and it works fine from Postman. But when I send the same request from Bubble it triggers the error and the call is rejected.
When I send a simple GET request from Bubble without any parameters it works fine as well.
Any ideas what I’ve done wrong to trigger the super scaling threshold?
Will be good if you provide more information about the request you send, your app id, and an error you catch.
Also, I prefer to think, if it works well with postman and console, and doesn’t work with Bubble - question might be related to Bubble. Make sense if you communicate to Bubble support.
As for Bubble: I noticed that some simpler requests (from your bubble-backendless integration tutorial) that worked just fine this morning now produce the same error as above. I can check with their support as well, if this turns out to be not related to backendless.
Sorry for the long delay.
It looks like Bubble is making requests from different locations. Without enabled super scaling system restricts amount of locations from which app can be accessed during the day.
Thanks for looking into this. This morning the calls worked fine again, but now (~10h) it seems blocked again. And I even have the error in console and in Postman which wasn’t the case yesterday.
I’ve worked from several different offices across the city today - would that trigger the block? Or is it purely the requests sent via bubble? Happy to provide that feedback to them. To better understand that: how sensitive to a location is your system? Is it on a level of country or continent?
I’m happy to upgrade to a higher plan eventually, but this current behaviour makes testing a bit difficult!
I’ve worked from several different offices across the city today - would that trigger the block?
It can be an actual reason for blocking. System detected that you have sent requests from different offices plus some requests had come from Bubble servers and it was enough for Backendless to asume that your app in production.
To better understand that: how sensitive to a location is your system? Is it on a level of country or continent?
Unfortunatelly we do not disclosure such details. I can only say that if you work from one place (home or office) during whole day, there will be no problems with super scaling even when some requests will come via Bubble.
I also can assume that if there was no integration with Bubble you would be able to work from different places across the city without any problems.
Hi Andriy, thank you for that additional information.
I appreciate that you need to set some sort of limits to make sure that users don’t exploit the payment plans you have and to make sure that the service runs smoothly for everybody.
That said, in terms of feedback, I feel that the way you have implemented this “super scaling” trigger/block makes for a really poor user experience. When I look at my usage vs the plan limits I’m barely on the chart on most of the categories:
In addition, you are selling a backend service (one that looks and works really great, btw!). It is hard to understand why the integration with a front-end like bubble causes complexity!
We don’t discriminate against bubble or anyone else. SuperScaling is triggered when our backend receives multiple parallel requests and/or requests from multiple locations. When you launch your frontend in bubble, postman, your own browser, etc, all of them constitute locations and that’s when it becomes a problem on the springboard plan.
I understand that getting all of backendless for free would be the ultimate user experience, but we would go bankrupt very quickly then.
