I plan to use AWS lambda + API gateway to act as middleman between my JS client and my devices.
Instead of directly calling particle.callFunction on my customer facing website I will make an http request to Lambda that, in turn, will invoke the function.
However, I’ve found that some of my functions take some time to complete and as such I have to leave my lambda timeout very high to avoid it returning a failing status code.
Much better, for me, would be to submit my operations to a queue, get a 201 and move on. I could do this myself (by using AWS SQS to buffer my requests) but was wondering if there is a better way?
If you are refering to Particle.function()s when talking about “device functions” then you should keep them as short as possible anyway.
Best practice would be to just receive the command string, store it, set a flag and leave the heavy lifting to the main loop.
Does the platform make any guarantees about the order that function calls submitted to the REST api are sent to the device?
Is there any documentation that shows the interaction between the loop and recieved function requests? Specifically I’m interested to know what happens to multiple requests recieved while the loop is busy doing other stuff.
AFAIK is the order of function calls not guaranteed.
Without SYSTEM_THREAD(ENABLED) function calls are serviced one at a time per visit to the cloud house keeping routines (dropping out of loop(), explicitly calling Particle.process() or on every accumulated 1000ms of delay() time).