Bear in mind that Script Blocks are working in the context of the existing browser app which has already performed a significant series of tasks to bring the data for the base into scope.
Sure, you can do that and this is especially useful if you want to process your data more slowly. As such, your hunch that it is a bit crazy is fully validated. :winking_face:
Sure, this is not an unreasonable assertion or approach in a traditional client-server relationship, but Script Blocks is not a traditional client-server environment. Think of Script Blocks as serverless containers running inside a client that is itself a container which has already asked for and received all of the data associated with a base.
I believe (architecturally) a call to <table>.selectRecordsAsync() is simply a formality; a way to associate existing data pointers with your block. This would explain why Script Blocks are blistering fast.
From my experience – and not without great trepidation – I worried about this exact issue and pondered whether I could be creating performance issues. However, I soon realized that the core task of any Script Block is to simply filter the data (which is already likely in memory) as it pertains to a given process objective. And Javascript is certainly the best way to achieve that unless they also supported Python (I predict that someday there will be a Python script block).
I’m pretty sure this use of javascript for filtering and such is what the dev team had in mind - a climate that frees us to focus on the data, not necessarily getting the data.
Not So Optimal, Perhaps…
Indeed, API queries add a degree of standardization making it possible to assert processes involving the data without crafting a wholly new approach using the raw nature of JavaScript. However, you are free to utilize a more abstract approach similar to (or actually employing) search.js, jsql, or graphql. Doing so might provide a query underpinning that can homogenize data access models across your Script Block apps.
