前回の記事から期間が空き、その間に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アプリを構築していた場合などには、使いやすそうです。
まとめ
今回は、Slackの次世代プラットフォームの特徴について、まとめました。
前回から時間も空いているので、予定通り次回に移植の記事を書くかは悩んでおりますが、
何かしらSlackの次世代プラットフォームで作ってみるところまで、記事の完走を目指したいと思います。