Skip to content
This repository has been archived by the owner on Jul 25, 2024. It is now read-only.

Support string fields and args #106

Open
sntran opened this issue Oct 3, 2016 · 3 comments
Open

Support string fields and args #106

sntran opened this issue Oct 3, 2016 · 3 comments

Comments

@sntran
Copy link

sntran commented Oct 3, 2016

At the moment, the fields key in %GraphQL.Type.ObjectType{} and args key only take a map with atom keys. For example:

%GraphQL.Schema{
  query: %GraphQL.Type.ObjectType{
    name: "RootQueryType", 
    fields: %{
      greeting: %{
        type: %GraphQL.Type.String{},
        args: %{
          name: %{type: %GraphQL.Type.String{}, description: "The name of who you'd like to greet."}
        },
        resolve: fn(_,_,_) -> "Hello" end
      }
    }
  }
}

However, there are cases where those fields are generated from user's input. By using atoms, we can run out of atoms in the Erlang shell, since atoms are not garbage collected.

It would be ideal to also support this:

%GraphQL.Schema{
  query: %GraphQL.Type.ObjectType{
    name: "RootQueryType", 
    fields: %{
      "greeting" => %{
        type: %GraphQL.Type.String{},
        args: %{
          "name" => %{type: %GraphQL.Type.String{}, description: "The name of who you'd like to greet."}
        },
        resolve: fn(_,_,_) -> "Hello" end
      }
    }
  }
}
@sntran sntran changed the title Support string field Support string fields and args Oct 3, 2016
@aweiker
Copy link
Member

aweiker commented Oct 3, 2016

I've never seen anyone allow a user to define a schema outside of compile time.

Can you expand on your use case more as to what you are trying to do?

@sntran
Copy link
Author

sntran commented Oct 3, 2016

Yes, I explained it in another issue here: #15 (comment)

Basically, I am providing a framework for generic backend, in which the schema is loaded and updated in run time. The schema is defined by user.

@sntran
Copy link
Author

sntran commented Nov 17, 2016

I'm not trying to rush here, but I would like to hear the arguments against this. I can see that the dot notation when using atom is nicer than square brackets, but other than that, I see no harm in supporting both.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants