I’m glad to hear that there will be some work to support this.
After some initial excitement of some real magic I thought we could achieve, I tried to build something useful this past week, but I have found it pretty limiting to not be able to pass args. Its like writing functions with no parameters.
Instead of @lambda fields being this magically flexible field, it limits it to being pretty much a single function field, and any variable requires a duplicate field to handle that slightly different scenario.
Some simple things I was attempting:
- prevent inadvertant calls to an expensive API (by requiring args before it ran)
- limit fields fetched through variables (each data piece in said API has a cost, so be able to limit which fields were fetched dependent on variables)
- String manipulation with various methods through a lambda.
- Trim a string to a variable length
- Change a string case to a variable case
- Use a database stored template string to and process replace with variables.
- Use a client provided template string and process replace with database fields.
- Do complex math operations dependent on variables using the field value.
- Format date fields per user’s supplied variable using a field from the database.
- Use fields as database side logic (e.g. Is my supplied variable in the range for a certain field: boolean)
This list could go on for so many different use cases that this is just the starting point. This truly allows an almost endless flexibility to a lambda resolver which helps to reduce the lambda resolver script size because now fewer resolvers can do more things instead of needing a dozen or more resolvers for just a few cases and each resolver then needs to map to its own field, which not only clutters the lambda resolver, but now also the GraphQL schema.