Hi Jan - reading through your docs, this looks very promising as I hadn’t got as far as using the api gateway - I was just connecting to the internal Alexa service.
One thing I didn’t quite understand - you mention specifying a HANDLER as an env variable, but your example description doesn’t seem to show where that is set? Is it in the bootstrap file (also is that bootrap.sh or just simply bootstrap? And are there any file attributes to set on that file?). It strikes me that rather than using an env variable - why don’t you specify the handler class when you invoke the image as the last command line option? (That is what I did in my example - or is it faster to query an env variable? Personally I find it easier to see it more explicitly on the command line). I also notice you include NeoJson - did you need that? I found that the default Ston reader was more than adequate for reading the json that was sent over (and so it’s one less pre-req). I haven’t yet fully understood the runtime layer - is this simply a zip file with the vm + files and without the image? Previously I had to add all of that in the zip I uploaded for each function, but this sounds like it simplifies things a lot. Do you have a script you used to create that - I ask as I found that trimming down the size of that made a difference to load times for Alexa (eg there are lots of sound and graphics dll’s you can remove - which I have in my script, and possibley, I could add to what you have done). Equally, I also figured out the command line fu for uploading and registering your Lamba so it works in a ci - this might also be worthy of inclusion. Anyway, l’ll Give it a go and see how the results compare - it was surprisingly fast using the js shim - but this seems like a much better solution. Thanks for sharing - it’s an executing world. Tim Sent from my iPhone > On Fri, 28 Dec 2018, at 11:35 AM, Jan van de Sandt wrote: > Hi Tim, > > Yes, I read that you got Pharo working via the Javascript runtime. It should > now be much easier and faster. > > I still have to figure out the best way to create a deployment image. With > the new bootstrap/modular setup of Pharo 7 it should be possible to create a > lean-and-mean runtime image that can run in the cheapest 128MB max. ram > configuration. > > Jan. > > On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon <tim@testit.works> wrote: > Cool - I was using a JS shim and had asked AWS many times why they couldn’t > open it up wider... > > Now I’m back from my travels I’ll reincarnate my previous work and see how it > works with this. I was looking forward to doing more with Lambda, so this is > great timing. > > Tim > > Sent from my iPhone > >> On 27 Dec 2018, at 10:32, Jan van de Sandt <jvdsa...@gmail.com> wrote: >> Hi, >> >> Last month Amazon extended their serverless runtime platform AWS Lambda with >> support for custom runtimes. I created a Pharo Lambda Runtime so now we can >> implement Lambda functions in Smalltalk and easily deploy them on the Lambda >> platform. Lamba has quite a large "free-tier", more than enough to do some >> experiments and to host small applications for free. >> >> See the GitHub project for more details >> https://github.com/jvdsandt/pharo-aws-toolbox >> >> Cheers, >> Jan.
