I’m trying to pick the best plan for development. Currently I have the Scale plan with the lowest threshold to prevent runaway costs, but it’s impossible to test anything without hitting the 5 call/min threshold. One clean start login from my app exceeds that so I’d have to raise the limit just to handle a recompile. I’m starting to think the Cloud 99 plan would be better because it has a “set” limit and a flat rate? However I can’t find in the comparison where it states how many calls/min the Cloud 99 plan can handle.
The Cloud99 plan has a concurrency limit of 3500 requests/minute. Please keep in mind that the plan will be phased out on May 1st of this year.
As for the login causing it to go over the limit, are you developing with UI Builder or some external frontend?
Regards,
Mark
it is an iOS app…on a clean start login it has to look at several tables to update the client and download images for messages, profile, etc. so hitting over 5 calls/min is pretty easy. In one minute I could login, click around the app, and fire off a few test msgs so I’m looking for a plan that doesn’t have the minute limit. Seems like the Cloud99 would work but I don’t want to spend days fiddling with plans again if it’s going to be phased out too. What plan do you recommend?
I recommend two things:
- Stay with the Scale plan and raise the tier threshold to allow the bare minimum of the API requests handling everything except for the file downloads. Paying $149 for Cloud99 while you’re in development is not reasonable.
- Move the images outside of backendless to some external webserver (every file you fetch is an API request). Alternatively, you could put a CDN in front of Backendless (many CDNs offer free tiers). This way, you will not hit Backendless every time, as the images will be cached in CDN. For more info, see the docs on how to configure a CDN: Cache and CDN Integration - Backendless REST API Documentation
Regards,
Mark
my usage on the Scale plan would have been $200 per month so the Cloud99 would have saved money and I wouldn’t be worried about per/min threshold while trying to focus on features.
yes moving images, etc would be part of the “scale up and deploy” plan, but for now I was trying to keep things simple and focus on a proof of concept/demo app. Setting up a CDN might not even be the best approach when the app is complete so I’d rather finish the app first and optimize second but we have already had that conversation yesterday.
Hard to stomach the Scale plan while still in development because I’m NOT trying to scale anything at the moment.
If I were you, I’d concentrate on figuring out why the app makes excessive calls for a single user. For example, for the period of time you mentioned you were actively building it, the system shows the following (the chart is for August 29th, 2023):
That’s 12,531 “Find by ID” and 3,420 “Find” calls in a single day. That doesn’t seem right to me. Of course, you and I may have different visions for how an app should be built and what priorities one should have at any point in time. I respect that and am simply sharing what I would do to make it work.
I don’t worry too much about stats like that until I after the dust of my app design has settled. Too many things change in the process to optimize this early. But yes different approaches…unfortunately this plan change negatively affects me. I’m more old school and used to do all my dev with a MySQL db on my own PC so I never concerned myself with API calls and things like that until basic functionality was settled. Now I have to pay attention to things that don’t ultimately matter.
Also worth noting that this isn’t a “single user” as one would expect in a real world scenario. The app is in development so there are lots of reasons you would see “excessive” calls as compared to a real world scenario when someone might open the app (with cached data too) a couple times a day? I’m sure you also write code that is very different in development then it is in production. I guess my point is that it would still be nice to have some kind of plan for development because an app in development is very different then one in production.