sangria-graphql/sangria

New middleware to limit visibility of schema elements

Open

#417 opened on Nov 12, 2018

View on GitHub
 (0 comments) (1 reaction) (0 assignees)Scala (219 forks)batch import
featurehelp wanted

Repository metrics

Stars
 (1,961 stars)
PR merge metrics
 (Avg merge 8d 15h) (4 merged PRs in 30d)

Description

The idea is to provide a middleware that allows to hide specific fields and types based on arbitrary logic. There hidden parts of the schema should be unavailable:

  • During the execution
  • During input value coercion (it should be possible to hide input as well as output types)
  • During validation
  • In the introspection results

The validation might be tricky since it is not aware of the middleware right now. On the other had, if for example a field is hidden, GraphQL query that uses the field should produce a violation during the validation phase. So maybe this feature needs to implemented as a new concept in the library and not necessarily as a middleware.

It should be possible to "hide" following elements of the schema:

  • Type (input and output)
  • Field (input and output)
  • Argument
  • Enum value

This idea is inspired by "Limiting Visibility" feature in graphql-ruby:

http://graphql-ruby.org/schema/limiting_visibility.html

Contributor guide

Research direction
Study the existing middleware mechanism in Sangria and how it integrates with validation and introspection. Look at graphql ruby's implementation for inspiration. Consider designing a new concept that wraps the schema and modifies its behavior during execution, coercion, validation, and introspection. Start by defining a trait or class that can filter types, fields, arguments, and enum values based on a provided predicate function. Then integrate it into the query execution pipeline and introspection response.
Tech stack
scala
Domain
apibackend
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GitGraphQLScala
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
65