Ich dachte die Evulationsmethoden wären über die Implements sauber modelliert?! Dementsprechend gäbe es garkeine Evaluationsmethoden mehr.

Das Problem ist, dass man keine Interfaces als Input-Types nutzen kann. Somit müsste man für jeden Typen eine eigene Mutation bereitstellen. Das bringt uns aber nichts, wenn wir z.B. in einem Vote alle Antworten gleichzeitig übermitteln wollen. Somit müssten wir jede Antwort einzeln übermitteln lassen oder einen Input-Type mit vielen "Nullable's" machen wo jeweils nur ein wert und ggf. der Typ mit angegeben wird.

Somit müssten wir jede Antwort einzeln übermitteln lassen oder einen Input-Type mit vielen "Nullable's" machen wo jeweils nur ein wert und ggf. der Typ mit angegeben wird.

Ja das ist wohl das kleinste übel. Auch wenn man dann die Valideirung wieder per business logic machen müsste. Dann würde ich aber die Antworten nicht genauer im Shaema spezifizieren, sonder die dann einfach als Object übergeben.

mutation(survey:"1000","answers:[{value:1},{ranking:["c","a","b"]}]")

Das Problem haben wir ja eh eigentlich nur, weil wir das ranking mit dabei haben. Ansonsten bestünde jede Antwort ja eh nur aus einem Wert,

Liegt nicht nur am Ranking. Die Antworten haben jeweils nen anderen Typen den sie benötigen wenn das mit den Interfaces so bleibt (codes = String, value = Float etc.). Und in Input-Types kann man ja keine verschiedenen Typen pro Key angeben und auch keine Objekte (nur andere Input-Types). Also wirst du da nichts machen können wie:
mutation("answers:[{value:1},{value:"Code"},{ranking:["c","a","b"]}]") etc.

Aber könnten für diesen Fall einen scalar Type definieren.

In most GraphQL service implementations, there is also a way to specify custom scalar types. For example, we could define a Date type:

scalar Date

Then it's up to our implementation to define how that type should be serialized, deserialized, and validated. For example, you could specify that the Date type should always be serialized into an integer timestamp, and your client should know to expect that format for any date fields.

Also z.B. ein Any.

Folgende Änderungen für das GraphQL Schema:

• Jede Question hat einen eigenen Input und Mutation
• Für Answer gibts einen allgemeinen Input mit Nullable's
• Userrechte werden nicht in GraphQL modelliert, da sie als ein internes Flag dargestellt werden

Ich habe eine neue Version des Schemas hochgeladen in dem alle Veränderungen der Architektur eingepflegt sind. Bei Unstimmigkeiten / Verbesserungsvorschlägen oder Fragen bitte bescheid geben.

Kommentar von Fabian: #24

• password bei user fehlt in database schema
• UserCreatePayload funktioniert nicht "out of the box -> Warum geau soll da ein token returned werden? Das ist doch für den admin oder? Ansonsten eher login.
• Ich habe _id in id umbenannt, da sonst nicht automatisch vergeben + keine unterschiedlichen Feldnamen zwischen database und api schema möglich
• Ähnlich mit createtAt und updatetAt -> Das muss überall gleich heißen, sonst fehler...
• Da sind noch viele inkonsistenzen wie bspw. creationDate?!

Ich schließe das jetzt hier, da die meisten Probleme je behoben sind. Bei weiteren Problemen bitte ein neues Issue öffnen.

Aktuell hat das Schema noch ein paar Schwächen:

• Like- und LikeDislikeQuestion
  • Als Rückgabetyp erhält man ImagePayload (like/dislikeicon), was einen Zwischenschritt über die Eigenschaft data notwendig macht
• ChoiceQuestion
  • Was für Werte darf die Eigenschaft Code haben?
  • Unterschied zwischen items und choices (Ähnliche Frage beim Regulator)?
• Images verfügen über creationDate und lastUpdate, was überflüssig ist
  • Hier sollten einige Parameter Nullable sein, damit wir diese bei der Rückgabe der Like / Dislike icons auslassen können

Bei "code" ist der Wert doch erstmal egal weil es ein String ist. Haben wir so gemacht damit der Code verschiedene Werte annehmen kann (z.B. 1 oder A usw.). Unterschied zwischen items und choices sehe ich auch erstmal nicht.

Im Schema steht folgendes:

""" Defines a question of type Like """
type LikeQuestion implements Question {

    """ Default Like-Icon """
    likeIcon : ImagePayload!
}

""" Defines the Payload for Image Data """
type ImagePayload {

    """ Defines the image data """
    data : ImageData!

    """ The URL an image can be downloaded from """
    url : String!
}

Daraus wird dann:

{
  /* question stuff */
  likeIcon: {
    data : { 
      // image daten
    },
    url: {
      // url
    }
  } 
}

Schöner wäre:

{
  /* question stuff */
  likeIcon: {
    // image daten
  } 
}