That was a long way. Thx a lot to all who helped!
Is there a difference between a input being nullable and have a default value baked into to graphQL or Sangria. Never used one without the other, so getting used to things.
I have a lot of APIs I'm querying that supply defaults but don't take Options, so the derive macros turn this in non nulls in the introspection schema.
Seq[T] in mutations where the Argument's type is the product of the deriveInputObjectType macro on the top typeIt seems we have to wrap it in
Option and OptionType but that means a Option[Seq[T]] which is kind of a painIs there a better way that results in not having our API consumers pass empty arrays?
What do you do in Sangria if you want to provide some kind of validation like an argument must match a pattern or condition?
like if I'm
mutation updateFooStatus($fooId: FooId!, $status: String!) {
updateFooStatus(fooId: $fooId, status: $status)
}and status must be either "An Apple", "A Banana", "A Carrot"?
I can't make them enums because I need the the API to return "An Apple"
[warn] [E-1] an unexpected type representation reached the compiler backend while compiling GraphQLTypes.scala: (marginChar: Char): String <and> (): String. If possible, please file a bug on https://github.com/scala/bug/issues.
[error] [E-1] Error while emitting GraphQLTypes.scala
[error] (marginChar: Char): String <and> (): String (of class scala.reflect.internal.Types$OverloadedType)
[info] Legend: Ln = line n, Cn = column n, En = error n
[error] (Compile / compileIncremental) Compilation failed
[error] Total time: 3 s, completed Jul 14, 2020, 1:00:34 PM
:wave: Hi, Anyone knows how to properly embed objects in graphQL schema? I did not find anything in the documentation:
I have the following use-case:
case class Outer(a: String, embedded: Embedded)
case class Embedded(c: String, d: String)What I would like to achieve is that the fields c and d are accessible in the api directly from the outer object.
The only way I currently see to achieve this is to manually add these fields in the OuterType definition:
implicit val EmbeddedType = deriveObjectType[MyCtx, Embedded]()
implicit val OuterType = deriveObjectType[MyCtx, Outer](
AddFields(
Field("c", StringType, resolve = _.embedded.c),
Field("d", StringType, resolve = _.embedded.d)))The problem here is that this is not forward compatible if we add new fields to Embedded in the future.
@mesutyigit which version of Scala are you using? I just came up against this using Scala 2.13.3 and ended up converting my schema definitions to explicit definitions via ObjectType
ObjectType(
"Application",
() =>
fields[MasterRepo[F], Application](
Field(to get my code compiling again. We were fine until I started adding in the documentation via @GraphQLDescription()
JavaConversions changed between 2.12 and 2.13
@erikdstock I'm in the process of designing a new schema right now that's quite large. I've created a model package with several sub-packages for each collection of Type objects. Since we're using http4s, functional-streams for scala, and cats.effect for our code we've implemented everything as object with the apply method constructing the type
object ApplicationType {
def apply[F[_]: Effect]: ObjectType[MasterRepo[F], Application] = {
ObjectType(
"Application",
() =>
fields[MasterRepo[F], Application](
Field(
"appId",
StringType,
resolve = _.value.appId
)
)
)
}Most of the types are in their own files if they're only nested 1 level from the root schema item Application. For items I'm nesting down 2-3 levels and aren't shared with other types I've included them as implicit types at the top of the apply method.
Hope that helps
deriveObjectType[MasterRepo[F], Application] but once I started adding documentation to the classes with the Attributes a bug in Scala 2.13 was exposed in compile time reflection. Thus I went back to the old ObjectType approach.
Money case class that has been created specifically to define presentational logic for our money numbers, and the GraphQL MoneyType exists in the companion object. In other cases, we might have for example an object User might include a UserType even though the user model exists outside our graphql package. Does this make sense?https://gist.github.com/erikdstock/09dc318dfea84f5f4f307fc2a487aecd
implicit vals the fieldsFn argument and so forth. It seems like no matter what I end up with a no implicit arguments found of type ValidOutType[...] on one specific enum type and some compile-time errors in at least one other case where it looks like i have defined the implicit val one line above its use - with no negative feedback from intellij.
implicit val ec: ExecutionContextExecutor], so I cannot easily mix them into each other
derive_Type is failing somewhere that I can't see due to macros, frequent use of both def & implicit val UserType: ObjectType[RequestServices, UserId]. In the validOutType case above that is also referring to a deriveEnumType (also defined in the same file) whose base trait is implemented entirely by case objects... Though i have to say, at this point this all is starting to feel like noisy word salad
enumeratum which I used to get my Enum working with Circeimport enumeratum._
import sangria.macros.derive._
import sangria.schema._
sealed trait Platform extends EnumEntry
case object Platform extends CirceEnum[Platform] with Enum[Platform] {
case object Android extends Platform
case object iOS extends Platform
val values: IndexedSeq[Platform] = findValues
}