🚀 SDUIは、サーバーがインターフェースの説明（通常はJSON）をクライアントに提供し、クライアントがそれをレンダリングするアプローチです。UIを変更する際、アプリケーションのビルドではなくデータを変更します。リリース数を減らし、柔軟性を高めます。✨
📦定義：SDUIの本質
Server-Driven UI サーバーが UIの構造と動作を管理します：クライアントに画面レイアウト（コンポーネント、そのプロパティ、アクション）を送信します。クライアントは基本ブロックを描画してイベントに関連付ける方法を知っていますが、 レイアウトのロジックとバリエーションはサーバー上に存在します.
{
"screen": {
"title": "Product of the day",
"blocks": [
{ "type": "image", "src": "https://cdn.example.com/promo.png", "ratio": "1:1", "alt": "Promo" },
{ "type": "text", "style": "h2", "value": "Discount -30%" },
{ "type": "button", "style": "primary", "text": "Buy", "action": { "type": "POST", "url": "/buy?id=42" } }
]
}
}クライアントは新しい画面を描画するためにコードを変更する必要はありませんでした。送信されたスキームを描画するだけでした。
🔍 その仕組みをステップごとに説明します
クライアントはサーバーに画面の構成を要求します。
サーバーは、UI スキーマとアクションを含む JSON/DSL を返します。
クライアントはスキーマからUIをレンダリングし、イベントに署名します。
ビジネスロジック（A/B、フィーチャー、表示条件）はサーバー上にあります。
これは、リリースがモデレートされているモバイルアプリケーションに特に便利です。
💡 SDUIはフロントエンダーにとってどのように役立ちますか
リリースが少ないサーバー上のUIを編集すると、クライアントはすぐに変更を取得します。
プラットフォームでの単一のエクスペリエンス：Webクライアントとモバイルクライアントは同じスキームをレンダリングします。
クイック実験：A/Bテストとフィーチャーフラグ—クライアントを再コンパイルすることなく。
コンテンツと構成を中心としたアプローチ：デザインシステムは、スキームを介して「プル」することができます。
リリースなしの実験： プロダクトチームは、サーバーの応答で「購入」ボタンのテキストを「カートに追加」に変更し、同じ日のコンバージョンを確認します。
📌 現実的なAPIの例
サーバーはブロックのリストだけでなく、 条件、データとイベントのバインド:
{
"screen": {
"title": "Catalog",
"blocks": [
{ "type": "search", "placeholder": "Find product..." },
{ "type": "list", "items": "{{products}}",
"item": {
"type": "card",
"image": "{{item.image}}",
"title": "{{item.title}}",
"price": "{{item.price}}",
"cta": { "type": "button", "text": "Add", "action": { "type": "POST", "url": "/cart/add", "body": {"id": "{{item.id}}"} } }
}
}
],
"data": { "products": "/api/products?query={{query}}" },
"experiments": { "cta_text": ["Buy", "Add", "Add to cart"] }
}
}テンプレート {{placeholders}} は、リンクで要求されたデータからクライアントによって置き換えられます。
✅ 長所
UI変更の市場投入までの時間を短縮します。
表示ルールとインターフェースのバリエーションの一元化。
コンポーネントの抽象化による単一のデザインシステム。
⚠️ 短所
デバッグはより複雑です。バグはスキームとクライアントの両方で発生する可能性があります。
スキーマのバージョン管理の規律が必要です。
クライアントの「豊富な」インタラクションの制限。
🔧 SDUIが特に適している場所
リリースのモデレーションが長いモバイルアプリケーション。
頻繁なプロモーション/再設計とA/Bテストのあるプロジェクト。
マルチプラットフォーム製品（Web + iOS + Android）。
🧭 結論
Server-Driven UI は製品の実験を加速します クライアントリリースの数を減らします。UIが頻繁に変更され、アプリケーションを再パッケージ化せずにバリエーションをすばやくロールする必要がある場合に適しています。同時に、スキーマのバージョン管理とクライアントとサーバー間の責任の境界を検討することが重要です。
📚 このテーマについてもっと詳しく知りたいですか？
アプリで コディック さまざまなテーマの詳細なレッスン、ステップバイステップの練習、エラー分析、便利な練習をスマートフォンまたはブラウザで直接見つけることができます。
ニュース、新機能、役立つ資料を知りたい場合は、当社のニュースレターをご購読ください。 テレグラムチャンネル. そこは快適で、ビジネスに向いており、コードへの愛情が ❤️