Meta attributes are macro quoted?

[mmmries]

Environment

• Elixir version: Elixir 1.11.2 (compiled with Erlang/OTP 23)
• Absinthe version): 1.5.5
• Client Framework and version (Relay, Apollo, etc): None

Expected behavior

I can use maps, structs or other native data types in the meta attributes on a field

field :paddles, list_of(:paddle) do
  meta(:proxy_to, %{url: "http://localhost:9002/graphql"})
  ..
end

# Later in a resolver

def resolve(_source, _args, resolution) do
  resolution.definition.schema_node.private.meta.proxy_to # => %{url: "http://localhost:9002/graphql"}
end

Actual behavior

Only simple scalar types seem to work for meta attributes. From the example above when I end up getting in my resolver is

def resolve(_source, _args, resolution) do
  resolution.definition.schema_node.private.meta.proxy_to # => {:%{}, [line: 8], [url: "http://localhost:9001/api/graphql"]}
end

I think this is because the meta attribute has been quoted without being unquoted.

Relevant Schema/Middleware Code

I'm trying to pick up the torch of schema stitching and move it forward for the community.
After reading through some issues it seemed like there was a desire for a community project to add this type of functionality.
I learned what I could from open source examples and started it on trying to build something that was general enough to be re-usable by other teams https://github.com/SpiffInc/absinthe_compose.
I'm interested in tackling this problem because our team at Spiff is wanting to build individual services and provide a unified graphql interface. I would like to keep the unified interface as thin as possible and schema stitching seemed like a great approach.

As I played around with how to approach the problem I liked the idea of being able to mark certain parts of your schema with metadata and then have resolvers automatically create the downstream queries and pull the data back into the local schema. I'm hoping to support arbitrary extensibility by letting people do things like meta(:proxy_to, {MyClient, [token: some_secret]}) where they can specify a module and pass some "init_args" style configuration. This way they could be calling graphql over some other transport, or using a custom HTTP client etc.

#928 seems to have a similar request, but it sounded like there were reasons that the project wanted to keep support for a more limited set of data types that could be passed in the meta attributes? I'm happy to change direction on this.

[binaryseed]

Thanks, we're looking into this, it's a similar shaped issue as those we are dealing with in #1023.

At the moment, you could sidestep this by using Keyword Lists instead of Maps (since they are represented the same in AST and code)

[mmmries]

Thanks @binaryseed I'll start with keyword lists for now. I'm totally open to feedback as I get started with building. I appreciate the awesome work that has gone into Absinthe and what it has done for our community.

[kdawgwilk]

@mmmries I was also looking at doing something similar but taking the Apollo GraphQL Federated approach rather than schema stitching. Have you looked into this at all?
This requires implementing services to conform to this spec. I started up this OSS library (absinthe_federation) where I started looking into building dependency that you could include with absinthe to get a schema that conforms to the spec. Unfortunately, there are some missing features in absinthe to support this. I have tried to dive into absinthe to see how I can contribute these missing features but its a fairly large project and it will take me a while to get up-to-speed. Its great to see others excited about the possibilities of a service-oriented architecture built on top of elixir and absinthe with a unified graphql schema and gateway. Hopefully, we can get enough support to get the ball rolling so we can all benefit.

[mmmries]

@kdawgwilk I only looked into Apollo Federation a little bit. I liked the idea of trying to do this without any additional requirements on my schema.

I also checked into graphql-mesh which is a pretty cool project for stitching together APIs into a single graphql gateway. Currently my team is leaning toward graphql-mesh, but I would still love to help out and support the elixir community in having a tool native to our stack.

[benwilson512]

Fixed by #1226