ジェネラティブエージェンツの大嶋です。
もくもくDifyで「Difyソースコードリーディング#3 ―APIのリクエストからレスポンスまで」というイベントを開催しました。
アーカイブ動画はこちらです。
Difyのソースコードは以下です。
今回は 戸塚さん にも同席いただいて、一緒に話しながらコードを読んでいきました！
今回のポイント
APIのリクエストからレスポンスまで
今回の目標の1つ目は、APIのリクエストからレスポンスまで、おおよそどのような呼び出しの繋がりになっているのか把握することでした。
ワークフローを実行するAPIである、WorlflowRunApiクラスのpostメソッド を起点として、実際にワークフローのノードが処理されるところまでコードを追ってみました。
CONTRIBUTING_JA.md の記載などから想像していた通りですが、「controllers -> services -> core」という流れで呼び出されていることが分かりました。
ワークフローの実行
ワークフローはDifyの内部でグラフとして表現されており、GraphEngineクラス で各ノードを順に処理していそうなことが読み取れました。
具体的には、コードの以下の箇所のwhileループで、ノードを順に処理しているように見えます。
ワークフローのノードのクラス
気になったので、ワークフローのノードのクラスもいくつか見てみました。
ワークフローの各ノードは、BaseNodeクラス を継承して実装されていることが分かりました。
例えば LLMNodeクラス でLLMの呼び出しが行われているようです。
おおまかにどんなAPIがあるか
少し話がそれましたが、今回の2つ目の目標だった、おおまかにどんなAPIがあるか把握することにも取り組みました。
DifyのAPIのエンドポイントは api/controllersディレクトリ で定義されています。
この中にさらにディレクトリがあり、それぞれおおよそ以下のAPIのようでした。
- console ... Difyにログインしてアプリを作成したりする際のAPI
- files ... ファイル関係（？）
- inner_api ... Enterprise用（？）
- service_api ... 不明
- web ... Difyのアプリを公開した際のAPI
とくに重要なのがconsoleディレクトリとwebディレクトリで、基本的なAPIはこの2つのディレクトリ内でエンドポイントが定義されているようでした。
次回のご案内
Difyでは、モデルやツールの詳細がYAMLファイルで管理されています。 次回は、これらのYAMLファイルがどのように扱われているのか読み解くことを目標にします。 時間があれば、ワークフローを保存するYAMLファイルの出力などのコードも探してみます。 ご興味ある方はぜひ気軽にご参加ください。
また、水曜日にもDifyのもくもく会が開催されます。 こちらではDifyの使い方の解説として、テンプレートをみていく予定となっています。 こちらもご興味ある方はぜひ気軽にご参加ください。
