I have questions about Scale plan and “optimizing” our app to avoid high API calls per minute, all relating to “file download” API calls. My understanding is:
when a page is loaded, there about 200 API calls are made to Backendless to download various files. These happen in much less than a minute, so if we have 3 users hitting the site at the same time we can easily get to 1000 API calls per minute for that day.
there’s no “optimization” to be done to reduce these. Even if nothing is fetched from the tables in the database (i.e. static page), these API calls will happen.
for this reason, we are looking at hosting the UI somewhere else (like AWS S3) as suggested by @mark-piller. I would love to read somewhere how this works/can be done but haven’t found any info.
The “file download” API calls happen not only on published app pages, but also on preview pages. This means that when we’re working on the app and change something in the CSS (for example) and we want to see a what things look like in a preview, we will trigger a few hundred API calls in less than a minute and be on Tier 8 for the day.
zipping up our entire application, moving it to AWS, unzipping, etc. to see the effect of a small CSS change doesn’t seem like it’s a reasonable way to work.
So, questions:
is my understanding correct re. all of the above? Maybe I have it all wrong?
does anyone host their UI off of Backendless servers, but still use UI Builder to build on Backendless? If so, how do you deal with the “preview” page load issue described above?
Please see the following how-to recipe describing how to migrate the UI to a 3rd party webhost:
Now your question:
It is conceptually correct. The numbers you quoted such as 200 API calls and few hundred API calls in less than a minute will vary depending on the design approach and complexity of the app.
OK thanks — and about the issue of building with UI Builder and seeing the results of work… sounds like the only way to avoid API spikes is to follow the procedure you describe… zip, move, unzip to some kind of staging place on an external host. Is that what you would do if you were a client on Backendless?
Further testing inspired by this topic & @Nicolas_REMY reveals that a published app produces substantially fewer requests than an app preview, presumably because components are not bundled together in single files and minified for preview pages, but they are for “production” pages.
In my test I looked at network traffic in the browser: loading published app page produces 38 requests, while loading preview page (same page) produces 241 requests. This means that a production app with a small number of users might not be too expensive in the new Scale pricing plan… but when/if developers are previewing pages while working on the app, our pricing increases massively.
So asides from the cumbersome option to move the UI onto an external host, another workaround might be to instruct devs to never click “preview”, and to work on a development container which is always published first and tested at the published URL. Somewhat awkward but maybe ok.
It appears to me that the Scale plan has the (presumably unintended) effect that development on Backendless costs much more than running a production app on Backendless.
Yes, @Alex_Klein , my point exactly in the topic I started. I now see yours is somewhat the same, sorry for the duplicate.
The effect, exactly as you describe, is that development (especially using UI builder) causes spikes when all (unoptimized) files are refetched simultaneously. As you say, this is a huge problem, because development tends to make the app cost much more than production, whereas you would think it went the other way around.
I also suppose this was unintended, yet here it is. And no, publishing elsewhere and testing there is not an efficient way to work. The single largest advantage I saw in the Backendless platform was the all in one aspect (backend + UI + all the rest). I understand Backendless now discourages hosting web apps in production, and I can hear that. But if hosting is also discouraged for development, that changes quite a bit. The UI builder becomes cumbersome to use and I don’t seriously consider juggling back and forth with zipping that has to be done through a web interface, etc. just to test a change in style or a simple change in the logic.
Reading between the lines, from what I understand of Mark’s answer to my topic, the Backendless team wishes to address the issue, so I sincerely hope that is done. Because otherwise, if I follow Mark’s very rational thinking above, then suddenly perhaps it’s the whole of Backendless which has become seriously cost-uneffective.
@Alex_Klein , @Nicolas_REMY : let me link my post below here, because a lot of what your suffering from boils down to my comment on the File API. With the scale plan, simply serving files from the backendless servers becomes much too expensive. Mark suggested to me even to “leave” the backendless files system and use things like CDNs. Of course, I don’t want to do this, because I’m loosing much of the integration advantage which led me to select backendless.
( https://support.backendless.com/t/scale-plan-and-file-system/)
Regards,
Gentlemen, I am pleased to inform you that we came up with a solution that will let us reliably identify the files traffic initiated by UI Builder preview and subsequently enable a bypass of these file fetches from the billing system. We already started an implementation of the functionality and it will be available in the production environment shortly.
Would it be possible to know if the proposed fix has already been implemented or not yet ?
Indeed, the August 1st deadline is coming quickly. With the development pages drowning the stats, it is quite difficult to make out what the real pricing impact of the scale plan is.
Once the multiple loads are excluded from the count, we will need a few weeks to make out what the real cost will be. And then it will be too late to make any decision if an implementation is needed before August 1st.
So the sooner we know where we stand, the better. Thanks for your understanding.
The change that excludes file API requests originated from the UI Builder page preview from billing has just been released. The change excludes only File download/fetch API and only for preview. All other API requests are counted.
Hi @mark-piller ,
I just checked the new “do not count file downloads in preview” feature and it doesn’t seem to work. I still see high File API requests.
For the preview, I’m using an URL with domain eu.backendlessappcontent.com
Could you please check? my AppId is 5BDF0E64-9F03-6F8E-FF75-0E183AF61100
I just checked this for your application using the “preview” button and you can see that there are only 6 requests in performance analytics, whereas the file api calls were 98.
I see. I didn’t use the preview button, instead I’m using the URL.
When using the preview button, the automatically generated custom domain is used in the URL. I have always NET::ERR_CERT_AUTHORITY_INVALID issues with this generated domain name.
The certificate I’m receiving looks very different. I’m working in a complex network environment and it seems that “someone” is exchanging the certificate.
Can I start the preview with the “native” URL https://eu.backendlessappcontent.com/ while adding your URL-parameter (e.g. &___bklst=2351F03C-848B-4A05-FF2F-52C208131900) myself?
