前回の記事から期間が空き、その間にSlackの次世代プラットフォームはオープンベータから段階的な正式リリースのステータスとなり、多くのアップデートがありました。
そのため、前回の記事と繋がらない部分はあるかと思いますが、ご容赦ください。

さて、今回は次世代プラットフォームの特徴をまとめていきます。
まとめるカテゴリーとしては、公式サイトのアピールポイントごとに行い、
これまでの方式との差異などを交えて記述していきます。

1. 統合された開発環境が提供される

以前のSlackアプリは、APIリファレンスを基に直接コードを書いたり、PythonのSDKを用いて開発を行っていました。
次世代プラットフォームでは、Slack CLIが提供され、これ一つで簡単にアプリのプロジェクト作成からテスト、デプロイまで行えるようになりました。
これにより、開発効率が向上することはもちろんですが、組織やチーム間でのプロジェクトの共有も容易となり、メンテナンスやアップデートについても多くの恩恵を受けることができるようになりました。
Slack CLI - Install & authorize

2. アプリのホスティング環境が提供される

次世代プラットフォームでは、コンピューティングリソースについても、Slackから提供されます。
これまでは、GASで書かれたものや、Pythonでイベント駆動型のサーバレス環境に設置されたものなど、動作環境が分散したり、それぞれの環境をメンテナンスする必要がありました。
それが、次世代プラットフォームでは、Slackが提供する環境で動作するため、環境の把握や管理も不要となり、ロジックの開発に集中することができるようになりました。

3. Slackというプラットフォームに特化したSDK

CLIでセットアップされるプロジェクトは、denoというJS/TSランタイム用にベースが作成されます。
そのため、プログラムの実装については、TypeScriptで行います。

プロジェクトは、Functions,Workflows,Triggersという、Slackプラットフォームに対する開発に特化した要素で構成されます。
なので、作りたいものをプログラムコードの文脈で分解しやすく、スムーズに開発に入っていけるように感じました。
各要素については、概要を以下にまとめます。

3-1. Functions

Workflowsを構成する機能の単位です。いわゆる関数です。
SDKがSlackを操作するための便利なメソッドを多数用意してくれているので、
データの加工や判定処理など、アプリに必要な部分を自分たちで実装していきます。
Slack functions

3-2. Workflows

実現したい処理の流れです。アプリのメイン処理部分です。
Functionsの組み合わせで構成されているので、可読性が高く、入れ替えや追加、編集も容易に行えます。
What are workflows?

3-3. Triggers

Workflowsの起動される条件にあたります。
定義できる条件は、

Link (チャンネルから特定のURLクリックで実行)
Scheduled (特定日時、毎時、毎日などの定期実行)
Event (チャンネルへの参加、メンション、リアクションの追加などSlack上のイベントを起点に実行)
Webhook(外部サービスなどから、特定のURLに対してのデータ送信で実行)

と、充実しており、それぞれの条件でアプリに渡される情報が異なるので、アプリで実現したいことをもとに、最適なものを選択します。
Triggering workflows

3-x. Datastores

処理からは少し離れますが、
Slackインフラ上に、NoSQLのデータベース(DynamoDB)も構築することが可能です。
感想になりますが、今までGAS(with スプレッドシート)でSlackアプリを構築していた場合などには、使いやすそうです。

Datastores

まとめ

今回は、Slackの次世代プラットフォームの特徴について、まとめました。
前回から時間も空いているので、予定通り次回に移植の記事を書くかは悩んでおりますが、
何かしらSlackの次世代プラットフォームで作ってみるところまで、記事の完走を目指したいと思います。