Request rate when developing and testing with UI builder

UI Builder
1

Hi,

Since the announcement of the change in pricing, and like many others, I found out that my pricing would multiply 10-fold or so, putting in danger the business model I had built over months.

When trying to analyze where the peaks come from, I stumbled upon a possible hypothesis, that I would like you to confirm if true.

Is it the case, when building an app using UI-builder, that this will initiate many requests when developing and/or when testing? Indeed, since the components are not bundled together in single files and minified, am I correct to think that many more files will be fetched than with a built-up application?

Do you have any plans to exclude development requests from the total being counted ? Indeed, the test application is not optimized for performance in any case, so it would make sense to unprioritize these API requests as opposed to production requests, and thus have them use resources when they are available.

Thank you for helping us understand if and how things can be optimized.

1 Like
2

Hi Nicolas,

Your hypothesis is correct. Running a page in preview will result in additional file fetches that will count as API requests (since they are). We are looking into various options that will prevent this specific use-case from impacting the billing in a dramatic fashion.

Regards,
Mark

1 Like
3

Would gladly like this to happen since I (very roughly) estimate a third of my API requests come from preview. This probably triples the resulting price :face_with_diagonal_mouth:

4

How about these ideas for starters ?

  • excluding API requests made with a logged in Backendless user token, and
  • excluding file requests made at /app/XXX/ui-builder/*
5

Thank you for sharing your suggestions. Unfortunately, these will not work for the following reasons:

Page previews are executed by a browser (we simply open a URL for the page). As a result, any custom headers are passed into the requests. Additionally, we cannot force the header to be present in all “sub-requests” such as CSS/JS/images, etc.

This would create a “billing hole” since I envision some people would be using that path pattern to launch/access their apps publicly.

Regards,
Mark

6

You probably know best :slight_smile:

However, when previewing my app just right now, my browser is showing 300+ requests, with many many many code.js and bundle.js files. It doesn’t feel fair for the billing to end up in Tier 7 just because I previewed one page and all requests were made withing the same minute.

7

And with that, we go to the point made in your original message… :wink:

1 Like
8

I have a hard time envisioning that… but I guess that it’s theoretically possible. Maybe there’s a way to handicap dev/preview apps so they can’t be used for production but are still useful for previews and development? Like perhaps limiting the number of users that can access them, or even setting a list of allowed IP addresses that can access them? Just some ideas/suggestions :smile:

9

Please see this.