🔥 FREE PRO OFFER OnlyLink.click Pro Version is 100% Free of Cost till 31 December, 2026! Claim Free Pro

Node.js

フロントエンド用バックエンド (BFF) パターンの理解: 簡単なガイド

フロントエンド用バックエンド (BFF) パターンの理解: 簡単なガイド

マイクロサービス アーキテクチャでは、当社のシステムは、ユーザー サービス、注文サービス、製品サービスなど、多数の小規模で焦点を絞ったサービスに分割されます。 しかし、この情報をユーザーに表示する場合、デバイスごとにニーズは大きく異なります。高速デスクトップ コンピューター上の Web ブラウザーには、テーブル、サイドバー、グラフが満載のリッチなダッシュボードが必要です。低速のセルラー ネットワーク上のモバイル アプリでは、帯域幅とバッテリーを節約するために、シンプルで軽量なレイアウトが必要です。スマートウォッチ アプリには 1 行のテキストのみが必要な場合があります。 これらすべてのフロントエンドがまったく同じバックエンド API をクエリする場合、誰かが妥協する必要があります。モバイル アプリは大量の役に立たないデータをダウンロードすることを強いられるか、Web アプリは必要なものをすべて取得するために何十もの個別のネットワーク リクエストを行うことを強いられます。 これは、フロントエンド用バックエンド (BFF) パターン によって解決されるまさに問題です。このガイドでは、このパターンを簡単な言葉で説明し、現実世界の類似点を見て、それを標準の API ゲートウェイと比較し、実際のコード実装について説明します。 現実世界のたとえ: レストランのメニュー 3 つのまったく異なるタイプの食事を提供するレストランを想像してください。 食品評論家。詳細な成分リストを含む完全な 5 コースのテイスティング メニューを望んでいます。 忙しい通勤者で、電車の中で簡単に包装済みの軽食を食べたいと考えています。 子供は、スパイシーな食材を使わず、少量でシンプルなお子様の食事を望んでいます。 もしレストランに、3 つのオプションすべてを詳細に記載した 1 つのメニューしかなかったとしたら、それは圧倒されるでしょう。通勤者は5品コースのレシピを読むのに時間を無駄にし、子供の親は簡単な食事の選択肢を見つけるのに苦労するでしょう。 代わりに、レストランでは 3 つのカスタム メニュー (テイスティング メニュー、エクスプレス To-Go メニュー、キッズ メニュー) を印刷します。 各メニューは同じキッチン (マイクロサービス) から取得されますが、その顧客 (クライアント) に合わせて選択肢の形式とサイズが設定されます。 このシナリオでは: キッチンはマイクロサービス (ユーザー、カタログ、支払い) を表します。 カスタム メニューはあなたの BFF (Web BFF、Mobile BFF、Watch BFF) です。 ダイナーはフロントエンド (デスクトップ ブラウザ、モバイル アプリ、スマートウォッチ) です。 問題: 「万能」API マイクロサービスが最初に普及したとき、多くのチームは、すべてのフロントエンド クライアントを処理する単一の共有 API ゲートウェイを構築しました。
Microservices BFF Pattern Backend for Frontend Software Architecture System Design Node.js
実例で解説する Electron IPC 通信の仕組み

実例で解説する Electron IPC 通信の仕組み

Electron は、HTML、CSS、JavaScript といった Web 技術を使用して、クロスプラットフォームのデスクトップアプリケーションを開発するための最も人気のあるフレームワークの 1 つです。内部的には、Node.js を実行する メインプロセス(Main Process) と、UI を描画するために Chromium を実行する 1 つ以上の レンダラープロセス(Renderer Process) からなるマルチプロセスアーキテクチャを採用しています。 セキュリティ上のリスクを排除するため、モダンな Electron アプリケーションでは、レンダラープロセスをオペレーティングシステムから隔離しています。つまり、レンダラーの UI から直接 Node.js モジュールやシステムリソース(ファイルの読み込みやデータベースへのクエリなど)にアクセスすることはできません。 このギャップを安全に埋めるために、Electron は プロセス間通信(IPC: Inter-Process Communication) を利用しています。 本ガイドでは、Electron の IPC がどのように動作するのかを解説し、本番環境でそのまま使用できる実用的なコード例とともに、3 つの基本的な通信パターンを紹介します。 1. レンダラープロセスからメインプロセスへ(単方向 / One-Way) このパターンは、レンダラーがレスポンスを待つことなく、メインプロセスにコマンドやアクションを送信したい場合に使用されます。一般的な例としては、UI 上のボタンをクリックしてアプリケーションウィンドウを最小化または閉じる操作が挙げられます。 これらが 3 つの主要なファイル(main.js、preload.js、renderer.js)でどのように実装されるかを見てみましょう。 メインプロセス (main.js) レンダラープロセスからのイベントを監視するために ipcMain.on を使用します。 const { app, BrowserWindow, ipcMain } = require('electron'); const path = require('path'); function createWindow() { const win = new BrowserWindow({ width: 800, height: 600, webPreferences: { preload: path.join(__dirname, 'preload.js'), contextIsolation: true, nodeIntegration: false } }); win.loadFile('index.html'); } // レンダラーからの 'close-app' イベントを購読 ipcMain.on('close-app', () => { app.quit(); }); プリロードスクリプト (preload.js) ipcRenderer モジュール全体をレンダラーに露出させるのではなく、contextBridge.exposeInMainWorld を使って安全なラッパー関数のみを露出させます。
Electron IPC Node.js デスクトップアプリ JavaScript