I did some quick digging, this is currently what I believe is happening.
In the no-code world, most terms are recalibrated, and with its user-friendly interface, builder or maker are spoiled with easiness and simpleness, intensified by nice-looking templates.
That makes us don’t intend to know the layer behind it, how it works so nice and better.
But, the rest of the world is already moving to NoSQL thing with its REST API, because it is scalable, while we are offered SQL based internal collections, which is very good in analytics, but requiring super huge amount computing power in single point, meaning not scalable, one app can eat another app’s resource and so on.
So, if this assumption is true, should we change our design to NoSQL, which most, if not every back end as a service provider support, and focus on that ?
Or put it this way, if our app is going to reach lots of users and using external collections, we need to think as JSON based database which is NoSQL, no longer focused on setting many relational properties in internal collections.
We need to go to the right direction, even tough we use no-code tools.
Well, depending on what kind of app we want to build, we also need which type of database we want to use.
If the above assumption is true, that internal collections is SQL based, which means if our app needs scalability we must design with NoSQL based, which is external collections.
Then, converting SQL to NoSQL is another challenge, and not all kind of app can do that, but the advantages are our app will be scalable like big techs, and hopefully it means our app can stand with market/product fit when the time comes.
