Schedule script block to run on periodically(on specific time everyday)

Do you think there will be any possibility to add those functionalities in future to trigger script block at specific day and time?

Airtable tends to not announce new functionality until it is ready for at least beta. While, there is a possibility that trigging a script on a schedule might happen, we have no idea when.

If you need a script to run on a recurring schedule, you can also look into accessing the Standard API from a third party scripting platform. However, the learning curve for the Standard API is higher than for Scripting block.

This should do it. :winking_face:

Hey Google! Remind me to run the script block at 4p every day!

Anyone who says this has mastered the art of scripting in non-blocking languages and is [therefore] a very good programmer. Don’t believe a word from top-shelf developers concerning the “ease of programming”. :slightly_smiling_face: @kuovonne is truly an expert developer and by definition lacks the judgment to assess what may [or may not] be an easier learning curve for non-programmers. Her mind works in a different world. Just sayin’ …

Functional programming is simple, straightforward, and linear, so I think you’ll find that while all scripting environments are generally difficult to master, the script block, which is non-blocking, is a bit more difficult to learn than say VBScript or Google Apps Script unless you invoke the non-blocking mode for these ancient scripting models.

For someone with years of experience in functional programming and web development, the Standard API may be easier. However, for someone without that experience, the Scripting API is easier.

• Standard API requires authentication, but Scripting block runs under the credentials of the current user. If you haven’t had to deal with authentication before, it can be a lot to learn in itself.

• Standard API requires using a separate code editor, but Scripting block has a sophisticated built in editor with built in hints.

• Standard API documentation does not include the read/write formats for each field type, but Scripting block does. (They value are actually the same for both, but it isn’t obvious to look at the documentation for the other.)

• Standard API has no automatic method of displaying output and requires either using dev tools or added code to display output. Both of those have their own learning curves. Scripting block has the very handy output.inspect that you can throw in anywhere and that concisely displays a wealth of information when you don’t even know what your data is because you’re debugging.

• The Standard API cannot retrieve metadata itself, such as finding the names of all the numeric fields in a table. You have to look up that info. Scripting block has access to the metadata, so you have to hard code fewer names.

• Standard API documentation has no fully coded executable examples, only snippets. Scripting block has fully coded, executable examples that you can run right out of the box with just copy/paste.

• Standard API requires paginated reads to get more than 100 records, but for Scripting block, you instantly get all the records in a table/view without having to deal with pagination.

• Standard API has a batch limit of 10 records, but Scripting block has a batch limit of 50 records. Small proof of concept projects might be within Scripting block’s batch limit, but not the standard API batch limit.

• Standard API has a rate limit of 5 requests per second. The rate limit of Scripting block isn’t published, but if you always await your async functions, you will never run into it.

As for the non-blocking versus functional aspects, you can simply run everything in Scripting block in series, and not in parallel. If the function has “async” in it’s name, always await it. If you write your own function that uses await, make it an async function, and use await when calling it. Airtable actually added “async” to these function names at the last minute. While the way Airtable released the changes to the input function names was problematic, the name change itself was very smart and helpful.

@kuovonne - thank you for proving my point. :winking_face:

If you have to explain this to a new [aspiring] domain expert who wants to do a little javascript programming, it is a steeper learning curve, right?

This [BTW] is a great list of learning points re the API - it should a big blog post.

Well, it depends on what you’re comparing it to.

Learning to always use await when there is async in the function name is pretty small compared to the laundry list of things in my previous post about the Standard API. Plus, with the Standard API, you still have to deal with callbacks, and those aren’t any easier to learn. In Scripting block, you don’t even have to understand what await and async mean (or know what promises are or how to run things in series vs. parallel) to get functioning code.

You learned Scripting block while it was still in beta, before Airtable changed the names of the functions to clearly indicate which functions were async functions. Trying to use async functions without being told that they were async functions must have been super confusing.

Now, if you’re comparing learning Scripting block to learning scripting in general, that’s a totally different beast. There are many ways of writing scripts and many ways of learning how to code.

The best coding/scripting language/platform/architecture/stack to learn is the one that will enable you to accomplish a project that you really want done. If that project motives you enough, the slope of the learning curve doesn’t matter as much.

Airtable is unique in that it provides two APIs with very similar functionality. If you’re starting from scratch and either API will work, pick the API with the easier learning curve.