I know, and in front-end they are great, I was talking about this implementation from back-end point of view in Scala.

This implementation requires one to write schema, that is in many ways (maybe fully) identical to your database schema e.g. Slick schema thus you have to write it twice. It would be a better to infer the GraphQL schema from Slick/database schema.

In practice, it's actually pretty rare for a GraphQL schema (exposed to clients) to be identical to a database schema which often has admin-only columns or database-specific idiosyncrasies like SQL join tables that you would opt to expose differently to a client.

That being said, there's a lot of low hanging fruit for building a GraphQL schema "generator" libraries for various backing databases - while some things are likely to change, it's quite nice to just apply those edits rather than building up a near-parallel schema again.

For me, one of the best features of GraphQL is that you're able to completely hide/abstract away non-domain-models such as join tables.