sangria-graphql/sangria

New middleware to limit visibility of schema elements

Offen

#417 geöffnet am 12.11.2018

Auf GitHub ansehen
 (0 Kommentare) (1 Reaktion) (0 zugewiesene Personen)Scala (219 Forks)batch import
featurehelp wanted

Repository-Metriken

Stars
 (1.961 Sterne)
PR-Merge-Metriken
 (Durchschn. Merge 8T 15h) (4 gemergte PRs in 30 T)

Beschreibung

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-Richtung
Studieren Sie den vorhandenen Middleware Mechanismus in Sangria und wie er in Validierung und Introspection integriert ist. Betrachten Sie die Implementierung von graphql ruby als Inspiration. Erwägen Sie, ein neues Konzept zu entwerfen, das das Schema kapselt und dessen Verhalten während der Ausführung, Koerzierung, Validierung und Introspection ändert. Definieren Sie zunächst ein Trait oder eine Klasse, das/die Typen, Felder, Argumente und Enum Werte basierend auf einer bereitgestellten Prädikatfunktion filtern kann. Integrieren Sie es dann in die Abfrageausführungspipeline und die Introspection Antwort.
Tech Stack
scala
Domain
apibackend
Issue Type
Funktion
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-2 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
GitGraphQLScala
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
65