First of all, @YousefAbubaker it’s sorry to hear about your experience with Adalo. Putting myself into your shoes, I guess I would feel the same.
In my opinion, Adalo is a great instrument for building apps. But its simplicity could be misleading. When a new Maker sees how easy is it to create an app, there are a lot of things which are hidden behind the scenes; so a false assumption might appear that an app will scale linearly and will behave the same way with 300 users and 10000 users.
Unfortunately it is not that simple due to the way Adalo is built. Let’s take a simple example: imagine you have 10K records in some collection and you add the list to the screen to display this collection. The result will be that your previewer - browser will be unresponsive 1…2 minutes. Why - because by default a list loads all records; then an app tries to display them all, and that’s a tough and resource-consuming task.
In this particular case, the possible solutions could be (a) enable “lazy loading” on the list (setting to load items as list scrolls), or (b) add a filter to the list to limit the amount of data returned and displayed.
Another side note: once I’ve seen a collection of ~3K records, but its size was ~3MB. You can imagine that if you request all collection, it is already several seconds required only to get the data..
Another thing for internal collections: if you have a collection with large number of relationships and you try to get a data from these related collections, most probably this will work slower than a “plain” collection. Here I’d love to get some clarifications from Adalo developers how it works inside - to be able to architect the app accordingly.
As for the external APIs: their beauty is that you can do server-side filtering and pagination. This improves the speed greatly. Again, same principle is used here: don’t try to return a large amount of data and I have an example of 10K+ records in an external API - works like a charm.
Also, some external APIs support something like JOIN requests (getting the data from several tables in one query). If used correctly, this could save a lot of time and improve the speed greatly.
Example: I have Items and Categories tables stored externally. Instead of querying Category each time for each item in the list, I can create Items external collection in a way that it will return Category as well - using JOIN request.
One of the speed issues mentioned was related to the buttons needed to wait till the action finishes. This is a difficult topic. Imagine the button do not wait till the action finishes and proceeds with next actions immediately. And then imagine the action fails. What will happen with the data? Will it be consistent?
In large highload apps several methods are used, DB caching, in-app caching, etc.; but they are not easy to implement even in full-code.
I face this problem frequently while working with Integromat scenarios: scenario may take 10-20 seconds to complete and it is not a good practice to let user wait. In this case I try to structure the app flow and scenario in a “fire-and-forget” way: “lock” the record, scenario immediately returns 200 (explicitly or not), and then modifies all what’s needed to be modified. With the last step it “unlocks” the record for further use. This is one of possible optimizations.
Having said that, I’m not denying the speed and stability issues in Adalo. They definitely exist, and they must be addressed by Adalo team.
Also, in my opinion Adalo isn’t simply suitable for some kind of apps - don’t try to replicate WhatsApp on it, for example
On a bright side - I’m working on this platform over 2 years, and can assure you that now it is much better then it was before, so the trend is positive
Wrapping this up: some optimisations are required when building an app with lots of data. Some of them are mentioned above; some could be found in this forum, along with general speed advices as well (like reducing image size).
Adalo speed should be increased, but we have what we have, so let’s try to make lemonade
It might be a good idea to create something like a how-to about app optimizations. I guess this could be backed up by Adalo: @jessehaywood @pford @ben1 what do you think?