Answer 1. 2023年7月現在、async await使えません
Answer 2. 非同期処理するためのライブラリが必要です
ライブラリ
- Async.gs: https://gist.github.com/sdesalas/2972f8647897d5481fd8e01f03122805
- 30~60s以上のラグがある
- また連続で処理するとGASの制限により、キューが詰まることも
- 処理は非同期のため、順番は保証されないことに注意するべき
- コメントの議論は読んでおくと良い
- RunAll: https://github.com/tanaikech/RunAll
- 並列処理と考えたほうが良さそう
- GCP連携せなあかんので10分だけ面倒
例えばslackのsubscription系の API使ったときに、そのレスポンスを処理をする場合、確実性的にAsync.gsに軍配が上がる。
参考資料
ここで公式っぽい雰囲気で(issuetracker.google.comなので)議論されている。
2023年6月時点では上記の方法しか観測できなかったが、こちらで新しい方法の提案、サポート情報について議論されている可能性もあるので、一度チェックすると良さそう。 issuetracker.google.com
その他の方法: google formでキューイングする事例もあったが、これはトリッキーすぎて試せてない。
Return a response from doPost before function finishes. : GoogleAppsScript
GASのgit管理
GoogleAppsScriptは、clasp使ってgit管理し、pushもdeployもGithub Action等を使い、自動化しましょう。
https://github.com/google/clasp
私見&感想
個人的には、GASは個人開発やプロトタイピングには適しているが、数人規模以上の環境では、使うべきではないという認識を持っている。
というのも、比較的レートリミットが早く来てしまうため。
例えば、トリガーの合計実行時間が90分/日なので、Async.gsなど使うとあっという間に制限いっぱいになる。
参考 https://developers.google.com/apps-script/guides/services/quotas?hl=ja
日本語で書かれた記事を見てみると、結構いたるところで使われている印象を受ける。
個人的にはオフィシャルな空間などでは実運用する場合は、GASからの移行先を想定した上で試験的に使ったほうが良いと思っている。
この辺の考え方はプログラミング知識に加えてアーキテクティング知識も蓄えておくと、気にする確率が上がるので良いと思った。
- O'Reilly Japan - ソフトウェアアーキテクチャの基礎 → 要件からアーキテクチャ特性を抽出するのだよ、という数ページの説明に特に価値を感じた
- O'Reilly Japan - Design It!→実際に何したらいいかがたくさん書いてあるので、参考になりそう(実際に使ってはないが)
業務上アーキテクチャ領域に踏み込むことは少ないような、基本プログラミングしかしないような私のような人でも、アーキテクチャレベルで考えないと詰むなということが肌感+αでわかるようになったため、いろんな知識大事だなあと思いました💆
