0

いくつかの「ソーシャル」機能を備えた Web サービスを開発しようとしています。(レスポンシブ) Web サイトとモバイル用アプリ (少なくとも iOS/Android) を作成する必要があります。

私はすでに API を備えた Web サービスを開発しています (アプリ アクセス用。通常は公開されていません)。ただ、今回は逆のアプローチを考えていたので、それについて意見をいただきたいです。

Web サイトを開発してから API を追加してアプリがサービスと通信できるようにする代わりに、API から始めて、その上にすべて (Web サイトを含む) を構築することを考えていました。次に、データベースと通信するサービス (PHP または Node.js アプリ) が存在し、Web サイト (クライアント側ではなくサーバー側) とアプリの両方がこのサーバーと通信します。

このアプローチの利点:

  1. データとビューの完全な分離。Web サイトは、API バックエンドとは別の別のサーバーで実行されます。
  2. おそらくよりスケーラブル

ただし、このアプローチでは、Web サイトとデータベースの間に追加のレイヤーを作成する必要があり、これがパフォーマンスに悪影響を及ぼす可能性があることも認識しています。

どう思いますか？この設計またはケーススタディの経験はありますか?

4

4 に答える 4

0

本格的なアプリケーションの場合、常に何らかの「サービス」レイヤーや「メッセージ バス」レイヤーが必要ですが、これは「API 」とは異なります。私見では、定義上、API は公開されており、変更されることはめったにありません。これは、新しい Web サイトには当てはまりません。また、Web サイトにはモバイル アプリとは異なる要件が必要になる可能性があります。

しかし、あなたのアイデアの精神は正しいので、物事をすばやく変えることができるようにする必要があることに注意して、分離に向けて努力する必要があります. したがって (強調してもしきれませんが) 、サービス指向アーキテクチャでは物理的な分離は必要ありません。コードを分離し、 SOAの黄金律に従うことができます: 状態と動作の分離 (つまり、ステートレス、サービス オブジェクトとデータ オブジェクトがあり、OOP はありません)。最初は物理的な分離が多すぎる (つまり、過剰なエンジニアリング) ために、変更を加えるのに非常に多くのことが必要になるプロジェクトをよく見てきました。

また、 RPC ベース(REST、要求/応答、および同期) とイベント メッセージ ベース(MQ、pub/sub、および非同期)をいつ実行するかを知っておく必要があります。ほとんどの Web アプリケーションは RPC を好みますが、モバイル アプリと HTML5 アプリでは非同期メッセージ (WebSocket またはネイティブ) を使用できます。

于 2013-10-12T18:05:01.077 に答える
0

このアプローチは魅力的に聞こえますが、私の経験では、将来的には制約になる可能性があります。API を使用するアプリケーションの優れたコミュニティが (できれば) あると、それを変更するのは非常に難しくなります。その一方で、サード パーティのアプリケーションが壊れることを心配することなく、Web サイトをすばやく反復処理する機能を保持したいと考えています。

長期的には、サードパーティの開発者が望むものをサポートするために手作りされた API と、Web サイトのユーザーが望むものを正確に提供する別の手作りの UI または API を持つ方がよいと思います。これらはユーザーのさまざまな構成要素であり、さまざまな要件がある可能性があります。

たとえば、アプリケーションでは、SQL に似たクエリ (OData を考えてください) を実行し、エンティティの多くの詳細を表示する機能を備えた豊富な API が必要になる場合があります。サード パーティは、エンティティのプロパティの小さなサブセットを使用した一括要求/更新のみを許可する、より単純な API を好む場合があります。たとえば、同期のユース ケースなどです。

自分のアプリとサード パーティのアプリの両方をサポートする API を作成しようとすると、いずれかを満たすことができなくなる可能性があります。

注:分離などを提供する API のユーザーに反対しているわけではありません。自分のアプリとサード パーティのアプリに共通の API を使用することについて話しているのです。

于 2013-10-12T18:16:22.230 に答える