Prisma1: Field resolver functions

[schickling]

Computed fields allow you to extend a model's schema by executing functions to calculate the value of the field for every request.

[marktani]

Another use case are computed nodes.

[zth]

I'm building an app where you'll regularly answer forms. My use case will be calculating averages and scores for those forms on the fly for certain periods of time, without needing to fetch all the data on the client and calculate it there.

[marktani]

compute the millisecond representation of a DateTime field

This is useful for the Algolia integration as Algolia expects that format for times. But better handled by #91.

[wallslide]

I'd also find this functionality extremely useful. I can see needing to have parts of dates for different queries. The month, the day, day of week. It would be helpful if I could just add a new computed property when I need it rather than having to update my schema and go back and calculate the value for all nodes.

[tonyxiao]

This would be HUGE. Without it I find it to be hugely limiting to be using a hosted GraphQL service rather than just write my own GraphQL server. Effectively this is like being able to create my own resolver function right?

Here's my use case while trying to create a waitlist app. I want to create the following type

type Reservation {
  id: String!
  email: String!
  peopleAhead: Int!
  peopleBehind: Int!
  referralCode: String!
}

However peopleAhead and peopleBehind depends on how many ppl are there on the waitlist in total, which is not a stored field but rather computed field

[mattfysh]

Super useful. Also wondering whether you'd be applying a caching layer to the computed result? One that's invalidated in certain circumstances, e.g:

1 - function to compute value changes
2 - underlying source data changes

At this stage, a workaround might be to store the result statically against the object, and updating via server-side subscription. Will also need a dummy value that can be updated on the object which triggers a refresh of the computed value (and an external tool which batches up this process for all objects)

[kbrandwijk]

A lot of these use cases could actually be implemented using RP hooks, if you can calculate the values at the moment you're saving/updating a node.
The other usecases are clearly about querying, where the values cannot be calculated in advance. For these specific use cases, calculated fields would be a great option.

[mattfysh]

The use case I'm looking for is updating an average score e.g. on a Product based on all of its Reviews

[tristancaron]

Is there a workaround at the moment?

[vincenzo]

@tristancaron Was wondering that myself, but I suspect the only workaround at the moment is to implement your customer query using a resolver function. This, effectively, would be the logic you'd have implemented for the computed field. However, in this case, you'll have to make two requests, rather than a single one (which kind of defeats one of the main "pros" of GraphQL).

@marktani @kbrandwijk Any other way to work around this using a single request?

[marktani]

This issue has been moved to graphcool/graphcool-framework.