バックエンド主導の開発

アプリケーションの開発に関しては、UI またはユーザー インターフェイスという用語が頻繁に使用されます。顧客がアプリを開いて最初に目にするのは、アプリケーションがどのように設計されているかということです。これが Web 開発の非常に重要な側面であることは理にかなっています。シンプルで使いやすい UI は、Web アプリのコンバージョン率をほぼ 200% 向上させることができます。 UI は、ソフトウェア開発プロセスの不可欠な部分です。

ユーザー インターフェイスは主に顧客が見るものに関連するため、フロントエンド エンジニアによって開発されます。 React.js、フラッターなど、いくつかの フロントエンド フレームワーク を使用すると、美しいユーザー インターフェイスを簡単かつ効率的に開発できます。ただし、従来の開発は、特に更新に関しては、長いプロセスになる可能性があります。 Apple ストアや Google Play ストアなどのアプリ ストアでは、開発者が大きな UI 変更を実装する場合、多くの場合、長いプロセスを経る必要があり ます。これは、SDUI、またはサーバー主導のユーザー インターフェイス アプリ開発が違いを生むことができる場所です。

サーバー駆動型の UI またはバックエンド駆動型の開発 はゲーム チェンジャーになる可能性があり、その仕組みはブラウザーが HTML や CSS などの言語を処理する方法と非常によく似ています。しかし、SDUI の仕組みとその利点について説明する前に、バックエンドまたはサーバー主導の UI が実際にどのようなものかを見てみましょう。

サーバー駆動型 UI とは?

アプリまたはサービスのユーザー インターフェースは、その外観と操作性を指します。 UI デザイナーは、アプリの個々の側面がどのように表示されるか、美学、および複数のデバイスでの Web ページの応答性に関心を持つ必要があります。これは、消費者がサイトに関与するホーム画面の領域であるためです。

Web サイトのユーザー インターフェイスは、HTML コードによって定義されます。サーバー側の UI 開発を採用しているサイトにアクセスすると、顧客はこのコードをすぐに受け取ることができます。ユーザーがこのようなアプリを使用すると、サイト、デザイン、CSS、 JavaScript 、およびサイト内の素材が元のリクエスト中に読み込まれます。

モバイル アプリの従来の開発では、プログラマーがリリース サイクルでユーザー インターフェイスのデザインと外観を設計およびパッケージ化します。ソフトウェア パッケージは、Google Play ストアなどのアプリ ストアにアップロードされ、顧客がダウンロードできるようになる前にレビューされます。このようなアプリのユーザー インターフェイスは、UI を表示するコンテンツから切り離すことでインタラクティブになります。ユーザー インターフェイスはアプリのコードのコンポーネントですが、多くの場合、情報はサーバーまたはバックエンドからダウンロードされ、UI に組み込まれます。これは、更新時のリリース サイクルの通常のケースです。

開発者がアプリにいくつかの主要なユーザー インターフェイスの変更を追加する必要がある場合を考えてみましょう。上で述べたように、開発者はこれらの変更を導入するためにリリース サイクル全体を経る必要があります。これは、情報の表示方法を決定するロジックがプログラムのホーム画面に統合されているためです。このリリース サイクルで必要な改善を行った後、レビュー、テスト、プレイ ストアの承認をもう一度受ける必要があります。 iOS と Android の両方のプラットフォームでアプリをリリースする必要がある場合は、リリース サイクルを 2 回完了する必要があります。これは長いプロセスになる可能性があり、異なる言語でコーディングする必要があるため、2 つのプラットフォーム用に別々の開発者が必要になる可能性が高くなります。マイナーな UI の変更でも、リリース サイクル後にユーザーに届くまでに数か月かかる場合があります。

クライアント側レンダリングとの違い

従来の開発では、クライアント側のレンダリングを利用しています。ここでは、クライアントがリクエストを行った後に、ページ デザイン、CSS、および JavaScript が取得されます。特定のコンテンツが含まれない場合があり、必要な HTML を生成するために JavaScript が追加のリクエストを実行する必要があります。

このアプローチには利点がありますが、更新に関しては上記の問題に直面します。ただし、場合によっては便利です。たとえば、クライアント側レンダリングを使用しているときに Web サイトのほんの一部が変更された場合、ページ全体を再レンダリングする必要はありません。クライアント側の UI レンダリングでは、必要なすべてのデータが完全に読み込まれていることを確認します。これにより、クライアント側の UI は非常に迅速かつ応答性が高くなります。また、クライアント側のレンダリングにより、ユーザーをインタラクティブに引き付けることができます。

サーバー側のレンダリングの場合、アプリのクライアント側とサーバー側の両方で同じスクリプトを保持する必要があります。これにより、運用コストが高くなり、開発が遅れる可能性があります。ユーザーフレンドリーなクライアント側アプリケーションは、高度なパフォーマンスを提供します。ただし、必要な JavaScript スクリプトの読み込みが完了した場合のみです。そのため、携帯電話を使用している場合や、そのようなアプリケーションでインターネット接続が遅い場合、パフォーマンスの問題が発生する可能性があります。また、現在利用できるモバイル デバイスが多様であるため、クライアント側のレンダリングがどのように機能するかを予測することも難しくなっています。開発者は、Ember.js、backbone.js などのライブラリを使用してクライアント側の UI を構築します。

サーバー駆動型 UI の利点

サーバー駆動型のユーザー インターフェイスの最終製品は、クライアント側の UI と何ら変わりはありません。では、SDUI が提供する利点は何でしょうか?

迅速な更新

開発者がアプリを更新する必要がある場合、SDUI には多くの利点があります。新しいアップデートのリリース サイクルには、最大で数週間かかる場合があります。これは SDUI で高速化できます。エンジニアは、バックエンドまたはサーバー側のアップグレードを使用するだけで済みます。新しいコードを作成していないため、テストする必要はありません。リリース サイクルでは、アプリの更新バージョンを Google Play ストアなどのアプリ ストアに送信する必要もありません。したがって、Apple や Google からの承認は必要ありません。以前は数か月または数週間かかっていた変更が、数時間または数日で完了できるようになりました。リリース サイクルにおけるこれらの変更は、変更がサーバーに直接加えられるため、iOS アプリと Android アプリの両方に反映されます。

実装が容易

開発者が静的な Web ページを作成している場合、バックエンドまたはサーバー主導の戦略は通常より単純です。また、Web サイトは静的な HTML を作成し、検索エンジンがその素材を参照できるようにするため、潜在的な SEO の問題について気にする必要もありません。ブラウザーの作業を減らすことで、予期しないバグの可能性も減少します。

より簡単なソーシャル メディアのインデックス作成

検索エンジンのクローラーと同様に、ソーシャル メディア ボットは JavaScript の内容を解析できません。たとえば、Twitter カードはクライアント側のレンダリングをサポートしていません。ソーシャル ネットワーキングの共有がマーケティング プランの重要な要素である場合は、サーバー側のレンダリング アプローチが適しています。アプリのサーバー主導のレンダリングも、複雑さが軽減され、より安全になります。これを詳しく見てみましょう。

複雑さの軽減

特定の条件下では、バックエンドまたはサーバー駆動型のユーザー インターフェイス開発を使用すると、フロントエンドおよびバックエンド部門よりもはるかに単純になる場合があります。開発者の観点から見ると、サーバー主導の UI 開発は認知ストレスを軽減します。 2 つのプログラミング環境を考慮する必要がないため、開発者は、作成しているアプリケーションの付加価値により集中できます。重複の排除により、これらのアプリケーションの複雑さも大幅に軽減されます。検証ロジックは 1 つの場所で処理されるため、バックエンド API ソフトウェアと UI ソフトウェアを識別する必要はありません。

安全

サーバー主導の UI 開発では、その仕様がブラウザーに表示されることはなく、ユーザー インターフェイスの変更に必要な正確なデータのみが提供されます。プログラマーが特定の UI 連絡先に適切なデータを伝えるシナリオと比較すると、これは本質的により安全な開発戦略です。その結果、API エンドポイントが JavaScript ブラウザーに多くの情報を開示することはありません。これにより、ハッキングやデータの侵害が発生しにくくなります。これは、会社の評判を維持するために非常に重要であり、ビジネス ロジックに不可欠です。

フルスタックチーム

多くの場合、開発チームは複数のチームに分割されます。これには、個々のコンポーネントが完成したら、さまざまなソフトウェア部分をある程度統合する必要があります。フロントエンドとバックエンドを厳密に分離すると、さまざまな分野で専門的な知識が必要になるため、チーム間にある程度の断絶が生じる可能性があります。これにより、開発者はエンド ツー エンドのビジネス ロジック全体を検討することがより困難になります。

あなたがフルスタックのエンジニアであれば、これははるかに簡単に対処できます。 UI コンポーネントの潜在的な欠点や利点は簡単に理解できます。フルスタックのチームはサーバー主導の UI 開発を実装でき、統合の必要性をある程度減らすことができます。

サーバー駆動型 UI の欠点

バックエンドまたはサーバー駆動型のレンダリングを使用することは単純な概念のように思えますが、アプリケーションとビジネス ロジックが複雑になるにつれてアイデアの深さが増します。サーバー駆動型のユーザー インターフェイスに関連する主な欠点のいくつかは次のとおりです。

より長いロード時間

サーバー主導のレンダリングの根本的な欠点は、クライアントとの接続ごとにサーバーまたはバックエンドが新しい Web ページを作成することです。その後、クライアントはこのページへのアクセスを再度許可される必要があります。このようなアクティビティは、応答性の欠如や読み込み時間の大幅な増加につながる可能性があります。バックエンドまたはサーバー側のレンダリングは、静的な HTML サイトの作成には適していますが、定期的なサーバー呼び出しのために、より複雑なアプリケーションでは Web ページまたはホーム画面の表示が遅くなる可能性があります。

もっと高い

サーバー駆動型アプリケーションを起動するには、サーバーまたはサーバーレス バックエンドを取得する必要があり、運用コストが増加します。サーバー主導のレンダリングは JavaScript Web ページの標準ではないため、プロセスは高価でリソースを大量に消費する可能性があります。中小企業は、そのようなサーバーの資金を節約するのが難しいと感じるかもしれません。

非互換性と大きい HTML サイズ

サーバー側のレンダリングは、一部のサードパーティ ツールおよびプログラムと互換性がありません。サーバー駆動型アプリケーションは、ハイドレーション条件が統合されているため、HTML サイズも大きくなります。これは、不適切に適用されるとリスクが生じる可能性があるため、考慮に入れる必要があります。

サーバー駆動型 UI の歴史

コンピューターは大規模で高価で、1960 年代から 1970 年代にかけて主に大企業で使用されていました。各ユーザーが部屋の幅のコンピューターを持つことは現実的ではなかったため、メインフレーム テクノロジが作成され、複数の人がコンピューター システムを使用できるようになりました。端末コマンド計算の出力を使用して作成されたユーザー インターフェイスは、表示のためにモニターに戻されました。これらの端末が最初のシン クライアントになりました。シン クライアントは、計算能力が非常に限られていることと、ユーザー インターフェイスを生成するために外部マシンに依存していることから、そう呼ばれていました。

パーソナル コンピューターは、1970 年代後半にマイクロプロセッサが開発された結果として作成されました。これにより、コンピューターの価格とサイズが大幅に削減されました。アプリケーションは、各ユーザーのブラウザで個別にダウンロードして操作しました。 PC は、ユーザー インターフェイスを表示するために必要なすべてのコンポーネントを備えたスタンドアロンのコンピューターでした。これらの完全自律型ワークステーションは、最初のシック クライアントです。

1990 年代にインターネットが普及したおかげで、Web ブラウザーで表示される Web サイトまたはアプリケーションは、シン クライアントの多くの利点を享受できました。 Web ブラウザーとインターネット サービスを持っている人なら誰でも、サーバーと呼ばれる専用コンピューターに集中的に配置された計算機能を使用できました。サーバーは、標準のマークアップ言語である HTML を使用してユーザー インターフェイス アプリを作成し、それをユーザーの Web ブラウザーに送信しました。リモート ブラウザごとに Web ブラウザをセットアップする必要がありましたが、必要なパフォーマンスははるかに低く、多くの場合、組織の運用上の問題を解決できました。

携帯電話は 2000 年代に進歩し始め、独立してアプリケーションを実行できるようになりました。携帯電話をシン クライアントとして使用して Web ページを表示する場合、サーバーまたはバックエンドは、パーソナル コンピューターの場合と同様に、ユーザー インターフェース アプリ全体をインターネット経由で携帯電話に送信する必要がありました。しかし、この時、モバイル ネットワークは低迷していました。そのため、ウェブページを閲覧するのはイライラしていました。

2007 年に登場した iPhone は、スマートフォンでできることに革命をもたらしました。 iPhone は、ユーザーが Web サイトやアプリケーションからソフトウェアを取得する必要がなく、完全なプログラム セットがインストールされた状態で出荷されました。 Apple は App Store を導入し、Android は Google Play ストアを採用して、外部の開発者がアプリケーションを作成できるようにしました。これらのアプリは、UI を表示するために必要なすべてがアプリケーションに含まれており、インターネット サービスなしで使用できるため、はるかに優れたユーザー エクスペリエンスを提供しました。

過去 40 年間、ソフトウェア配布はシン クライアントとシック クライアントの間で交互に行われ、シック クライアントであるネイティブ アプリがモバイルで優勢でした。シン クライアントの利点の一部は、SDUI によってネイティブ アプリに拡張されます。 SDUI 開発戦略により、サーバーはネイティブ アプリのユーザー インターフェイスの一部を制御し、Web 経由でユーザーのスマートフォンに送信できます。新しいバージョンのソフトウェアをインストールしなくても、ネイティブ アプリケーション内の UI をすばやく変更できます。

サーバー駆動型開発のためのフレームワークとツール

サーバーはアプリケーションのサーバー主導のレンダリングを実行しますが、クライアント側のレンダリングはブラウザによって実行されます。現在利用可能なさまざまなフレームワークがあり、最も使用されているもののいくつかは次のとおりです。

• Vue.js

これは無料でオープンソースの JavaScript UI フレームワークであり、他の特定のツールと組み合わせて、オンライン アプリケーション用のフルスタック開発環境を作成できます。

• React.js

これは、再利用可能なユーザー インターフェース アプリ要素とそれらの単純な構成を作成して、大規模で高度にスケーラブルなプログラムを構築できるようにする JavaScript ツールキットです。

• 角度

Angular Universal は、バックエンドまたはサーバー主導の開発ツールです。

サーバー主導の UI と AppMaster

今日では、コーディングの経験がほとんど、またはほとんどなくても 、アプリやプログラムを作成 できます。これは、 ノーコード プラットフォームとツールの助けを借りて可能になります。このようなプラットフォームにより、開発者と非プログラマーの両方が、従来のコンピューター プログラミングではなく、ユーザー インターフェイスと構成を使用してソフトウェア アプリを作成できます。ノーコードにより、ソフトウェアの開発がより簡単になり、アクセスしやすくなりました。

これは、AppMaster のようなノーコード プラットフォームの助けを借りて可能になります。 AppMaster を使用すると、コーディングの経験がなくてもアプリを設計できるようになりました。また、作成したソース コードの権利について心配する必要はありません。それはあなたに属します。このコードも高速に生成できます。

AppMaster のサーバー主導の戦略により、リアルタイムのアプリ更新が可能になります。バックエンドまたはサーバー主導の UI を使用して、iPhone や iPad などのデバイスのハードウェアに直接アクセスできます。アプリは、従来の開発と UI の更新を使用するよりも、ほぼ 10 倍早く市場に投入されます。 AppMaster を使用して、バックエンド主導の UI 開発のユーティリティを活用できます。

結論

サーバー駆動型開発がアプリケーションに適しているかどうかの最終的な問題は、その機能によって異なります。アプリが動的で多くの要素がある場合は、SDUI を使用することをお勧めします。上記の利点以外に、SEO ランキングで Web サイトやアプリケーションにも役立ちます。サーバー主導のユーザー インターフェイス開発を実装する前に、その長所と短所を理解することが重要です。 SDUI はより多くのリソースを必要とする場合があり、同じものを使用している場合はそれらを提供する立場にある必要があります。

高速に読み込みたい静的 Web サイトを構築するだけの場合は、より単純なクライアント側開発を使用する方がよい場合があります。最終的には、アプリケーションのニーズと実装しているビジネス ロジックを評価し、バックエンドまたはサーバー駆動型の開発が適切かどうかを判断する必要があります。