<!--

Precheck

Thank you for submitting a pull request! Absinthe is a large project, and we really appreciate your help improving it.

Please keep the following in mind as you submit your code; it will help us review, discuss, and merge your PR as quickly as possible.

• Tests are good! Please include them if possible.
• Documentation is good:
  • Modules should have a @moduledoc (may be false)
  • Public functions should have a @doc (may be false)
  • Consider checking /guides for documentation that needs to be updated
• Specifications are good. Include @spec when possible.
• Good Git history behavior is good. Don't rebase your PR branch, and make small, focused commits. We generally squash commits on merge for you, unless there is a reason not to (multiple committers on a PR, etc).
• Matching existing code style is good.

We're happy to work with you, providing guidance and assistance where we can, collaborating with you to help your contribution become part of Absinthe. Thanks again!

As always, feel free to reach out for questions/discussion via:

• Our Slack channel (#absinthe-graphql): https://elixir-slackin.herokuapp.com
• The Elixir Forum: https://elixirforum.com

-->

Apollo federation is not built in, but I don't see anything standing in the way of someone writing a library that enabled it on top of Absinthe. At this point Absinthe has exposed 100% complete control over how schemas are built, when schemas are built, and how queries are executed.

So is it not possible to leverage Apollo Federation while also using Absinthe Elixir ?

Mesh should, at least in principle, be able to add a Federation implementation to an existing nonconforming schema: https://www.graphql-mesh.com/docs/transforms/federation via https://github.com/0xR/graphql-transform-federation

@d-led Schema stitching and federation are not the same though

Each system has a unique strategy for combining sub-services:

- Federation services are aware of each other’s data while the gateway is a generic agent that combines them. The gateway configures itself by reading SDLs from each service, and may be reloaded on the fly with new SDLs.

- Stitching services remain unaware of each other while the gateway loads and combines their schemas. Recent development has added SDL annotations that allow stitched schemas to also be reloaded on the fly.

So is it not possible to leverage Apollo Federation while also using Absinthe Elixir ?

If submitting a bug, please provide the following:

Environment

• Elixir version (elixir -v):

Erlang/OTP 23 [erts-11.2] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [hipe]

Elixir 1.11.4 (compiled with Erlang/OTP 23)

• Absinthe version (mix deps | grep absinthe): 1.6.3
• Client Framework and version (Relay, Apollo, etc): Not relevant as it's a backend bug

Expected behavior

Define an enum type with the shorthand syntax:

enum :example_type, values: [:A, :B, :C]

In the schema, have a field with default value: arg :example, :example_type, default_value: :A.

It should work as expected.

Actual behavior

A compilation error is thrown:

(ArgumentError) you attempted to apply :value on [:A, :B, :C]. If you are using apply/3, make sure the module is an atom. If you are using the dot syntax, such as map.field or module.function(), make sure the left side of the dot is an atom or a map
    :erlang.apply([:A, :B, :C], :value, [])
Stacktrace:
  │ (absinthe 1.6.3) lib/absinthe/phase/schema/validation/default_enum_value_present.ex:33: anonymous fn/1 in Absinthe.Phase.Schema.Validation.DefaultEnumValuePresent.validate_defaults/2
  │ (elixir 1.11.4) lib/enum.ex:1411: Enum."-map/2-lists^map/1-0-"/2
  │ (absinthe 1.6.3) lib/absinthe/phase/schema/validation/default_enum_value_present.ex:33: Absinthe.Phase.Schema.Validation.DefaultEnumValuePresent.validate_defaults/2
  │ (absinthe 1.6.3) lib/absinthe/blueprint/transform.ex:16: anonymous fn/3 in Absinthe.Blueprint.Transform.prewalk/2
  │ (absinthe 1.6.3) lib/absinthe/blueprint/transform.ex:109: Absinthe.Blueprint.Transform.walk/4
  │ (elixir 1.11.4) lib/enum.ex:1533: Enum."-map_reduce/3-lists^mapfoldl/2-0-"/3
  │ (absinthe 1.6.3) lib/absinthe/blueprint/transform.ex:145: anonymous

I had to change the definition of the enum type like this:

  enum :example_type do
    value :A
    value :B
    value :C
  end

for it to work, even though it seems that they should mean the exact same thing.

The test cases look largely correct to me now, I'll review in more detail later this week. I think supporting it this way in Absinthe is important since it needed changes to key files.

If submitting a bug, please provide the following:

Environment

• Elixir version (elixir -v): Elixir 1.11.4 (compiled with Erlang/OTP 23)
• Absinthe version (mix deps | grep absinthe): absinthe 1.6.4
• Client Framework and version (Relay, Apollo, etc): n/a

Expected behavior

When defining a schema with a higher-order interface, for example, interface Mammal implements interface Animal, and object type Dog implements Mammal (and therefore Dog transitively implements Animal)...

I expect compilation of object types in that schema to enforce the interface transitivity requirement of the GraphQL spec:

Transitively implemented interfaces (interfaces implemented by the interface that is being implemented) must also be defined on an implementing type or interface. For example, Image cannot implement Resource without also implementing Node

Actual behavior

However, when defining an absinthe schema such as this Dog/Mammal/Animal example, if I only explicitly implement Mammal on Dog, I do not get a compilation error about the missing Animal interface declaration, and instead, I get runtime errors when resolving queries that spread on the various types. Here is an example.

My test schema:

defmodule AbsintheTestSchema do
  use Absinthe.Schema

  interface :animal do
    field :name, :string
    field :leg_count, :integer
    resolve_type fn
      %{breed: _}, _ -> :dog
      _, _ -> nil
    end
  end

  interface :mammal do
    interface :animal
    field :name, :string
    field :leg_count, :integer
    field :has_fur, :boolean

    resolve_type fn
      %{breed: _}, _ -> :dog
      _, _ -> nil
    end
  end

  object :dog do
    interface :mammal
    field :breed, :string
    field :name, :string
    field :leg_count, :integer
    field :has_fur, :boolean
  end

  query do
    field :my_animal, :animal do
      resolve fn _, _ ->
         {:ok, %{name: "Ponyo", leg_count: 4, has_fur: true, breed: "pitbull" }}
      end
    end
  end
end

Then I hop into iex with this test project, and define this query string:

{
  myAnimal {
    name
    ... on Mammal {
      hasFur
    }
    ... on Dog {
      breed
    }
  }
}

Passing that query string into Absinthe.run(AbsintheTestSchema) gives me these resolution errors:

{:ok,
 %{
   errors: [
     %{
       locations: [%{column: 5, line: 4}],
       message: "Fragment spread has no type overlap with parent.\nParent possible types: [\"Mammal\"]\nSpread possible types: [\"Dog\"]\n"
     },
     %{
       locations: [%{column: 5, line: 7}],
       message: "Fragment spread has no type overlap with parent.\nParent possible types: [\"Mammal\"]\nSpread possible types: [\"Dog\"]\n"
     }
   ]
 }}

If I change the definition of :dog to explicitly implement both interfaces (interfaces [:mammal, :animal]), then recompile and run the same query, it works as expected, and gives me this result:

{:ok,
 %{
   data: %{
     "myAnimal" => %{"breed" => "pitbull", "hasFur" => true, "name" => "Ponyo"}
   }
 }}

In contrast, I tested this with graphql-js (given that it is a reference implementation of the GraphQL spec), and a similar schema does not pass the validation--it gives me this error, which I expect absinthe to give also:

{
  errors: [
    GraphQLError [Object]: Type Dog must implement Animal because it is implemented by Mammal.
        at SchemaValidationContext.reportError (/Users/epoley/node_modules/graphql/type/validate.js:86:19)
        at validateTypeImplementsAncestors (/Users/epoley/node_modules/graphql/type/validate.js:379:15)
        at validateInterfaces (/Users/epoley/node_modules/graphql/type/validate.js:293:5)
        at validateTypes (/Users/epoley/node_modules/graphql/type/validate.js:209:7)
        at validateSchema (/Users/epoley/node_modules/graphql/type/validate.js:52:3)
        at graphqlImpl (/Users/epoley/node_modules/graphql/graphql.js:79:62)
        at /Users/epoley/node_modules/graphql/graphql.js:28:59
        at new Promise (<anonymous>)
        at graphql (/Users/epoley/node_modules/graphql/graphql.js:26:10)
        at Object.<anonymous> (/Users/epoley/code/test_graphql_js/test.js:42:1) {
      locations: [Array]
    }
  ]
}

This was a surprise to me when I used higher-order interfaces in GraphQL for the first time in absinthe. My assumption (coming from other languages with higher-order protocols and interfaces) was that I'd only need to explicitly implement Mammal on Dog, which was how I wrote the erroneous code. It's fine that GraphQL specifies that transitivity must be explicitly defined on the object type, but it's confusing that Absinthe doesn't enforce this when validating a schema.

Relevant Schema/Middleware Code

(provided above)

If this is helpful, I’m happy to make the associated changes in the absinthe tutorial. They’d be almost entirely formatting changes, and very simple to make.

In practice, this builds the tutorial as an absinthe 1.6 project upon a fresh Phoenix 1.5.9 project generation, and formats the project with mix format. All the queries listed in the absinthe tutorial resolve as they ever did.

@benwilson512 In which direction should I continue?

Just ran into this, looks like the fix was also already contributed in another open PR (#7). If anyone else needs to work around this, I did so by adding the following config to my Mixfile:

dialyzer: [ignore_warnings: ".dialyzer_ignore.exs", plt_ignore_apps: [:ex_aws_sns]]

...and putting the following in .dialyzer_ignore.exs:

[
  # ignore warnings caused by :ex_aws_sns being excluded from the PLT
  ~r/Function ExAws\.SNS\..+ does not exist/
]

This effectively disables all the typespecs of ExAws.SNS functions, but I couldn't find a better way to do it without either ignoring the whole file where verify_message is used, or adding a large number of specific ignores for the cascade of "The pattern can never match the type" and "Function will never be called" caused by the incorrect spec.

You need to be patient. It doesn't help that your question contains lots of code sketches that aren't real Elixir code. If you make things more concrete and real it helpful to people.

@benwilson512 I've already asked same question in elixirforum https://elixirforum.com/t/return-response-fields-based-on-the-context-using-dataloader/40162. But, I didn't get any solution. That's why I asked here. Can you help me with this

Need to return response based on the context.

This is my schema.ex

object(:user) do
    field :name, :string
    field :dob, :string
    field :test_1, dataloader(Repo)
    field :test_2, dataloader(Repo)
    field :test_3, dataloader(Repo)
    field :test_4, dataloader(Repo)
    field :test_5, dataloader(Repo)
end

def plugins do
    [Absinthe.Middleware.Dataloader | Absinthe.Plugin.defaults()]
  end

  def context(ctx) do
    loader =
      Dataloader.new()
      |> Dataloader.add_source(Repo, Dataloader.Ecto.new(Repo))
  
    Map.put(ctx, :loader, loader)
end

If the get_user API was hit by logged in user(By context, I was validating that). I will to return all the fields. The dataloader will do loading the associations job for me.

%{
    name: "some name", 
    dob: "some dob", 
    test_1:  "some_test_1", 
    test_2: "some_test_2",
    test_3: "some_test_3",
    test_4: "some_test_4",
    test_5: "some_test_5"
}

If the same get_user API was hit by not logged user(Without token). I only want to return the “name” field from the backend!
%{
    name: "some name", 
    dob: nil, 
    test_1:  nil, 
    test_2: nil,
    test_3: nil,
    test_4: nil,
    test_5: nil
}

How can i achieve this with dataloader?. Dataloader try to load all the association every time(If that particular field was passed from the frontend).