CODEWITHSUNDEEP
graphqlfaunadb
noi.m
noi.m

Reputation: 3132

filter by Time in graphql (using faunaDB service)

My graphQL schema looks like this,

type Todo {
  name: String!
  created_at: Time
}

type Query {
  allTodos: [Todo!]!
  todosByCreatedAtFlag(created_at: Time!): [Todo!]!
}

This query works.

query {  
  todosByCreatedAtFlag(created_at: "2017-02-08T16:10:33Z") {
    data {
      _id
      name
      created_at
    }
  }
}

Could anyone point out how i can create greater than (or less than) Time query in graphql (using faunaDB).

Upvotes: 2

Views: 1032

Answers (1)

Brecht De Rooms
Brecht De Rooms

Reputation: 1822

GraphQL range queries are not supported (yet.. they're coming!)

FaunaDB does not provide range queries for their GraphQL out-of-the-box, we are working on these features.

.. but there is a workaround.

That doesn't mean though that it can't do range queries since range queries are supported in FQL and you can always 'escape' from GraphQL to FQL to implement more advanced queries by writing a User Defined Function (UDF).

.. using resolvers

By using the @resolver keyword in your schema you can implement GraphQL queries yourself by writing a User Defined Function in FaunaDB in FQL. There are some basic examples in the documentation bt I imagine you might need some help so I'll write you a simple example.

I added your schema and added two documents: enter image description here

First thing is that our schema will be extended with the resolver:

type Todo {
  name: String!
  created_at: Time
}

type Query {
  allTodos: [Todo!]!
  todosByCreatedAtFlag(created_at: Time!): [Todo!]!
  todosByCreatedRange(before: Time, after:Time): [Todo!]! @resolver
}

All this does is add a function for us to implement: enter image description here

Which if we call via GraphQL gives us exactly that Abort message we saw in the screenshot before since it has not been implemented yet. But we can see that the GraphQL statement actually calls the function.

enter image description here

.. UDF implementation

First thing we will do is add the parameter which is just writing a name as the first parameter of the lambda: enter image description here

Which also takes an array in case you need to pass multiple parameters (which I do in the resolver that I defined in the schema): enter image description here

We'll add an index to support our query. Values are for ranges (and for return values and sorting). We'll add created_at to range over it and also add ref since we'll need the return value to get the actual document behind the index. enter image description here

We could then start off by just writing a simple function (that won't work yet)

Query(
      Lambda(
        ["before", "after"],
        Paginate(
          Range(Match(Index("todosByCreatedAtRange")), Var("before"), Var("after"))
        )
      )
    )

and could test this by calling the function manually via the shell.

enter image description here

This indeed returns the two objects (range is inclusive). Of course, there is one problem with this, it does not return the data in the structure that GraphQL expects it so we'll get these strange errors: enter image description here

We can do two things now, either define a type in our Schema that fits these and/or we can adapt the data the returns. We'll do the latter and adapt our result to the expected [Todo!]! result to show you.

Step one, map over the result. The only thing we introduce here is the Map and the Lambda. We do not do anything special yet, we just return the reference instead of both the ts and the reference as an example.

Query(
  Lambda(
    ["before", "after"],
    Map(
      Paginate(
        Range(
          Match(Index("todosByCreatedAtRange")),
          Var("before"),
          Var("after")
        )
      ),
      Lambda(["created_at", "ref"], Var("ref"))
    )
  )
)

Calling it indeed shows that the function now only returns references. enter image description here

Let's get the actual documents. I know that FQL is verbose (and with good reasons, although it should become less verbose in the future) so I started adding comments to clarify things

Query(
  Lambda(
    ["before", "after"],
    Map(
      // This is just the query to get your range
      Paginate(
        Range(
          Match(Index("todosByCreatedAtRange")),
          Var("before"),
          Var("after")
        )
      ),
      
      // This is a function that will be executed on each result (with the help of Map)
      Lambda(["created_at", "ref"], 
        // We'll use Let to structure our queries ( allowing us to use varaibles )
        Let({ 
          todo: Get(Var("ref")) 
        }, 
        // And then we return something
        Var("todo")))
    )
  )
)

Our function now returns data.. woohoo! enter image description here

We still need to make sure this data is conforms to what GraphQL expects, and from the schema we can see that it expects a [Todo!]! (See docs tab) and a Todo looks like (see the schema tab):

type Todo {
  _id: ID!
  _ts: Long!
  name: String!
  created_at: Time
}

As you can also see from that docs tab is that 'non-resolver' queries are automatically changed to return TodoPages. The function we wrote so far actually return pages.

Option 1, change the schema and turn it into a paginated resolver.

We can fix this by adding the paginated: true option to the resolver. You will have to take into account for extra parameters that will be added to the resolver as explained here. I haven't tried that myself, so I'm not 100% certain how that would work. The advantage of a paginated resolve is that you can immediately take advantage of sane pagination in the GraphQL endpoint.

Option 2, turn it into a non-paginated result.

A paginated result is a result that looks as follows: { data: [ document1, document2, .. ], before: ... after: .. }

The result doesn't accept pages but an array so I'll change it and retrieve the data field:

enter image description here

And we have our result. enter image description here

The complete query looks as follows:

Query(
  Lambda(
    ["before", "after"],
    Select(
      ["data"],
      Map(
        Paginate(
          Range(
            Match(Index("todosByCreatedAtRange")),
            Var("before"),
            Var("after")
          )
        ),
        Lambda(
          ["created_at", "ref"],
          Let({ todo: Get(Var("ref")) }, Var("todo"))
        )
      )
    )
  )
)

Disclaimers

Once you go custom, pagination also becomes your responsibility (e.g. pass an extra parameter). You can't fetch relations out of the box anymore as you would normally do by just requesting the relations in the GraphQL body.

Some words on the benefits of UDFs and the hybrid of GraphQL/FQL

Before you shy away from FQL (and yes, we do have to add range queries and are working on that), here is some explanation on the UDF approach in general and why it makes sense to think about it anyway.

You will at a certain moment encounter things in GraphQL that are just impossible (complex conditional transactions, e.g. update document and update this other document only if some condition that results form the previous update is true). Users that use other GraphQL implementations typically solve this by writing a serverless function in case you have to implement advanced logic or transactions.

FaunaDB's answer to this is to use their User Defined Functions (UDFs). This is not a serverless function, it's a FaunaDB function implemented in FQL which might seem cumbersome at first but it's important to realize that it gives you the same benefits ( multi-region/strong consistency/scalability/free-tier/pay-as-you-go) that FaunaDB provides.

Upvotes: 8

Related Questions