[arcticfox]

What happens when your backend isn't SQL? Then you'll need to accept a different query language as well. Wait - maybe those could be abstracted into a single query language? Ah, it's GraphQL!

To your other points:

* no matter what you do to expose an API you have to set up security

* there are already server side solutions that help enormously with implementing your own endpoint

* I don't see the logic behind your client-server opinion. You seem to say that the server should be defining the data that the client needs.

[xmatos]

Regarding the last point, yes, that's what I'm saying. And it's not a matter of opinion, but of decades of computer engineering best practices.

Your app's UX will depend on how much code runs on the client. It can vary from a dumb terminal, like classic web applications, where everything runs on the server, to smart or rich clients, where some code do run on the client, but is always related to the UI. In a client-server application, your app's logic should always run on the server.

I've worked on desktop client-server apps where the application logic was on the client and the server was mainly the database. It works, but you might end with clients with different versions trying to access the DB and you don't want that.

That's what server validation means. You should never trust clients. You shouldn't build a web app, which is a client-server app, entirely on the client. It's like reverse best practices. It will bite you.

Regarding having something else than sql, how much effort would be necessary to build a graphql server library that abstracts whatever you have on the server? Would you build something and release it to your clients with that level of maturity? And for what?