Override "__" fields from schema

[michaelkschmidt]

@benwilson512 here is the PR we talked about yesterday. Please let me know if you wanted it done a different way

I'm still figuring out how to add fields via the pipeline stuff. I intended to add them to the unit tests here too

[benwilson512]

Hey! Thanks for taking a shot at this. I don't think I articulated the route I want to go super well though. What I'd like to get to is, for all intents and purposes, not really having introspection fields at all. The idea would be that one of the schema building phases would just go to every object and add a __typename field or a __field field.

There's still a schema validation rule which says that you can't name fields starting with __ but we would basically just flag those fields with some kind of override that the validation phase looks for and could ignore. If you want to add custom "introspection" fields you can just add a field as normal and supply the override.

The built in introspection resolvers would of course exclude these introspection fields from introspection results.

As far as extending objects and fields I should have directed you at the decorator feature @bruce has been working on: https://github.com/absinthe-graphql/absinthe/blob/master/test/absinthe/schema/notation/experimental/import_sdl_test.exs#L58-L81

At the moment the only decorators that are merged in are for resolvers but I think @bruce has a branch somewhere that lets you add fields. Let me update this shortly.

[michaelkschmidt]

ok--let me give that shot. I might ping you on Slack to confirm a few points

[michaelkschmidt]

@benwilson512 I managed to get the fields added, but I think I hit a major issue:

  fragment F0 on SearchResult {
    ...F1
    __typename
  }

Don't work correctly on Unions, since they do not have fields

[michaelkschmidt]

@benwilson512 do you want the decorator phase updated to allow fields to be added then? I can add it as a PR to #649

[michaelkschmidt]

@benwilson512 I think I have the introspection fields working the way you describe. Do you want me to move the manipulation functions to be part of the decorator stuff? I can merge #649 into this branch and start adding if you want

[benwilson512]

Yes feel free to merge that branch in. I'll review what you've got here shortly.

[jessedijkstra]

Index the types by their name :)

[WolfDan]

Any updates on this? @michaelkschmidt @benwilson512

This decorator feature is exactly what I'm looking for my project, right now I'm changing all the blueprint inside a pipeline, but this feature solve most of my problems!

[michaelkschmidt]

@WolfDan Our need for this feature was to expose custom meta data to the introspection queries. Our final solution achieves this doing something like this

  def run(blueprint = %Blueprint{}, _) do
    ...

    blueprint =
      blueprint
      |> Blueprint.add_field("__Type", type_fields)
      |> Blueprint.add_field("__Field", field_fields)
      |> Blueprint.add_field("__EnumValue", enumval_fields)

    {:ok, blueprint}
  end

Originally we were going to expose using " _ _ " names, but we backed down to a single "_" prefix instead. This probably means " _ _ " fields isn't strictly necessary anymore, but I have not had time to go back and see if everything could be moved inside a library instead

@benwilson512 I am open for ideas on how to proceed with this. Do you still want override able introspection fields?

[WolfDan]

Oh I see @michaelkschmidt

My problem is more about deleting/adding/modifing fields based on SDL field decorators, which from what I've seen this PR does (somewhat what prisma.io does)

[benwilson512]

@michaelkschmidt this is really great work. There's a few things I want to tweak, so I'm gonna merge this into a feature branch on Absinthe itself and go from there.