Feature request: make `resolve` in schema optional and use query/mutation id as a default resolve

[kirillsalykin]

Based on example from the tutorial

{:objects
 {:BoardGame
  {:description "A physical or virtual board game."
   :fields
   {:id {:type (non-null ID)}
    :name {:type (non-null String)}
    :summary {:type String
              :description "A one-line summary of the game."}
    :description {:type String
                  :description "A long-form description of the game."}
    :min_players {:type Int
                  :description "The minimum number of players the game supports."}
    :max_players {:type Int
                  :description "The maximum number of players the game supports."}
    :play_time {:type Int
                :description "Play time, in minutes, for a typical game."}}}}

 :queries
 {:game_by_id
  {:type :BoardGame
   :description "Access a BoardGame by its unique id, if it exists."
   :args
   {:id {:type ID}}
   :resolve :query/game-by-id}}}

Instead of explicitly specifying resolve every time game_by_id can be used, because it is guaranteed to be uniq.
Based on type it should be expanded to queries/game_by_id or mutations/game_by_id of course.

What do you think?

Thanks.

[hlship]

Generally, each resolver only belongs in a single place in the overall schema. I think you are saying to have an automatic mapping from operation name to a function within a namespace. Feel free to add such a feature in your own code; it can attach functions to the :resolve key prior to invoking schema/compile.

In new code, I tend to use inject-resolvers rather than attach-resolvers, the sentiment is the same; by the time the execution reaches compile, the :resolve key has been provided. That's the advantage of a data-driven API.

[kirillsalykin]

Oh, it seems already be implemented in inject-resolvers

Alternately, the key may be of the format :queries/name (or :mutations/name or :subscriptions/name).

Thank you and sorry for noise.