rate limiting?

[dezren39]

how would one handle rate-limiting? i'd like to allow almost anyone to execute small wasm functions. i can imagine timeouts pretty easily, but it'd be nice to be able to segment memory or cpu maximums too. i could also see minimal ip/request rate limiting. i could find ways to load balance computers around raptor but it might be nice to be built-in. one could also consider queueing/scheduling but that is maybe more complicated. it may end up being more about detailed metrics or controls to allow app-specific monitoring and orchestrating by library consumers. i'm glad this is written in go and hollywood is very interesting to me. will go have an 'go sdk' or would go users use the raptor code base almost directly? a bit of both?

[anthdm]

I'm already have some ideas in mind for rate-limiting, those will come soon. Regarding the SDK. Eventually the Golang SDK will be in a different package, users can import. Basically, every language will have its own SDK.

[dezren39]

that sounds great! will i be able to import raptor and start the server from within my go module? (in certain scenarios, i would like to ship one, very large, executable, with some config files)

[anthdm]

I think I put everything in the internal folder. I will make sure those packages are importable.