Well, Rails wants to be on a relational database. That's a pretty strong constraint that - say - NextJS or Flask avoid.
I think it's true that it sometimes feels a little crazy that form posts are so much tricker in the SPA world. I sometimes wonder if NextJS has got this right: build a semi-old fashioned web app with a frontend and a backend, so all the data transport in between those is pretty light on code, and then use APIs to data services with nicely defined domain objects.
Still yet to put my money where my mouth is on NextJS though.
No. It's not. It may be in your domain. But it really very much depends on the domain and use-case.
I daresay that purely on information density and amount of gigabytes, most data you use in your business is both document-based and hierarchical: files, docs, directories. But obviously I don't know you or your business, so this is just a wild guess.
This misunderstanding that "data is mostly relational", I believe, comes from the fact that it is easy to make most data relational (edit: to clarify: turning something into X is not the same as something being X to begin with). Much easier than to make most data document-based, indexed, hierarchical or into graphs. For one because the tools (RDBMSes) are mature and omnipresent. Practical: it's easy to put word docs and directories in postgres. But it's hard to have millions of CSVs with profile information accessible on directory structure
And, if what you say were true, that "most data is relational", then the best tool for most of our jobs would be a step-up in relationality from an RDBMS and we should be using graph-databases instead.
I'm talking as a whole. So yes, there are cases where it's not relational but on average most data is relational. A user has many projects. Those projects have many tasks. This is very common to most web-based software used today. Think of all the tools out there that work perfectly with this structure.
Most of our data isn't files, docs, directories. It's data given to us by our users or generated by our own processes. I'm not getting the reference to CSVs and word docs.
Yes, we store uploaded files but the metadata is stored in the database in a row that has some identifier that links to the directory where the file is stored. That works fine. We don't need a document database.
You're just only classifying relational data as data. YouTube's petabytea of data is mostly video and audio. Perhaps some of its data should be stored relationally, but definitely not most of it.
Yes, a lot of data is relational (although probably most of the world's data is not relational). But not all things need to persist data or are data driven.
If all data belongs to a user or an organization, which is usually the case, and that user does some actions to some objects, is that not relational? It's easy to see how most web apps fall into this pattern.
Building your own API to join data is absolute torture.
I think it's true that it sometimes feels a little crazy that form posts are so much tricker in the SPA world. I sometimes wonder if NextJS has got this right: build a semi-old fashioned web app with a frontend and a backend, so all the data transport in between those is pretty light on code, and then use APIs to data services with nicely defined domain objects.
Still yet to put my money where my mouth is on NextJS though.