私は magento の初心者で、magento を使用した Web サイトの作成に取り組んでいます。magento には、e コマース Web サイトを作成するために必要なすべての機能を公開する多数の API があることに気付きました。そこで、magento の api を使用してデータをフェッチしたいのですが、magento に依存せずに UI を個別に開発します。私は、magento テーマを使用して Web サイトを開発する多くの参照を見つけましたが、UI が別の MVC で開発され、magento を純粋にサービス層として使用するものは見つかりませんでした。私のアプローチに問題/問題はありますか?
編集: API の db パフォーマンスの問題と、外部キャッシングが問題を軽減する方法について多くの明確さを得ましたが、サービス層としての magento の圧倒的な使用 (つまり、magento の api を使用して Web サイトに燃料を供給する) をまだ理解していません。 、他の落とし穴はありますか？
Magento APIは低速であり、MagentoAPIからサイトを実行しようとすると深刻なパフォーマンスの問題が発生します。
EAVモデルは複雑な性質を持っているため、APIだけで製品を管理するのは難しい場合があります。
Magento独自のフロントエンドの使用に関して特に懸念があることはありますか？最初は大変ですが、レイアウトシステムを理解すると、実際には非常に強力でカスタマイズ可能です。
Magento API の遅さをどのように克服したかを以下に示します。
これはやり過ぎのように聞こえるかもしれませんが、速度が遅くなることなく、かなり高いスループットを達成することができました。
技術的には、APIを介してのみサイトを実行することが可能です。
あなたが直面するかもしれない問題は実際的なものであり、すべてのAPI呼び出しを学ぶことに時間を費やす代わりに、Magentoで現在のUIを実装する方法を学ぶことができます。
このアプローチの利点は、Magentoが内部でどのように機能するかをよりよく理解できるため、Magentoの機能を独自のビジネスニーズに活用できることです。
もう1つの問題は、APIを使用する場合、処理/計算の方法を少し制御できないことです。これに対して、Magento自体で作業する場合は、詳細を制御することができます。
SOAP と XMLRPC の両方を介して Magento の API にアクセスすると、「セッションの有効期限」の問題が定期的に発生します。私のすべての呼び出しには、実行の停止を避けるために例外処理が必要です。APIの上にすべてを構築するとき、それだけでは悪夢が生まれると思います.
最良の答えは、コーディングを開始する前に API の負荷テストを行うことです。テストを広範囲にログに記録し、エラーを探します。通常のエラーが表示される場合は、質問に答える必要があります。試していることを実行しても問題ないというドキュメントが見つかったとしても、ストアの実行に必要な負荷の下で適切に動作するように API を調整する必要があります。
開発に何時間も費やす前に、自分が何に直面しているのかを知っておくとよいでしょう。