> the natural assumption would have been that ActiveRecord model classes should double as GraphQL result objects, and there would be a nice DSL for specifying how to safely expose those objects to the API.
GraphQL-Ruby Types _is_ that DSL. You specify what fields can be exposed to the world and this is also the place where you can hide too low-level specifics (e.g. join separate `amount` and `price` columns into specific `Money` type). Then you pass AR object to GraphQL-ruby and it does what you said in DSL.
> have created a completely parallel schema - new classes for every object in the GraphQL graph, which are analogous but separate from the Rails models, each one acting like a combination of controller and presenter
And IMO this is good. Now you have dedicated place (namely `app/graphql` folder) for API-specific data mapping and validations. And in general GraphQL-Ruby gently pushes you to decouple your API from your database schema so you will be able to refactor and optimize things under your application hood later.
+1 on this. GraphQL is a great way to actually decouple your API from underlying database schema. When you start thinking not about specific REST endpoints, but about API data model in general, it turns out that it is much better to hide many database-level specifics and provide more natural data model to clients.
But you're still actually getting that data from somewhere (maybe even several places). You absolutely have to consider deeply the performance characteristics of complicated operations across these datastores to be able to deliver a sane API. There's only so much you can hide when you allow arbitrary joins and filters etc.
It is⦠burlesque!