If you are using a pool of executors (configurable semephore) for executing ‘natively’ that sounds ideal to me.
I’ve come to the conclusion that incoming requests should be concurrent anyways. Therefore it would be better to make the lambda thread safe and there would be no need for starting up goroutines and a limitation is not really needed. I’m creating a wasm instance for each namespace that has a lambda script stored now. This means I don’t have to check the schema.
however I would use golang plugin infrastructure
I honestly don’t remember any specifics anymore, but I also tried the golang plugin stuff in the past and it was a very unpleasant experience.
For now I’m implementing the lambda with wasm.
No matter the solution I’ve come up with another constraint - backwards compatibility.
- We should support Node for at least one more version to allow devs to switch technology. Or should Node support be kept indefinitely?
- DGraph Cloud allows to write resolvers within the UI. This would not really be possible with wasm as it needs to be compiled. Alternatively a simple upload button could be provided. This would also speak for keeping Node in addition to wasm.
How critical are such things seen by the core-dev team? How important is backward compatibility? Should we support both wasm and node? Who should I ask?