Investigate automatic input and output schema detection in attach-query and attach-mutation

[acron0]

It's theoretically possible to discern the schemas from the fdef (if one exists) rather than have the user supply schema.

For example, instead of (attach-query ::input ::output handler) you could just do (attach-query handler) and the function would find an fdef associated with handler, detect the :args and :ret (thanks @devurandom) and use these in place of input and output specs.

This is just sugar, really, but might help with onboarding

[devurandom]

There is s/get-spec to retrieve the spec of a fully qualified symbol. It should contain :args and :ret keys.

[workshub]

@tolgraven started working on this issue via WorksHub.

[workshub]

A user started working on this issue via WorksHub.

[workshub]

A user started working on this issue via WorksHub.

[workshub]

If you successfully complete this Issue via WorskHub there's a $25 reward available.
Start work via WorksHub Issue Details page.

[benjamin-asdf]

Challenge

Investigated this and there is a challenge:
When you s/def, you provide a sequence-spec for the arglist. So it is not
simplistic to "get" the query spec (the second arg). The spec might be
a function at this point.

If users would always fdef using s/cat we might able to
extract the spec but now we are making more assumptions than we
should imo.

Another constraint we impose on the user is that their sepcs must be
keywords, not functions. Unless ::query-spec can be allowed to be function.

#40 Makes an erronous assumption in my analysis. The :args spec
would be for a list [ctx query value], but we would want to extract
the spec for query or the 2nd arg specifically.

So in my opinion we would not be able to provide this sugar in a way
that still is simple. We are better of taking the spec as param.

I asked on slack and Alex Miller said there is currently not really a
good way to get an arg spec like that. https://clojurians.slack.com/archives/C1B1BB2Q3/p1674644797222099

Alternative:

There would be an alternative maybe in conjunction with #11 to check
metadata on the resolver-fn.

We could then have something like:

(defn
  ^{:leona/query-spec ::test/driod-query
    :leona/results-spec ::test/droid}
  droid-resolver
  [ctx query value])

This would be trivial to implement and I suppose nice for users that
have a resolver function using the same specs in a lot of places.

[acron0]

I do like the metadata approach. I wish this had been used more in the original design of Leona as well.