私は、Rails のバックエンドと CSS/HTML のフロントエンドを備えたサイトをかなり有能に構築した、かなり優秀な開発者を雇った非技術的な (つまり、ソフトウェアやハードウェアのバックグラウンドではない) 創設者です。次のステップは、Yodlee 統合を開発することであり、これを行うのにかかる時間を知りたいと思っています。彼は私が合理的だと思う見積もりを持っていますが、回答に偏りがないようにコミュニティからのフィードバックを求めています.
また、誰かが以前に実装を行ったことがある場合は、あなたの視点と助けに本当に感謝しています!
過去 2 年間、LA を拠点とするスタートアップ企業に複雑な Yodlee 統合を実装してきました。彼らはその上にソーシャル ゲームとマネー管理プラットフォームを構築しました。簡単に言えば、それはタフで汚い仕事だということです。
アプリケーションが Yodlee API と通信するための技術的な側面は、まったく難しい部分ではありません (ほぼ標準の Web サービスです)。以下は、難しさを強調するいくつかの側面です。
私は 15 年間システムの設計と構築を行っており、プロジェクトの見積もりをかなり得意としてきました。私たちはヨドリーとはかけ離れていました。実際、私たちはまだ問題に取り組んでいます。なぜそれが難しいのかを理解するには、Yodlee とは何かを理解する必要があります。Yodlee は 10,000 の異なるシステムのアグリゲーターです。これらの他のシステムは、バンク・オブ・アメリカ、チェースなどの大規模な専門システムかもしれませんが、多くの場合、小さな小さな銀行 (オマハのボブズ銀行) です。
Yodlee が大企業 (コンテンツ サービスと呼ばれる) と通信する場合、ほとんどの場合、実際に適切なデータを返す API が存在します。しかし、小さな子供たちと一緒に、彼らはスクリーンスクレイピングをしています。あなたはそれがいつも壊れていると想像することができます. 彼らはインドにチーム全体を持っており、それに専念しています。
もう 1 つの問題は、データのモデリングに関するものです。ソースの各コンテンツ サービスは、データをさまざまに (さまざまな名前、さまざまな要素、さまざまな関係など) モデル化していますが、Yodlee では 10,000 モデルすべてを 1 つのビューに結合しています。これにより、特定のデータ要素を知ることも期待することもできない、非常に肥大化したモデルが残されます。
アイデアを提供するために...標準の基本クラスフィールド（残高など）を超えて、クレジットアカウント（apr、クレジット金額、最後の支払いなど）に関する追加のフィールドがあります。このデータを持っていることは素晴らしいことのように思えますが、実際には、これらの追加データ要素を提供するコンテンツ サービスの数は非常に少なく、実際には依存することはできません。これらのデータ要素の忠実度は非常に低いと言えます。本当に信頼できるのは、基本要素 (口座名、種類、残高) と (取引日、説明、種類) だけです。
トランザクションといえば...彼らのトランザクション分類システムはあまり良くありません。彼らは、正確さに焦点を当てるのではなく、明らかに幅を優先するアプローチをとっています. はるかに効果的なトランザクション分類のためのシステム全体を構築しました。
その他のいくつかのこと: DAG アカウント テスト システムは役に立ちません。実際のアカウントと同じようには機能しません。さまざまなコンテンツ サービスで 5 ～ 10 個のアカウントを開設し、開発者にテスト用のユーザー名とパスワードを提供する方がはるかに優れています。アカウント セキュリティの MFA (多要素認証) システムは、頭の痛い問題でした。これは Yodlee のせいではなく、ゲームの性質です。銀行は、セキュリティ層を追加するクレイジーなことをますます行っています。Yodlee は、これを補うために MFA システムを導入しています。常に、何らかの理由でアカウントの約 20% がエラーになっています。これを管理するためだけにコンポーネント全体を構築しました。
それで、これはどういう意味ですか？見積もりを2倍にして、汚れる準備をしてください。私は Yodlee を倒したくありません (ドキュメントがないことを除けば)。彼らは本当に難しい問題を解決しています。他のより良いオプションは本当にありません。
私は Yodlee API の販売とサポートを担当するチームを運営しているため、反応が少し偏っている可能性があります。
クライアントが 10 日から 3 か月から 6 か月で起動して実行されるのを見てきました。実装にかかる時間は、使用しているデータ モデル内のフィールドの数と、ユーザーに表示する前にデータを使用または操作する方法によって異なります。
口座残高や取引金額などの最も一般的なデータ フィールドは常に利用できますが、Craig の言うとおりです。より広範なデータ モデルを使用すると、データが存在しない場合の例外をコーディングする必要があります。Yodlee は、このプロセスを支援するためにフィールドが利用できる頻度に関するドキュメントを提供しています。ただし、基本的なアカウントとトランザクション情報のみを使用する場合は、これらの複雑さについて心配する必要がなく、実装が迅速化されます。
Yodlee から受け取ったデータをどのように使用するかも、統合にかかる時間に大きな影響を与えます。トランザクションの説明から追加のデータを取得する場合、または分類を使用して何かを行う場合は、複雑さが増し、より多くの時間が必要になります。多くのフィールドをそのまま使用している場合、これはより簡単になります。
Craig が言及したもう 1 つの項目は、追加のセキュリティの質問 (多要素認証) です。API のそのセクションはいくつかの作業を追加しますが、統合を容易にするために、これに関するドキュメントを追加しました。また、開発上の問題が発生した場合は、テクニカル コンサルティング チームが監視する開発者フォーラムへのアクセスをクライアントに提供します。