I am thinking defining relation might help ? But I am stuck on how to define relations in SDL based approach ?
Sorry if duplicate.
So if I understand correctly,
- we can't use DeferredResolver mechanism with SDL based approach?
- But DeferredResolver are much more efficient than SDL based directive or field resolver ?
- Also looks like we can't define Relations in SDL based approach ? I couldn't find much documentation on this.
I have requirement on schema first approach but just want to make sure on pros and cons.
Thanks in advance. Please help with clarifying these.
Hi,
We've been using Sangria to create our company's first GraphQL APIs. We're a Scala Functional programming shop so we like doing everything monadic. We're doing our first schema that does a large number of fetches from DynamoDB tables to realize the result schema and I'm trying to use the Fetcher type for each sub-table. This method expects a Future returned from the repository function while our is returning a higher-type of F[Seq[Software]]. Have others been using Functional types with the Fetchers and Resolver caches? Sample code block below
def softwareFetcher[F[_]: Effect] =
Fetcher((repo: MasterRepo[F], ids: Seq[String]) => repo.devicesRepo.softwareByDeviceGuids(ids))(HasId(_.deviceGuid))
6 replies
Correct me if I'm wrong, but...
I get the impression that https://github.com/sangria-graphql/sangria-akka-http-example is using https://github.com/graphql/graphql-playground and that the latter has been ended in favor of GraphiQL. graphql/graphql-playground#1143
I've incorporated GraphiQL into a Sangria server before using webjars. Is this something that needs to be done?
Following up on my previous question on union type, have made changes to return all possible types of union as a default case. But I wanted to add check based on the __typename requested for. I see in .js, objects are resolved based on the unique field name that each type has. Am looking for something equivalent in sangria.
__resolveType: obj => {
if (obj.reason) {
return "TimeoutError";
}
if (obj.field) {
return "ValidationError";
}
return null;
}
someUnionField or, better yet, split this into two distinct fields rather than 1 that is a union type. Am I understanding correctly?{
someUnionField {
... on UnionTypeA {
someFieldOfTypeA
}
... on UnionTypeB {
someFieldOfTypeB
}
}
}{
someUnionField {
... on UnionTypeA {
someFieldOfTypeA
}
}
I'm trying to setup access control in Sangria, basically I'm authenticating on client side through Auth0 and then make the query with the bearer as Authorization header, I then validate the token and retrieve the user's identity from the database (all this happens before call
Executor.execute), but so now that I have my user's identity and its roles, I don't really know what to do...I tried following Sangria's documentation (https://sangria-graphql.github.io/learn/#authentication-and-authorisation), however the part about that
SecureContext really confuses me.If my understanding is correct, I should first create a
SecureContext that holds an Option[Identity] defaulting to None, and update that context after I retrieved my user's Identity, and then perform my access control against that updated context.Sorry if my question sounds a little silly, but can someone confirm / correct my understanding of the process ?
Thank you !
I made good progress on my authorization middleware, but I have a few more questions.
So far I went with a middleware-based auth instead of a resolve-based auth.
However, this seem to cause issues for me for the following use case:
Let's assume I have a Book entity, that has a userId attached to it, and a user can only query his books, how can I ensure that the Identity I'm holding from the Bearer token is matching the Id given in the query ?
Since
beforeField has my Context as parameter, my guess is that I can check the arguments passed, as one of them would be my userId , but let's assume the argument I want to check varies from one query to another (like, not necessarily called 'Id', or 'userId'), is there a way to use Middleware-based authorization anyway, or should I use Resolve-based authorization ?Thank you !
I don't think it's middleware VS resolve-based auth. We are using both for example.
The middleware checks that we are logged in.
The middleware also checks permissions based on tags:
val permissions = ctx.field.tags.collect { case Permission(p) => p }
if (permissions.nonEmpty && !secureContext.hasPermissions(permissions))
throw GraphQLOAuthException(OAuthError.insufficientScope(permissions))And then, in some resolve functions, we also check the permissions:
resolve = (c: Context[SecureContext, Unit]) => {
if (!c.ctx.hasPermissions(....))
throw GraphQLOAuthException(OAuthError.insufficientScope)
case object JsonCoercionViolation extends ValueCoercionViolation("Not valid JSON")
implicit val JsonType: ScalarType[Any] = ScalarType[Any]("Json",
description = Some("Raw JSON value"),
coerceOutput = {
case (value: JsValue, c) => value
},
coerceUserInput = {
case v: String => Right(JsString(v))
case v: Boolean => Right(JsBoolean(v))
case v: Int => Right(JsNumber(v))
case v: Long => Right(JsNumber(v))
case v: Float => Right(JsNumber(v))
case v: Double => Right(JsNumber(v))
case v: BigInt => Right(JsNumber(BigDecimal(v)))
case v: BigDecimal => Right(JsNumber(v))
case v: JsValue => Right(v)
case _ => Left(JsonCoercionViolation)
},
coerceInput = {
case ast.StringValue(s, _, _, _, _) =>
Right(Json.parse(s))
case _ =>
Left(JsonCoercionViolation)
})I'm puzzled as to why this variables field in GraphQLHttpRequest has a type parameter (and thus why GraphQLHttpRequest itself does). It seems like this should just be represented as a Map[String,String], possibly empty.
case class GraphQLHttpRequest[T](
query: Option[String],
variables: Option[T],
operationName: Option[String])
How can we pass List[List[caseClass]] as argument ? When I am trying to do so, I am getting the following error: "spray.json.JsArray cannot be cast to scala.collection.Seq"
val fdsInputRequestFilter: InputObjectType[RequestFilter] = deriveInputObjectTypeRequestFilter
val requestFilter = Argument("filters", OptionInputType(ListInputType(ListInputType(fdsInputRequestFilter))))
Hi guys, thanks in advance for reading this. Does everyone know how to solve my problem?
I have a product data type in my code that looks like this:
final case class Choice(id: Int, name: String, option: ChoiceOption)
sealed trait ChoiceOption
object ChoiceOption {
final case class SingularChoiceOption(checked: Boolean) extends ChoiceOption
final case class MultipleChoiceOption(possibleValues: Seq[String], defaultValue: String) extends ChoiceOption
}I want to represent this code in sangria as an interface:
interface Choice {
id: Int!
name: String!
}
type SingularChoice implements Choice {
id: Int!
name: String!
checked: Boolean!
}
type MultipleChoiceOption implements Choice {
id: Int!
name: String!
possibleValues: [String!]!
defaultValue: String!
}but I don't want to write my code like this:
sealed trait Choice {
val id: Int
val name: String
}
final case class SingularChoiceOption(id: Int, name: String, checked: Boolean) extends Choice
final case class MultipleChoiceOption(id: Int, name: String, possibleValues: Seq[String], defaultValue: String) extends ChoiceI'm using InterfaceType for describing my Choice, but there're no constructors that resolve value as an interface subtype. In other words, I want to view product data type as a sum data type.
Does anyone know workarounds for this case? Thank you =).
1 reply
It's in a very raw state, still, but it now compiles and runs. :tada:
In developing a Sangria example, I'm having difficulty in demonstrating even the most basic use of an SDL-based schema materialization. I'm getting
sangria.schema.SchemaMaterializationException: Can't extract value for a field 'User.id': not a map-like value.when I use an SDL file containing
type User {
id: Long!
name: String!
person: Person!
}I find it odd that ScalaInputUnmarshaller.isMapNode()is true only for Maps, not for case classes, or that my User case class doesn't get treated like a map. Wondering whether there's some linkage in the Scala code that I need.
The examples that I see tend to define the schema in Scala code. That has worked for me, but it obfuscates the schema's design. So it seems a real shame to do it that way.
Anyway, just mentioning the error for now, in case someone else has seen it. I'll have a clean example of the failure published soon.
InputObjectType is used to represent a GraphQL type that can be used as an input, for example for an argument.People usually use that with a scala case class as it's convenient. But you can use it with a trait, that you have to instantiate yourself at some point.
But if you are using a trait, we may have different implementations in scala. In that case, it may be better to expose a GraphQL interface and some concrete types of it.
2 replies
The modularization is in progress: the AST and the parser are now in separated modules.
Thanks @performantdata for this!
We add deprecations in the v2 releases to make the upgrading path easier. Make sure to fix those deprecations before upgrading.
Feedback welcome!