Also, I've found it much harder to modify functionality because now your business logic is embedded in your DB which is harder to version than backend code.
In any event, if you want a GraphQL/DB API and don't want to pay for graph.cool, there's a great similar tool called PostGraphile: https://www.graphile.org/
I would say that the tooling is lacking in this area but there is no big underlying obstacle that would prevent you from working with code in the database the same as with code in other envs. For PostgreSQL in particular, a combination of Sqitch and Apgdiff works quite nicely. I've combined them for a particular project structure (https://github.com/subzerocloud/subzero-cli) but this approach can be generalised. I have all my database code (including table definitions) in separate files/folders, split however i want (modules), work on them in any oder i need, when the time comes to deploy, apgdiff does the diffing between live and dev versions of the database, creates the new migrations DDLs automatically, and than those migration files are managed by sqitch and deployed.
https://github.com/begriffs/postgrest
If you need GraphQL and standard PostgREST endpoints (as well as a few other tools like Openresty), this starter kit is really nice and fires right up with docker-compose:
Postgraphile is a pretty cool project that was on hn yesterday actually https://news.ycombinator.com/item?id=16150663
PostGraphile and Prisma takes different approaches in that PostGraphile embraces the power of PostgreSQL and encourages you to place business logic in the database.
Prisma on the other hand is a separate piece of infrastructure that you deploy in front of a database to add extra functionality such as realtime subscriptions, rate limiting etc.
If you haven't checked it out yet, then I'd encourage you to take a look at GraphQL bindings and how that allows you to work with your own server for more complex scenarios: https://blog.graph.cool/reusing-composing-graphql-apis-with-...
The switch from REST to GraphQL moves the burden of data fetching from client to server. As GraphQL is dynamic in nature you have to handle any query the frontend might send and can no longer rely on the static shape of a REST API when optimising your data access pattern.
The fundamental issue is that there is a big gap between the GraphQL API you want to expose and the underlying data layer you have available. Sometimes you need to combine data from several underlying databases making it critically important to perform data queries in the right order and in parallel when possible.
Think of Prisma as a GraphQL database query engine that analyses every incoming query in order to generate an optimal execution plan for your underlying databases.
As to your comment, nothing is black and white, but if the logic operates strictly on the data (not interfacing with 3rd party systems), having it in the db imo is better/less complex.