[icot]

It's not really necessary because as you say, there are other ways.

But it's useful if what you want to do is create a simple API to access your data. If your use case includes buildinga CRUD app, or API, you basically get that out of the box.

If you have several components/clients (in different languages) which need to access your database it allows you keep a common interface instead of having to work with different specific libraries/frameworks for each language.

(PostgREST user)

[ruslan_talpa]

The point is to allow untrusted clients (browser/mobile) to run (safe/predictable) queries against your database without the need for "backend/api" as a middle layer because nowadays most of the business logic is mostly on the frontend and it needs a way to get to the database.

It's not necessarily useful if you have trusted code running on your servers, it should just connect to the database. But if this works for you ... why not.

(At least that's how i think of it, others may use it in different ways)

[thedarkproject]

> nowadays most of the business logic is mostly on the frontend

This is a design flaw imho and should not be used as a reason to motivate the use of such projects. If your logic is in the frontend you should rather build a backend that captures the logic instead of just putting a rest layer on your DB and call it a day.

[denisw]

Unless you are writing an app that should also work offline. In this case, most of your logic _must_ be your frontend, and your backend is mostly a data repository for data backup and synchronization. In such a scenario, database-as-an-API seems to be exactly the right approach.