title: GraphQL SDL enum types
body: <p>We have a bunch of enum types defined in an SDL and they work great for queries and mutations. 
  In the resolvers section these are mapped to the strings which represent those enums in the back end.</p>
  
  <p>For example in the SDL we have :</p>
  
  <pre><code>enum WRRole {
      USER
      PROVIDER
      SUPPORT
      ADMIN
      SUPER_ADMIN
      GUEST
  }
  </code></pre>
  
  <p>And in the resolvers section we have :</p>
  
  <pre><code>WRRole: {
     USER: 'user',
     PROVIDER: 'provider',
     SUPPORT: 'support',
     ADMIN: 'admin',
     SUPER_ADMIN: 'super admin',
     GUEST: 'guest'
  },
  </code></pre>
  
  <p>The resolvers match the enum values defined in the nodejs backend using Mongoose where the field is defined as :</p>
  
  <pre><code>...
  roles: {
    type: [
      {
        type: String,
        enum: ['user', 'provider', 'support', 'admin', 'super admin', 'guest']
      }
    ],
    default: ['user']
  },
  ...
  </code></pre>
  
  <p>The issue we have with GraphQL enums is that we cannot introspect the enums and get back the mappings using GraphQL introspection....</p>
  
  <p>This causes issues with constructing UI's where we want to present the user with a dropdown list of these as options. The SDL enum values such as SUPER_USER are great for the keys but we want to display the actual backend mapped value to the use to select from. </p>
  
  <p>This is just one example of many enums we have. Many of the mapped values consist of multiple words that have spaces between or words containing characters not allowed in the SDL enum value such as "super admin" in this case.</p>
  
  <p>So my question is... How are you all handling stuff like this without having to repeat yourself or add more code to the front end to map these to more useful meaningful names for presentation ????</p>
  
  <p>The order cannot be guaranteed to match the defined order of the enums in the backend so adding to the backend model enums would seriously mess up any assumptions that SUPER_USER actually maps to "super user" even though the resolver knows this.</p>
  
  <p>Regards</p>
  
  <p>Steve</p>