I am evaluating the feasibility of splitting the app into 2 apps to benefit from 2 x 3000 API call / minute limits and I need a clarification on API call consumption.
I have 2 options to achieve a split,
a) a front-end / backend split
b) a split of certain high-volume API services on the Backend.
Here are my questions:
In scenario ‘a’, let’s assume for simplicity that my Backend is generating 1500 API calls per minute while the front end is also generating 1500. Let’s assume that about 500 API calls on the front end are generated when a button is clicked, and we trigger a GET API call using the REST key to the backend to retrieve the contents of a table. I understand this would trigger Data Service Find API calls.
If I transfer my front end to a separate app, will this still be 500 or will it double because both apps will be consuming API calls, one from the front end and one for the back end?
In scenario ‘b’, I transfer a high-volume API service. The methods in this API service again may call other methods or get records from the database. By transferring this to a new app, will I be doubling the API calls?
The API server counts each request as an API call for the app, which means if you run a request from client App A to the API Service of App B it will count as 1 API call for App B only.
I hope it answers your questions
Btw, as your business grows would you like to consider switching to another installation type Pro or Manage? Having one of these installations you get many benefits and advantages, here are some of them:
it will be installed only for your apps and you won’t need to share hardware resources between all customers as it is in the Cloud version
you can control all limits
you can enable CloudCode cache which extremely accelerates executing CloudCode
We would indeed be interested to explore a Pro or Managed account and we had some email exchanges last month with @mark-piller. I also understand you are in the process of adjusting your pricing.
I think we are still at a scale “in between” your pricing plans. We are nearing a stage where we will be able to afford the single-server deployment option as per current pricing, however I am uncertain if this option presents worse uptime risks than Cloud 99. We are not able to consider pricing of the high-availability option at this time.
This is why we are considering splitting into 2 apps at this time.
I would appreciate arranging a call to understand the new pricing before I proceed.
It seems that the best option, for now, is creating a second app. The idea is to move our entire UI Builder logic to the second app since our UI builder containers generate many API calls.
Can you please confirm whether the steps below capture the high-level workflow we should do? Please let me know if we are missing something.
We go into the new app and delete all the backend API services we will not use.
We go into UI Builder in the new app, and wherever the logic calls Backend functions, we connect these to the old app backend API services using REST blocks.
(Please confirm feasibility) When we are ready and have tested that everything works on the new app UI builder, including that it fetches data correctly from the backend of the old app, then is it possible to transfer the custom domain we are using from the old app to the new app? This will make the customer experience much smoother.
Hi @mark-piller ,
Great to hear about the first part.
Sorry, maybe my assumptions are mistaken on the second part, so I should not proceed until I clarify them.
I am searching for code in my existing app that consumes a lot of API calls. Understanding how the analytics page works has been helpful, although I am still having a bit of trouble. What we are doing is adding separate API keys on a number of key methods. Then the Analytics page breaks out the API calls per API key. I still have a large block of Find API calls on Cloudcode, which we are currently trying to split per Method by adding different API keys (thus shifting the calls from CloudCode to new keys so I can see which ones consume a lot). Does this make sense?
As I notice that my UI Builder containers consume a lot of API calls, does it not make sense to move them to a different app? I understand this will shift API calls away from my current app to the new app and allow me to enjoy another 3000 API call limit. Is this mistaken?
In parallel, I am also trying to put transfer high volume methods out of Backendless into another No Code service that does not have a similar limit.
Your approach makes sense. But, as Mark pointed out above, I’m not sure how this will help you reduce the metric either.
I still have a large block of Find API calls on Cloudcode, which we are currently trying to split per Method by adding different API keys (thus shifting the calls from CloudCode to new keys so I can see which ones consume a lot).
I assume that a large number of Find API calls on Cloudcode are related to the service operation. They invoke the Find request when executing the logic.
If some of your services call app B instead of always calling only app A, this will give you additional API calls per minute. But the core question is, won’t this break anything and how much working time will it take for developers to implement?
I don’t know @Marina.Kan@mark-piller . I really don’t know how much time it will take. I am already spending significant development time over the past 3 months refactoring code and reducing API calls.
I hope the second app solution will not generate extra API calls. The simple use case is: app A is the backend, app B is the front end. When you click a button in app B, there is a Find request that Gets objects from a method in app A. Please confirm this increases my combined API call limit without increasing API calls.
I can’t see a solution other than this. I must admit it is getting a bit frustrating.
I would love to pay double what I am paying now and have double the API calls per minute in App A, but I understand this is impossible for technical reasons.
I am afraid to move to a Pro account with a single server for uptime reasons + I do not have any internal capabilities to manage hosting. If I had clear pricing, implementation guidelines, and structured support towards this from the Backendless team that is usable by my no-code team, I would consider it. But it feels like the Pro Account requires an upgrade of internal capabilities from No-Code to Full-Code. If this is true, it means that Backendless only allows us to scale to a certain point as a No-Code team, and it is, therefore not a great solution for a scalable app that is managed by a No-Code team.
It feels like a bit of a dead end.
I am leaning towards removing a number of high-volume methods to another app that is not limiting me in this way.
If there is other advice you can provide, or if you can guide me towards implementing a Pro Account with a No-Code internal capability, I am willing to learn and spend time. Because I do really like the Backendless ecosystem and think it can serve us well if we are able to scale.
When app A processes an API request, it will be counted as an API request. It doesn’t matter if that API request is made by app A, B. C or Z. What matters is that app A handles the request and the call count will be reflected in that app.
That is an incorrect statement in its entirety. Backendless Pro is the same identical technology stack as Backendless Cloud. Apps running in Backendless Pro run the same way as they run in Backendless Cloud. What’s different though is you need to maintain the infrastructure where the actual product (i.e. Backendless Platform) runs.
Something very important to keep in mind: Backendless Cloud is a shared hosting environment. It manages multiple (tens of thousands of) apps at the same time and handles all the logic for proper resource allocation. As some applications grow faster than others, they start generating significantly greater load on the system and thus demand larger resource allocation than many others.
Currently, our pricing does not take that into the consideration. There may be 2 different apps on the same pricing plan, with both developers paying the same monthly fee, but one of the apps could be draining server-side resources, while the other stays relatively idle. This is not right. What we currently do is put the requests/minute limit so that other apps have a fair chance to get the much-needed resources. This is a temporary solution. The proper way to do this is to modify the pricing where it is based on the server-side resource utilization. We will be putting it in place soon. I will be happy to discuss the new pricing with you as well as other options (i.e. Pro deployment) so you can make an informative decision about the next steps for your app.
I do not mean to make incorrect statements or emotionally charged remarks. I am trying to decide on the future build strategy of our product as well as the resources I will need internally in each case. It is clear to me that the stack is the same. My question for Backendless Pro is indeed whether a no-code team is able to
Maybe there is currently a pricing gap for companies that are “mid-scale” who do not currently have the resources to hire a full stack coding team internally or afford your high-availability Pro plan.
I will request a call via email. I understand you are improving pricing vs resource allocation and this is great.
On the call with @mark-piller we identified that logging is using a lot of API calls.
Mark mentioned the use of the Real Time API to potentially turn logging on/off in our methods. I would love a bit more clarity on this, if I have understood it correctly.
For example, I have a logger in a method, as per the screenshot.
I am unclear as to what I need to add to the method, or elsewhere to turn this off or on. The way I know how to do it, would add a boolean logging true/false step before the logger, but it would take an API call to go search for the boolean value in some table.
Make logging conditional based on a configuration value in the database (or in Hive). Put a boolean value into the database (or Hive). The value would indicate if logging is enabled or disabled. In your API services, make a call to check if the logging is enabled. If it is, use the logging API. If not, skip it. This can be encapsulated in a Custom Function.
Thanks Mark.
The logging policy is per method, right? I would not be able to store messages from multiple methods in buffer? And when the messages are reached, that’s when an API call is consumed?
If I use a database property to make logging conditional, I still consume an API call to check the database for the boolean property of whether logging is on off, right?
When a logging policy is used in the API services, it is scoped to a single invocation of the service. Once an API service method is done, Backendless will not hold any “state” around for subsequent calls.
The policy will be flushed under the following conditions:
Specified number of log messages in the buffer is reached
or
Specified time (flush frequency) is elapsed
and
API service method finishes its execution
As for the database property, yes, it is an API call. However, if your service sends X log messages now, the trade-off is you make one call to save X.
