After doing some testing I realize that Backendless will prove to be extremely expensive.
Here is a simple example.
1 Android user requests 1 page of ITEMS, size = 10 (thats 1 call)
For each item you will need (isFavorite, likes, dislikes, comment-count, maybe an image), thats 5 queries per item
Now we are at 50 + 1 = 51 query for just flat opening app cost.
God forbid if he scrolls to the next page, thats another hit for 51 calls in the same minute.
Just to be VERY VERY VERY conservative, lets say one user costs you 51 + 51/2 ~= 77 calls/minute
Lets say you have the 1200 calls per minute account, you can afford only 1200/77 ~= 16 concurrent users.
And this is a low ball figure for 100$ / month.
If I am making a mistake in understanding API calls here, please correct me.
Even if my math is half correct, its really NOT FEASIBLE.
Hi Fahad,
if I get you right, you store such entities as isFavorite, like, dislikes etc in a separate tables for each one? If so, have you considered a solution to store these values in one table, called Post for example. I do not see the point of storing every value in the new table until it really is needed. So in that way you will need only 1 call for opening the app. Am I wrong somewhere?
After all, you can organize your code and your database as you like: you can do just a few queries to get all the data, and you can put all the data on different tables and then, of course, you will have to do dozens of queries - but whether it will be optimal for the client, even If it did not cost you money?
I did go through that decision in the design process. From what i recall, I didn’t do this because there is a limit on record or field sizes or something like that, to stop people from storing binary files (images/mp3 etc) within the record. Eventually if you store the list of users who liked a post, or commented on a post within a record as an array, you could reach that limit, no ?
You are right about the likes, dislikes stuff, i can also store counters per post and increment them to keep track, but just generally, that API call limit per minute seems very small.
I’m just testing out multiple backends for a project, MongoDB, Backendless, even going back to MySQL. Just looking at all that seems like you guys have very strict limits, and overage charges will accumulate.
When you retrieve some data from a table and you need some related data - that’s just one API call, since you can load up to 10 levels of relations loaded with that parent one in one request. Yet the request would be slower the more relations you load at once (which holds true to any database request regardless of whether its Backendless or MongoDB or MySQL).
When you retrieve data from multiple unrelated tables - then you need a few more API calls since there should be a request per table, but still this won’t be even close to 50 (assuming you haven’t done anything fundamentally wrong in your UI, since your app shouldn’t require a lot of unrelated tables on one screen).
Also, you can’t compare Backendless as a BaaS solution with pure databases like MongoDB and MySQL - they’re just totally different in the number of functionalities provided: the latter ones are just databases, like the Data Service in Backendless, while the BaaS solutions provide you with much much more functions and services. Keeping all that services stable and still trying to improve things is a costly business, and API calls generated by the customers’ applications affect that stability most of all.
Nevertheless, even the Free plan limit of 60 API calls per minute (1 call/sec) combined with in-app caching should be enough when you’re just starting your business and don’t have much users which generate the load. The idea is that when your app gets traction and makes more API calls, you should be able to receive enough revenue from it to afford extensions on the BaaS side.
Returning to your question, I just think you got the data retrieval a bit wrong: you don’t need to load each relation separately using a dedicated request for each. You can just load them all in one request by specifying it in the DataQueryBuilder object. And also there’s a way to configure the page size so that you retrieve 100 entries instead of 10 in one request.
I understand your point, and yes I ignored the relational object fetch using the depth parameter. Even still, I’m looking at an application where a server inserts data, about 10k records a day, and multiple users also accessing the database. Imagine a scenario where you need to update something daily. Eventually with this model you will start going over on multiple levels. No. of records are over 400k, api requests are over 1200/minute. Its just not scalable in terms of $s.
Well i can compare backendless to mongo DB, since it seems like you guys are wrapping it with a java. So why wont you unleash its full capability in terms of data storage etc. I’m not asking for sharding here, but limiting the # of records is pretty bad (400k is really low). Its a really bad lock in, if my database goes over 400k records, I’m locked to pay overage forever.
I mean i can get by with deleting 2 week old data, but then again, why should i do it from a purely storage point of view when other database can store up to terabytes of data.
The free plan is generous i agree and thank you for that.
I mean I’m not trying to offend anyone, just laying out my thoughts on the matter. If you can please tell me the math then, how many concurrent users can I support for a general application for 200 - 300$ budget ? You can use my example and fix the numbers if you like.
I’ve just seen how AWS and AZURE charges rack up, so I’m a little extra cautious.
For just $100 you can switch to our max Cloud 99 plan and have your API calls value boosted to 20/sec, which is a rather big value for any starting business. 400k data objects also shouldn’t be a showstopper if you do the mentioned periodical cleanup, but also you could spend $100 more and get 2,000,000 objects if you need. Of course you could just use MongoDB and forget about this limit, but this way you should write your own data access layer, permissions layer, maybe even set up your own server for business logic etc., and then spend some time to support all that stuff.
What I meant to say is that BaaS is a service which requires money to be alive. I think if you compare our pricing and the pricing of any similar provider, there won’t be much difference.
Looking at your requirements, I can say that you should definitely fit into $200-300 budget and maybe even less (as I described above).