Available Resolvers
| Query | Mutation | Field | |
|---|---|---|---|
| @lambda | ✓ | ✓ | ✓ |
| @custom http | ✓ | ✓ | ✓ |
| @custom dql | ✓ | ✗ | ✗ |
| @lambdaOnMutate | Web Hooks |
|---|---|
| pre | ✗ |
| post | ✓ |
Summary
- @custom - used on a custom field, or within the custom types Query and Mutation, resolves within your schema by custom dql or fetching an external http endpoint
- @lambda - used on a custom field, or within the custom types Query and Mutation, resolves within your own custom javascript function within the lambda namespace
- @lambdaOnMutate - used on any type itself with (add, update, or delete), and resolves within your own custom javascript function within the lambda namespace AFTER the mutation has completed
The way DGraph currently works by resolving filters, queries, and mutations with the custom directives is extremely complicated, and with the options to use subscriptions as well.
In a real app you really just need to use custom dql queries for nested filters and sorting by counts, as well as custom lambda mutations (@lambda on a Mutation type) for field validation and security (adds and updates). It is triple the work, but doable for a middle size app.
I doubt anyone has ever built secure large apps using DGraph’s current middleware. So, it really depends on your use case, but we hope to see a plan to get rid of the need for all lambdas and custom directives. If they add a few of these features (which unofficially it seems they’re leaning to do–still waiting on an game plan), you could make a middle-sized app a large app by the time they release these features.
Hope this helps,
J