静的ページのみがバックエンドを呼び出すのは良い考えですか？
特にフロントエンドに関しては、Webアプリケーション開発は初めてですが、理解できるように、大きなアプリケーションの一般的な構造には、バックエンドサービスを呼び出して動的ページを生成するフロントエンドphp（または同等の）レイヤーがあります。
現在、私たちは新しいサイトを構築しており、私の同僚は、動的ページを生成するレイヤーがないと主張しています。彼はページをhtmlとJSの単なるスケルトンにしたいので、基本的に静的なWebページであり、JSでバックエンド（REST）を直接呼び出します。もちろん、これはバックエンドサービスを公に利用できるようにすることを意味します。
このアーキテクチャのアプローチはお勧めですか？それはスケーリングしますか？
あなたの同僚が提案したそのアーキテクチャは、今日ではかなり一般的です-それは Single Page Application と呼ばれています。
セキュリティの点では、2つの方法は同等です。どちらの場合も、サーバーはページの作成に必要なすべてのデータを生成し、クライアントに送信します。唯一の違いは、このデータがユーザーに表示されるフォームにフォーマットされる場所と方法です。
たとえば、ユーザーに製品の検索を許可する場合、従来のアプローチではサーバーは製品のリストを含むHTMLページ全体を生成し、SPAアプローチではサーバーが同じ製品のリストを生成します。ただし、HTMLをレンダリングする代わりに、リストをXMLまたはJSONまたはその他の形式にシリアル化し、シリアル化したリストをクライアントに送信します。
どちらの場合にも注意してください。
- 製品を表示するために必要なすべてのデータは、ネットワーク上で転送されます。
- 製品を表示したり、それ以上の操作を実行したりするのに必要ないデータ（表示しなくても、ユーザーが製品を注文するためのボタンをクリックした場合にクライアントが必要とする製品IDなど）クライアントに到達しません。
- 内部サービスは公開されていません-SPAを使用してDBを直接クエリすることはできません。製品のリストを生成するメソッド（およびクライアントに公開することにしたその他のメソッド）を呼び出すだけですが、公開する必要があります。クラシックアプローチの同様のサービス）
セキュリティの面で、SPAアプローチに対する従来のアプローチの唯一の利点は、SPAによってアプリケーションをプログラムで使用するのが少し簡単になることです。たとえば、毎朝実行され、資格情報でログインするスクリプトを作成する方が簡単です。製品のリストを要求し、新しい製品を追加した場合はメールで通知します。しかし、私は古典的なアプローチでもそれを行うことができました-少し難しいでしょう（シリアル化形式からよりもHTMLページからデータを抽出するのが難しいためです）が、それでも可能でした（実際に行いました）数回...）