ワークフローのカスタムコードで複雑なことをするのはつらい

Operations Hub Profesionalプラン以上で使えるワークフローのカスタムコードアクションはコードを書くことで何でもできるので便利ですが、複雑なことをしようと思うと結構大変です。

つらいポイント1. 標準で提供されているライブラリが限られている

まず標準で利用できるNode.jsライブラリが下記に限定されています（2022年12月現在）。

• @hubspot/api-client ^3.4.1
• async ^3.2.0
• aws-sdk ^2.858.0
• axios ^0.20.0
• lodash ^4.17.20
• mongoose ^5.11.19
• mysql ^2.18.1
• redis" ^3.0.2
• request" ^2.88.2
• bluebird 3.7.2
• random-number-csprng 1.0.2
• googleapis 67.1.1

これだけたくさんあれば多くの場合は何とかなりますが、地味にday.jsが無いのはキツかったりします。そうなると自前で使いたいライブラリを import しようと思い付く訳ですが、ワークフロー上ではファイルシステムがなく当然 import などは使えませんので自前で用意したライブラリを含めてバンドルする必要があります。

つらいポイント2. モジュールバンドラとワークフロー上の仕組みの相性が悪い

ワークフロー上では既にHubSpotのAPIクライアントが用意されているため、const hubspot = require('@hubspot/api-client'); でAPIクライアントが使えます。これ自体は非常にありがたいです。

しかし一方でローカルで開発し、デバッグもするので当然ローカルのファイルでも上記コードを含みます。そして自前のライブラリをワークフロー上で利用するためにwebpackなどでバンドルすると、HubSpotのAPIクライアントもバンドルされたファイルが出来上がります。これがまたファイルサイズがかなり重いのでワークフロー上にバンドル後のコードをそのまま載せる訳にはいきません。

そのためなるべくファイルサイズを減らすべく Tree Shaking や Split Chunks など試行錯誤するのですが、それでもAPIクライアント自体が元々かなり重いためなかなか500KB以下にはなってくれないのが実情です。また Split Chunks してしまうとAPIクライアントに対する依存を手動で書き換えなければならないため、これまた面倒です。

つらいポイント3. コード分割ができない

上記の理由からモジュールバンドラとの相性がかなり悪いので、複数のカスタムコードアクションで共通の処理を抜き出そうとしても、コード分割& import ということができません（できますが、上記バンドラとの相性の悪さを頑張って克服する必要があります）。

結論

ちょろっとAPI叩いて何かする…程度のものであればカスタムコードアクションでもよいかもしれませんが、要件が結構複雑であったり、複数のカスタムコードアクションに別れる場合は、カスタムアクションを作成するか、Webhookとしてデータを飛ばしてWebhookのデータを受ける側で処理をさせた方が良いように思います。
HubSpotのプロジェクトを利用すればサーバーレス関数を生やせるので、処理をそこに投げられればホスティングの面倒も見ずに済むのでラクそうですね（プロジェクトにはプロジェクトのつらいポイントがあるかもしれませんが…）。
検証した結果、プロジェクトのサーバーレス関数でも自分で書いたコードの import は出来ませんでした。CMS Hubのサーバーレス関数は検証していませんが、恐らく同様に不可能な気がします。結局 webpack などを使わざるを得ないため、HubSpotのAPIクライアントの利用をやめ、APIを axios などで直接叩くようにすればバンドルサイズが減らせるように思います。