Everything about this API happens asynchronously. POSTS are batched up, and although most of this is hidden and shouldn't provide too much difficulty for the javasScript developer, some care needs to be taken. jQuery promises are used throughout and can be used to test completion of requested operations.
We'll use exactly the same data as was used in parse.com - nosql database for VBA, parse.com - noSQL database for GAS and the same database and Google Apps Script handlers as used by A VBA API for scriptDB. The term 'class' in these examples refers to a group of objects which are stored in a scriptDB against a particular siloID, and is somewhat similar to the parse.com definition of a class.
For our tests, we'll render all results in <div> elements in the testing web page using this simple function
Here's how to count how many objects of class 'VBAParseCustomers' are in the scriptDB described by the entry 'dbTest', and shows the result (or the error) on a web page element
This one show all objects for customers in the United States
See how the .getCount() and .getObjectsByQuery() function are executed asynchronously, and the results are only available for rendering when the the promise they return is resolved (or rejected).
Functions which POST data (as opposed to GETting data) are more complex. This is because POSTS are batched (when you execute a POST, the API might not actually execute that POST until there is more to do - this helps to avoid scriptDB rate limits. Note also that the Google Apps Script handler (which deals with requests for both this and A VBA API for scriptDB), also does its own batching. Finally, it can't be guaranteed that your requested POSTS happen in the order that you execute them, since that is the nature of asynchronous requests.
DELETE, UPDATE and CREATE are all POST type operations.
Here's an example of how you would do a POST type operation
At first this looks not much different the GET operation, and in fact will not be resolved until all the objects have actually been finally handled by the Script Apps handler as part of some future batch operation. However, when you are done with all POST operations , you need to execute a finalFlush(). Although flush() is executed from time to time as the queue of requests builds up, there will usually be a queue of some size to empty out. This ensures that any request which are still in the batch queue get executed. So your final operation needs to be
.finalFlush() follows .createObjects(), and .createObjects() will not be resolved until .finalFlush() is. This guarantees that any objects you have posted have indeed been completed. You can use the promise returned by .finalFlush() to know that there is nothing more to do. Note that different POST operations are dealt with in the same batch, so there is only a need for one finalFlush() per scriptdb object.
The following example copies a couple of classes from one scriptDb to another, and excercises all the concepts mentioned above.
There's a few things of note here