時間のかかる処理簡単に作れるよ！しかも進捗確認も簡単にできる！！っていうくらいのノリで発表してきました。
発表資料はこちらになります。
#スマートスピーカーを遊びたおす会
— ちょまどMadoka@エンジニア兼マンガ家 (@chomado) March 5, 2019
今日はありがとうございました！☺️
私のスライドはこちらです
ーー
Google Home, Amazon Echo, LINE Clova クロス開発＆ Azure Durable Funcitons で時間のかかる処理を簡単に書くhttps://t.co/wSWqQAB6TQ
ーー pic.twitter.com/BeRJrvskfw
ちょまどさんパートの中身については、ちょまどさんにお任せするとして私のパートでお伝えしたかったことはこれです。
さらっとDurable Functionsの説明されてるけど、これすごいことをさらっと実現できてます。セッション保持可能な関数のオーケストレーションを自分で書けて、エラー処理やタイムアウトの制御も実装可能。勉強する価値ありですよ。 https://t.co/Is9TZQMMia #スマートスピーカーを遊びたおす会
— Yoichiro Tanaka (@yoichiro) March 5, 2019
こういう複数の処理が連携して動くワークフローの定義って、私の認識ではワークフローデザイナーみたいなので画面でぽちぽちデザインして、裏側では JSON なり XML なりで管理されて実行エンジンが、それを解釈して動くようなものが多いと思ってます。 Durable Functions はプログラムコード（現在対応している言語は C#, JavaScript(TypeScript も OK)) で書ける点が強いです。
会場で受けた質問について
要約すると以下のような内容の質問を受けました。
最初はいい感じで動いてたけど、そこそこの期間運用してるとうまく動かなくなることがあった。 Durable Functions をオーケストレーター関数のインスタンス ID にはユーザー ID を指定している。
即答できなかったのでちょっと調べてみたら、同じ ID での実行履歴がたくさん溜まってくると、それを読み取るのに時間がかかるので結果として Durable Functions がうまく動かなくなるっぽいように見えました。
上記ドキュメントから引用 このテーブルのパーティション キーは、オーケストレーションのインスタンス ID から派生します。 ほとんどの場合、インスタンス ID はランダムであり、Azure Storage での内部パーティションの最適な分散が確保されます。
そうはいってもユーザー単位で単一のオーケストレーター関数っていうのは便利なのでユーザー単位でインスタンス ID が 1 つというのはやりたい。
ということなので、履歴消去の仕組みがありました。
PurgeInstanceHistoryAsync で自分にとって都合のいいタイミングでいらなそうな履歴は消してしまうと精神衛生上よさそうです。
まとめ
Durable Functions はいいぞ。
