Deprecate decoding using atoms

[c0m3tx]

Updated Client.call function, which now also accepts a decoder (just before options). Decoder is just a function with arity 1 which accepts a body and returns a tuple {:ok, decoded_body} or {:error, any}. Since the arity of the call function has changed, I also created a (deprecated) function with the old arity which fallbacks to atoms keeping the current behavior intact.

Updated the BridgeEx.Graphql macro, which now accepts the decoder too, and prints a warning when it's not provided (since it falls back to atom decoding).

Also provided three basic decoders in the Utils module (to decode keys in strings, atoms and existing_atoms) which simply mirror Jason behavior. This approach allows lib users to define their own decode functions which may be useful for some applications.

[cpiemontese]

Nice job 😄 I don't know if someone has anything else to say

[Fs00]

Overall the approach is good, I'd change a couple of things:

• I would rename the decoder param to decode_keys everywhere, to be more consistent with the naming of encode_variables and format_variables
• I would personally restrict the decode_keys option to just :atoms and :strings, because:
  • I don't think the behavior of the existing_atoms is something desirable (throwing an error doesn't look very robust)
  • I feel that providing a custom decoder function is a bit out of scope for the goal in the Roadmap and I don't see any use-cases for that

[c0m3tx]

:existing_atoms may be useful when you have to strictly check the validity of what you get in response. Raising an error is not always something undesired, you can optionally catch the exception and behave accordingly. It's just "another option" which doesn't hurt IMHO.

As for the custom decoder, I think it's worthwhile since it would allow decoding non-json endpoints like, for instance, gRPC (or XML 😱). Having custom decoders is almost "zero effort" on this lib side, and allows more flexibility on the user side.

[Fs00]

:existing_atoms may be useful when you have to strictly check the validity of what you get in response.

Ok, you convinced me 😄

it would allow decoding non-json endpoints like, for instance, gRPC (or XML 😱)

Non-JSON endpoints are not supported by the library (since it's fully committed to GraphQL) and won't be for the foreseeable future.
In general, I prefer to keep the API surface as small and focused as possible for simplicity and to avoid potential pitfalls. In this particular case I see that the behavior of a custom decoder may overlap with the format_response option, which already massages the response keys.
I think it's better to avoid dealing with the interaction (or potential conflicts) between these two options 🙂

[c0m3tx]

may overlap with the format_response option, which already massages the response keys. I think it's better to avoid dealing with the interaction (or potential conflicts) between these two options slightly_smiling_face

Ah yes, I didn't consider it at all! Ok you convinced me this time 😄

[Fs00]

I've proposed a few nitpicks/improvements to the documentation, the rest is already looking good

[Fs00]

I've pushed a small fix for an unrelated typo that screwed up the documentation on HexDocs.
LGTM!

[cpiemontese]

Nice 🎉