Description
Summary
It's rare that the standard CRUD ops generated by schema introspection will cover our needs. Mutations exposing stored procedures would enable us to write exactly the business logic we need with access to all of our data wrapped up in a PostgreSQL function.
Rationale
For most real world apps, frontend devs will not know how to write GraphQL mutations that insert or update data. For example, my own app (e-commerce, currently still on Firebase, but soon hopefully on Supabase...) uses 100s of cloud functions such as "createTangibleProduct" or "grantWritePrivilegeOnProductToUser", which give frontend devs a defined set of arguments they can specify to create a new product or grant specific rights to specific users. Such functions check and update multiple tables (collections) in a single transaction. This would be very hard and error prone to do with CRUD ops on the frontend.
Design
The solution is to write SQL and PLPGSQL functions that ask for well defined arguments to handle all the complexity and are then exposed via GraphQL to clients.
Examples
Drawbacks
I don't see any.
Alternatives
Functions are already exposed by Postgrest. But this requires working with two interfaces and generating two sets of Typescript types (openapi-typescript and graphql-codegen). It would be much cleaner and more efficient to work only with the widely used GraphQL standard.