結論
- Answer 1. 2023年7月現在、async await使えません 2024年6月現在も使えなさそう
- 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月時点では上記の方法しか観測できなかったが、こちらで新しい方法の提案、サポート情報について議論されている可能性もあるので、一度チェックすると良さそう。 2024年6月に確認したが更新されておらず。
その他の方法: google formでキューイングする事例もあったが、これはトリッキーすぎて試せてない。
GASのgit管理
GoogleAppsScriptは、clasp使ってgit管理し、pushもdeployもGithub Action等を使い、自動化しましょう。
https://github.com/google/clasp
私見&感想
GASはプロトタイピングに適す
個人的には、GASは個人開発やプロトタイピングには適しているが、数人規模以上の環境では、使うべきではないという認識を持っている。
というのも、比較的レートリミットが早く来てしまうため。
例えば、トリガーの合計実行時間が90分/日なので、Async.gsなど使うとあっという間に制限いっぱいになる。
参考 https://developers.google.com/apps-script/guides/services/quotas?hl=ja
アーキテクチャの知識あったほうがよい
日本語で書かれた記事を見てみると、結構いたるところで使われている印象を受ける。
個人的にはオフィシャルな空間などで実運用する場合は、GASからの移行先を想定した上で試験的に使ったほうが良いと思った。
アーキテクティング知識を培っておくと、こういった領域も視野に入りやすいと思った。
読んだ本
ソフトウェアアーキテクチャの基礎
「要件からアーキテクチャ特性を抽出するのだよ」という数ページの説明に特に価値を感じた
Design It!
実際に何したらいいかがたくさん書いてあるので、参考になりそう(実際に使ってはないが)
