Returning futures (soy value providers) from custom functions and not have them evaluate lazily

[Johannes Nel]

Hi all,

This is a call for some advice and thoughts.

We create a few soy functions, one of which is at times fairly expensive. We would like to return a SoyValueProvider which we resolve later with a circuit breaker in from the start.

What we have found is that internally assigning data in a let is lazy. from our perspective we would prefer this being eager, but blocking the use of an assigned value until a future resolves.

Hoisting of these calls would also be ideal (so we can parallelize around it) - but I realise this has some pretty nasty implications.

Stefan Liebenberg has found a workaround we can use, which is taking those lazy calls and making them eager by forcing the data into a map early.

The points discussed above can be found here
https://github.com/geniussportsgroup/soy-async-rendering-spike

We would massively appreciate insight on different approaches we can take here.

Thanks in advance,

Johan

[Luke Sandberg]

the current design of how the async support works was based on two assumptions

1. futures would be passed into soy, rather than calculated as a side effect of rendering

2. it would be valuable to lazily evaluate lets in order to make progress before blocking on a potentially asynchronous input.

Obviously if you are calculating these async things as part of a soyfunction this doesn't really work.  We have talked internally about providing support for SoyFunctions to return SoyValueProviders to enable these kinds of usecases, but for this to work well we would need to change the SoyFunction api and we haven't been sure how useful this would be.

Finally, i should note, that the soy evaluation model doesn't actually guarantee that we call each soy function exactly once.  For this reason your soy functions should be idempotent and doing something like an httprequest from one could result in redundant work (without client side caching).

So for the time being i would recommend passing this data into the soy template as a parameter (or an $ij) rather than calculating it in a soy function.  

--

---
You received this message because you are subscribed to the Google Groups "Closure Templates Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-templates-...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Johannes Nel]

We can't pass the data in,the soy function call functions as a binding to a data query (think grqphql like) and our templates here all have the same signature - we allow consumers to upload them to our system. We do have a client side cache for these queries.

We will use the map hack to force immediate evaluation of our calls and get our parallelisation in that way.

Obviously I am biased but I would find a change of these functions to soyvalueprovider useful :)

Thanks,
Johan