この記事について
- この記事は、現在エンタープライズ向けWebアプリケーション開発に携わってはいるが、SalesforceでのWebアプリケーション開発、ということについて慣れていない or 新たに参入する必要がある立場の人/事業者に、どのような状況であるかを解説します。
- １パートナー＆市井の開発者の立場としての意見ですので、デベロッパーマーケによる大本営発表のメッセージとは違う部分は多々あると思います。
そもそもの話：Salesforceって？
- Salesforceは営業支援がメインのクラウド型アプリケーションサービス。一般的にはSaaSだと認識されることが多い。
- SaaSではあるのだけど、自由にデータベースとなる入れ物を定義できるため、プラットフォーム色が強い
- データベースとなる入れ物を作成したらCRUD用の画面がセットで生成されるので、いちいちUI開発する必要がない。またある程度ならGUIのレイアウトエディタで調整も可能
- データベースにアクセスするためのAPIもあるけど、Salesforceのサーバ内にUIを記述したりビジネスロジックを記述したりしたものをホストできる
- つまり任意のWebアプリケーションの開発がSalesforceのサーバだけで可能である
構築できるWebアプリケーションの種類（利用ユーザのタイプ別に）
- Salesforceを使っている会社内の社員が使うアプリケーション
- 社外のメンバー（パートナー、顧客）との間で利用するアプリケーション
- Force.com Site / Community機能を使って構築する
- あるいはHeroku等の外部サーバを使う
大体の場合は社内向けのユースケースがほとんど（Salesforceのアプリ自体が社内ユースがメインだから）。
アプリケーション開発パターン
パターン1. Visualforce + Apex
- 古来(2007〜)からの王道
- Visualforceで独自タグを書いてUIを記述
- Apex（独自言語)を用いてロジックを記述
- Javaっぽいとは言うが、Genericsを使ったクラス定義もできないJava5未満のそれ
メリット
- Salesforce標準のUIに沿ったUIがタグを書くだけで実現できる
- ユーザの権限情報に密接したコンポーネントの表示制御（例：参照のみ項目は入力不可になるなど）
デメリット
- 独自の言語/独自のタグを覚える必要があるため、新規参入者にはSalesforce開発のためにエンジニアへの初期投資が必要となる。
- 構築したものはSalesforceのプラットフォーム上でしか動かない（技術的ロックイン）
- 現在、本家が新UI基準（Lightning Experience）に移行中のため、上記のメリットで挙げた利点があまりなくなってしまう可能性
パターン2. Visualforce（薄め）+ JavaScript(HTML5) + API ⇒ SPA
- VisualforceはただのHTMLの箱としても一応使える。この場合独自タグは不要
- JavaScriptおよびCSSなどの静的ファイルは「静的リソース」という仕組みでSalesforce内にホスティング
- SOAP/REST のAPIエンドポイントは画面と同一ドメイン内にホストされるため、JavaScriptから直接APIコールが可能
- JSforceというJavaScript向けのAPIライブラリがあります
メリット
- Salesforce以外でのSPAでのWebアプリケーション開発のノウハウを適用できる
- 技術的ロックインを極力避けられる
デメリット
- すでにエンジニアがSPAでのWebアプリケーション開発に慣れていないとBootstrapとしてはメリットがない
- しかしながら投資した内容がSalesforce向けに限らない場面で使えるという利点はある
- Salesforce内のメタデータ（権限情報など）に密に連携したUIの構築には手間がかかる
- APIには利用制限がある（使えるエディションおよび1日あたりのコール数上限が決まっている）ため、環境およびアプリケーション内容によって配慮が必要
パターン3. Visualforce（薄め）+ JavaScript(HTML5) + JS Remoting + Apex(薄め) ⇒ SPA
-
- からAPIの利用について排除したパターン
- APIの呼び出しは各種制限（エディション、コール数）があるためこれを考慮したもの
- Apexでのロジック実装はデータクエリや保存などシンプルに徹する
- JavaScript Remotingという仕組みでApex内のメソッドをJS側のメソッド呼び出しに変換
メリット
- Salesforce以外でのSPAでのWebアプリケーション開発のノウハウを適用できる
- 利用制限のあるAPIの使用を回避しているため、環境制約が少ない
デメリット
- 技術的ロックインが多少ではあるが存在する
- すでにエンジニアがSPAでのWebアプリケーション開発に慣れていないとBootstrapとしてはメリットがない
- Salesforce内のメタデータ（権限情報など）に密に連携したUIの構築には手間がかかる
パターン4. Heroku（およびその他PaaSなど） + API
- Salesforceは完全に箱に徹する
- データメンテナンスなどの管理側のUIが自動でついてくるので、それでも価値はある場合は多い
- アプリケーション開発側は開発言語も含めて自由に決定できる
- さらに発展形として Heroku Connect （SaleforceのデータをHeroku Postgresと同期するもの） を使うという選択もある
メリット
- 技術的ロックインが存在しない、または完全にローカルでも同様のアプリケーションが構築できる
デメリット
- Salesforce以外にサーバインスタンスを持つことによる運用負担の増加
- たとえPaaSにしろアプリケーションレベルでの運用監視などは必要となる
- 追加のサービスおよびライセンス契約が必要
各パターンに関して、個人的見解
- パターン1.は、基本的に今からSalesforceでの開発に新規参入する事業者がとるべき選択肢ではない
- 唯一ありえるのは、むしろ自社内のエンジニアリングリソースを活用できない場合で、オフショアなど安価に教育済みのエンジニアリングリソースを調達するあてがある場合など
- エンジニア個人の戦略としても、パターン1.での開発経験を積むのは注意が必要
- たしかに現状カスタム開発の案件として需要が多いのはこのパターン
- たかだか数年の食い扶持のためだと割り切ることができるか
- あるいはCOBOLのようにほぼ保守需要だけになっても（ともすれば荒稼ぎはできるかもしれないけど）そこに居続けるのでいいのか
- なんのためにエンジニアをやっているのか
- パターン2. 3. はSPAが前提であるが、今のエンタープライズ（にかぎらずではあるが）Webアプリ開発ではSPAはトレンド中のトレンド
- Salesforceの開発にかぎらず活用可能。投資しても損はたぶんない
- 差別化戦略としても、ちゃんとこれ(SPAでの開発)ができている事業者/個人はまだ少ないので、今がチャンス
- 外部にエンジニアリングリソースを求める場合は少し注意が必要（『JavaScriptできます！』の玉石混交問題）
- パターン2. 3.はハイブリッド運用が効果的
- 違いはデータアクセス層のみ。適切にインターフェースを設定して環境ごとに分離することは可能
- ローカル開発では2.を利用(Visualforceは素のHTMLで代用)、プロダクションでは3.で運用する。3.のデメリットであるロックインを回避できる
- パターン4. は、すでにある自社のWeb開発技術（Ruby/Java/Python/PHP）をそのまま使えるので一番無難ではあるけれど
- Webアプリケーション開発できる事業者/個人は特に珍しくないので、差別化要素がない
- Salesforceだけで動くかどうかが要求の前提になるケースはカスタム開発・製品開発含めて意外に多い
- ユーザはSalesforceのサブスクリプションだけで何とか済ませたいと考えている
補足：Lightningについて
- 最近は大本営からはよくこの名前が出てきているはず。
- Lightningはほぼブランド名となっているため、コンテキストによって指すものが違っておりいろいろややこしい。新ユーザインターフェース(LEX)、開発フレームワーク(Aura）、コンポーネントベースのUI構築機能(AppBuilder)、CSSデザインフレームワーク(SLDS）、ライセンスのエディション、その他…
- しかもそれぞれについて残念な問題があり、全般的にあまり評価は高くない（私見）
- 開発フレームワークとしてのLightningについては、とりあえずまだ様子見の方が安全。リスクを取るには取るなり理由が必要という理解。単に業務アプリケーション構築のための手段としてこちらを選ぶ必要は現状まだない。