Geekly Articles each Day

Webは何をフォローしますか？

最初の部分では、現代のWebプラットフォームをアプリケーションに置き換える方法を考える時が来たと主張しました。 その理由は、パフォーマンスの低下と、原則として解決できないセキュリティ問題です。

誰かが私があまりにも否定的に書きすぎて、ウェブの肯定的な側面に注意を払わないと決めた。 つまり、最初の部分は「私たちは深い穴に落ちたという事実を議論する」というスタイルであり、2番目の部分は「より良いものを開発する方法」でした。これは大きなトピックなので、2つの部分に限定されません。

競合他社をNewWeb Webと呼びましょう（ブランド設定は後で行うことができます）。 最初に、ウェブが最初に成功した理由を理解する必要があります。 Webは、最高のGUI開発ツールを備えた他のアプリケーション開発技術を迂回しているため、欠陥を上回るいくつかの品質を明らかに持っています。 これらの資質を満たさなければ、運命にある。

自動配置と区切り文字を備えたUIエディターであるMatisseでGUIを作成します。 （新しいスタイリッシュな）王様の長生き？

安さにも集中しなければなりません。 Webには多数の開発チームがあります。 彼らの仕事のほとんどは複製または破棄され、何かを再利用することができます。 小さな新しい開発も可能ですが、概して、NewWebテクノロジーは既存のソフトウェアから組み立てる必要があります。 貧しい人々は選択する必要はありません。


以下に、Webの5つの主要なプロパティの個人リストを示します。


これは、まさにアーキテクチャの主要な原則と見なされるものではありません。開発者にインタビューすると、ほとんどの開発者は、Web URLのアーキテクチャの本質を呼び出し、ソースコード、クロスプラットフォーム、HTTPなどを表示します。 しかし、これらはすべて実装の詳細にすぎません。 JavaScriptがとてもクールだからではなく、WebはDelphiとVisual Basicをより良くしました。 より深い理由があります。

上記のことは、原則として非常に理解しやすいものです。 記事の過程でそれらをより詳細に分析します。 ウェブを打ち負かすには、その強みを繰り返すだけでは十分ではありません。ウェブを簡単に統合できない独自の改善を提供する必要があります。 それ以外の場合は意味がありません。プロジェクトの代わりに、単にWebの改善に取り組みます。

この記事では、2つのことを提案します。特定のアーキテクチャの原則（私の意見では、Webの深刻な競合他社が従うべきもの）と、さまざまなオープンソースプロジェクトから収集した具体例です。 多くの読者は特定の例を好まないでしょう。なぜなら彼らは他のプロジェクトやプログラミング言語を好むからです。心配する必要はありません。 気にしません これは単なる例です-原則は本当に重要です。 これらの夢が完全に非現実的ではないことを説明するために、特定のコードベースを呼び出します。

建築の原則


少なくともアプリケーションに関しては、Webにはわかりやすいアーキテクチャの哲学がありません。 私の意見では、彼が欠けている必要なものは次のとおりです。

  1. アプリケーション識別子の明確な概念。
  2. バックエンドからフロントエンドへのデータの統一されたプレゼンテーション。
  3. バイナリプロトコルとAPI。
  4. プラットフォームレベルでのユーザーの認証。
  5. IDE中心の開発。
  6. コンポーネント、モジュール、および優れたUIレイアウトシステム-デスクトップコンピューターまたはモバイルデバイスの通常の開発と同じです。
  7. また、Webがうまく機能することも必要になります：ストリーミングアプリケーションをインストールまたは手動で更新せずに即座に起動し、これらのアプリケーションをサンドボックスに隔離し、複雑なUIスタイルを設定し、「ドキュメンタリー」と「ソフトウェア」素材を組み合わせて一致させる（特定のリンク機能など）アプリケーションの種類）、段階的なトレーニングの可能性、および開発者が複雑すぎるUIを作成することを妨げないアーキテクチャ。

太字の最初の4つのポイントはセキュリティに関連しています。これは、セキュリティの問題が原因でこのような急進的な立場を取ることを余儀なくされたためです。 おそらく、新しいJavaScriptフレームワークを使用すると、Webのパフォーマンスの低下を修正できる可能性があります。 しかし、セキュリティの問題は解決できるとは思いません。 後続の記事では、太字でない項目について説明します。

アプリケーション識別子とリンク


サンドボックスでのWeb展開と分離の利点を得るには、アプリケーション用のブラウザーが必要です。 アプリケーションの個々の部分をハイパーテキストドキュメントの一部として参照できると便利です。 これはウェブの成功の重要な要素です。Amazonの検索結果ページは何らかのアプリケーションのように見えますが、リンクできるので、ドキュメントでもあります。

ただし、アプリケーションブラウザは、物理的にWebブラウザに似てはなりません。 見直してください：WebブラウザーのUIは完璧ではありません。



URLはブラウザのデザインの重要な部分ですが、時には混乱を招くことがあります！

最初の問題は、URLがUIに侵入することです。 アドレスバーには、ブラウザのメモリからのランダムなビットが常に含まれており、人間とマシンの両方が理解するのが困難な形式でエンコードされ、悪用のパレードにつながります。 デスクトップアプリケーションがランダムな内部変数をタイトルバーにアンロードした場合、これは会社の評判を脅かす深刻なバグと見なされます。なぜここでこれを許容する必要があるのでしょうか。

2番目の問題は、マシンがURLを認識しにくいことです（ ここでクレイジーなエクスプロイトを作成することは可能です ）。 このようなcなトリックを考慮しなくても、アプリケーションのアイデンティティを確立するさまざまな方法がWeb上にあります。 Cookieストアを相互に分離し、発行されたアクセス許可を追跡するために、ブラウザーにはアプリケーションIDの特定の概念が必要です。 これが「ソース」（起源）です。 時間が経つにつれて、Web上のソースの概念が進化し、今では本質的に定式化することは不可能です。 RFC 6454はこれを実行しようとしますが、ドキュメント自体には次のように記載されています。

時間が経つにつれて、多くの技術が断熱材の便利なユニットとしてのソースの概念に収束しました。 ただし、Cookie [RFC6265]など、現在使用されている技術の多くは、Web上のソースの最新の概念よりも前に作成されました。 これらの技術には、しばしば異なる分離ユニットがあり、脆弱性につながります。

たとえば、サーバーが.comドメインのCookieを設定できない原因を考えてください。 kamagaya.chiba.jpはどうですか？ （これはWebサイトではなく、.comのような階層の単なるセクションです！）

予期せずアプリケーションの一部にリンクを配置する機能は、それから何の利益も得ず、それが「危険なリンク」の問題の原因の1つです。 高度なURL指向の設計により、アプリケーション全体が無許可のユーザーによるデータ注入のリスクにさらされます。 これは、対処がほぼ不可能であることが知られている設計上の制限ですが、Webアーキテクチャ自体によって快く奨励されています。

それでも、すべてが開発者の意図したとおりに機能する場合、ドキュメントからアプリケーションの中央へのリンクを作成する機能は非常に便利です。 そこで、いくつかの要件を策定します。

要件：アプリケーションID（分離）は単純で予測可能でなければなりません。

要件：アプリケーションへのディープリンクを配置できる必要がありますが、常にではありません。

彼らの功績として、Androidアーキテクトはこれらの要件を理解し、ソリューションを提案しました。 ここから開始できます：


URLと他の人の意図を自分のものと区別するために、他の人のリンクパッケージと呼びます 。

デフォルトで外部リンクの受信をオフにすると、NewWebのリンク接続性は低下しますが、セキュリティは向上します。 たぶんこれは悪い妥協であり、致命的になるでしょう。 しかし、現代のWebで人々が理論的に作成できる多くのリンクは、認証要件のため、または意味のある初期状態（多くのSPA）を含まないため、本質的には役に立ちません。 したがって、アプリケーションは攻撃領域を最小限に抑えます。 このような多数のエクスプロイトの開始点である悪意のあるリンクは、すぐに危険が少なくなります。 これは貴重な成果のようです。

しかし、他にも利点があります。Webアプリケーションのドメイン名の重要性は、 管理者が好ましくないドメインを没収する誘惑に駆られます。 単純なサイトは問題なく別のドメインに転送できますが、より複雑なサイトでは、メールアドレスやOAuthトークンなどの確立された評判を大事にすることができます。 秘密鍵は紛失したり盗まれたりする可能性がありますが、ドメイン名と同じです。 秘密鍵を紛失した場合-少なくともあなたのせいです。

ブラウザUIの残りの部分については、おそらくそれらを取り除くことができます。 タブは便利かもしれませんが、ページの再読み込みボタンは決して使用しないでください。また、理にかなっている場合は、iOSのように、前の状態に戻るためのボタンをアプリケーション自体に組み込むことができます。

アプリケーションブラウザーの作成方法 NewWebはWebとはまったく異なりますが、フルスクリーンアプリケーションの基本的なUIはかなり標準的なものであり、ユーザーは切り替える必要があります。 では、Chromiumをフォークして、新しいモードでタブを追加してみませんか？

（編集：上記を「ここにリストされているすべてにChromeを使用する」と思っている人はいません。タブ付きUIを使用して、NewWebとOldWebを隣で開くようにしました。ただし、タブUIは簡単に作成でき、Chromiumを使用する必要はありません。アプリケーションブラウザは、アプリケーションによってゼロから作成することもできます。

統一されたデータ表示


リンクパッケージの概念は少しぼやけているように聞こえるかもしれません。 これは何ですか 定義を明確にするために、データ構造が必要です。

ウェブ上でこれを行うには多くの方法がありますが、それらはすべてテキストベースです。 私の前回の記事の論文を思い出してください：テキストプロトコル（JSONだけでなく）には根本的な脆弱性があります：これは「インバンド」バッファーシグナリングです。つまり、データの終了位置を見つけるには、特定の文字シーケンスを検索してすべてを読む必要があります。 これらのシーケンスはデータの正当な部分になる可能性があります。つまり、スクリーニングメカニズムが必要です。 そして、これらのプロトコルは人間が読めるか、少なくとも読めないと想定されているため、空白処理や正規化されたユニコードに奇妙な境界線のケースがあり、HTTPヘッダー分割攻撃などの悪用につながります。

昔、テキストプロトコルはWeb開発者を支援していました。 情報源を見ると、数え切れないほど何度も助けになりました。 しかし、現在では、Webアプリケーションはもちろんのこと、Web ページの平均サイズは2メガバイトを超えています。 静的なテキストを含む退屈なWebページでさえ、多くの場合、機械の助けがなければ理解することさえできない多くの縮小されたスクリプトを含んでいます。 テキストプロトコルの利点は、従来よりも小さいようです。


プリミティブデコンパイラ

正直に言うと、近年、Webはテキストプロトコルを徐々に放棄しています。 HTTP / 2バイナリ。 そして、広く知られている「WebAssembly」は、コードを表現するためのバイナリの方法ですが、私たちが話した問題を実際に解決するわけではありません。 しかし、それでも。

要件：データシリアル化は、データウェアハウスからフロントエンドまで、自動的に入力され、バイナリで変更されない必要があります。

シリアル化のためのコードは書くのが面倒であるだけでなく、深刻な攻撃経路でもあります。 優れたプラットフォームが課題に取り組むべきです。 データ構造を表現するための最も原始的な構文を定義しましょう。

enum SortBy { Featured, Relevance, PriceLowToHigh, PriceHighToLow, Reviews } @PermazenType class AmazonSearch( val query: String, val sortBy: SortBy? ) : LinkPacket

ウェブでは、同等のものはamazon.comのURLです。 特定の状態でアプリケーションを開く要求を示すために、不変型のデータ構造を定義します。

このデータ構造は@PermazenTypeとしてマークされてい@PermazenType 。 これはどういう意味ですか？

接頭辞付きの長さ、スタック全体へのインジェクションに対する強力な型保護を備えたコードを使用する場合、SQLで何かをする必要があります。 構造化クエリの言語は、さまざまな非常に強力なデータベースエンジンに複雑なクエリを表現するための優れた、よく理解された方法なので、残念です。 ただし、SQLはテキストAPIです。 SQLインジェクションは、簡単に理解して修正できる最も単純なタイプのエクスプロイトの1つですが、Webサイトで最も一般的なバグの1つでもあります。 不思議ではありません：Webサーバーで最も明白な方法でSQLを使用すると、SQLは正常に機能しますが、サーバーを静かにハッキングに対して脆弱にします。 パラメータ化されたクエリは役立ちますが、これは、すべての状況で使用できるわけではない側面のめちゃくちゃなソリューションです。 技術の積み重ねは、私たち全員にとってよく隠されたクマのわなを作り出し、私たちの目標は、機能とリスクの比率を最小限に抑えることです。

SQLには他にもいくつかの問題があります。 オブジェクトリレーショナルマッピングの問題がすぐに発生します。 SQLクエリの結果をHTTP接続経由でネイティブに送信したり、Webページに埋め込んだりすることはできないため、別の形式への変換が常に必要になります。 SQLは、基になるクエリのパフォーマンスをユーザーから隠します。 バックエンドのスケーリングは困難です。 多くの場合、スキーマの変更にはテーブルのフリーズが必要であるため、許容できないダウンタイムなしでは展開できません。

NoSQLエンジンはそれほど優れたものではありません。通常、これらの問題の1つまたは2つを修正しますが、それ以外のすべてのためにSQLソリューションを破棄します。 その結果、多くの場合、異なる決定を迫られますが、必ずしも最良とは限りません。 その結果、GoogleやBloombergなどの大手企業は、SQLデータベース（ F1 、 ComDB2 ）をスケーリングする方法を見つけるために多くの時間を費やしています。

Permazenは、現在私にとって魅力的なデータストレージへの新しいアプローチです。 彼らのウェブサイトからの引用：

Permazenは、永続的なプログラミングに対するまったく新しいアプローチです。 ストレージテクノロジの一部で開発を開始する代わりに、彼はプログラミング言語の一部から始めて、次の簡単な質問をします。そして言語の面で最も自然な方法で？」

PermazenはJavaライブラリです。 ただし、そのアーキテクチャと技術は、任意のプラットフォームまたは言語で使用できます。 彼女は、多くのクラウドプロバイダーが提供できる種類のソートされたキーと値のストレージを必要とします（K / VストレージとしてRDBMSを使用することもできます）が、他のすべてはライブラリ内で行われます。 彼女にはテーブルもSQLもありません。 代わりに、彼女：


実際、素晴らしいレポートを読むか、スライドを見るだけです（スライドはライブラリの古い名前を使用しますが、これは同じソフトウェアです）。 Permazenはあまり知られていませんが、これまで見たデータウェアハウスとオブジェクト指向言語を緊密に統合するための最も賢明で最も賢いアプローチです。

Permazenの興味深い機能の1つは、トランザクションスナップショットを使用してオブジェクトグラフをシリアル化および逆シリアル化できることです。 このスナップショットにはインデックスも含まれます。つまり、十分なメモリがなければローカルストレージにデータをストリーミングでき、すでにインデックスクエリを実行できます。 ここで、オフライン同期のサポートにより、このライブラリがデータストレージをどのように統合するかが明らかになるはずです。 Permazenのすべての操作はシリアル化可能なトランザクション内で実行できるため、競合の解決はトランザクションで実行できます（操作可能な変換ライブラリを必要とするGoogleドキュメントのスタイルで競合のない作業が必要な場合）。

NewWebはそのようなアプローチを使用する必要はありません。 protobufのようなもう少し伝統的なものを選択できますが、すべての言語で同様に不便な特別なIDLとタグフィールドを使用する必要があります。 CBORまたはASN1を使用できます。 現在のCordaプロジェクトでは、AMQP / 1.0上に構築された、オブジェクトをシリアル化する独自のエンジンを作成しました。 デフォルトでは、メッセージはそれ自体を説明するため、特定のバイナリパッケージごとに常にスキームを取得します。したがって、XMLやJSONのように、ソースコードを表示する機能があります。 AMQPはオープンスタンダードであり、基礎となる型システムが非常に優れているため（たとえば、日付と注釈を認識するため）AMQPが推奨されます。

ポイントは、潜在的に有害なソースからデータを受信するのは危険であるということです。そのため、形式と完全性チェックの最大数内でできるだけ多くの自由度を取得することが望ましいです。 すべてのバッファーには長さのプレフィックスが必要であるため、ユーザーはフィールドに悪意のあるデータを挿入しようとすることはできません。そのような試みは早期に停止します。 ロード中にデータを慎重にチェックする必要があります。このようなチェックに最適な場所は、型システムとデータ構造自体のコンストラクターです。これは、すでに忘れているかもしれません。 ダイアグラムは、構造がどうあるべきかを理解するのに役立ち、侵入者がタイプミキシングを使用するのを防ぎます。

提案されたスキームは絶対にバイナリであるにもかかわらず、デバッグや教育目的でテキストへの一方向の変換を実行することは可能です。 実際にパーマゼンとそれが可能です。

シンプルさと段階的な学習


型システムには1つの問題があります-複雑さが増します。 型に出会っていない開発者にとって、彼らはある種の無意味な官僚主義のように見えます。 また、適切なツールがないと、バイナリプロトコルを学習してデバッグするのが難しくなります。

要件：習得が簡単

ウェブの成功の大部分は、それが本質的に類型化されていないという事実によるものと確信しています。 ここのすべては単なる行です。 安全性、性能、および保守性には劣りますが、トレーニングには非常に適しています。

Webの世界でこのような構造を処理する1つの方法は、JavaScriptバージョンで段階的に入力することです。 これは優れた貴重な研究作業ですが、そのような方言は広く使用されておらず、新しい言語のほとんどは少なくとも部分的に強く型付けされています（Rust、Swift、Go、Kotlin、Ceylon、Idris ...）。

この要件を満たすもう1つの方法は、スマートIDEです。開発者が最初に型指定のない構造（ Anyとして定義されているもの）で作業できるようにすると、ランタイムは元の型を決定し、この情報をIDEに変換しようとします。 その後、彼女は最適なタイプの注釈の代替を提案できます。 開発者がプロ​​グラムの実行中に型変換エラーに遭遇した場合、IDEは制限を再度緩和するよう提案する場合があります。

もちろん、このアプローチは、開発者に事前に型を検討させるよりもセキュリティが低く、メンテナンスが容易ですが、ランタイムエラーにつながることが多い比較的弱いヒューリスティックな型でさえ、多数の悪用から保護します。 JVMやV8などのランタイム環境は、すでにこの種のタイプ情報を収集しています。 Java 9には、仮想マシンを低レベル（JVMCI）で制御できる新しいAPIがあり、そのようなプロファイリングに取り組んでいます-そのようなツールで実験するのがはるかに簡単になります。

言語と仮想マシン


NewWebはどの言語を使用する必要がありますか？ もちろん、これは簡単な質問ではありません。プラットフォームが芸術的になるべきではありません。

長年にわたり、JavaScript以外の言語をWebに導入する試みが数多く行われてきましたが、それらはすべて、ブラウザー開発者（主にMozillaから）のコンセンサスを得ることなく成功していません。 実際、この点でWebは過去に戻っています。Java、ActionScript、VBScriptなどの言語を実行できますが、ブラウザーメーカーはすべての非JavaScriptプラグインをプラットフォームから体系的に削除しました。 これは少し残念です。 もちろん、競争を維持することは可能でした。 Webプラットフォームに対する悲しい文章は、WebAssemblyが新しい言語を追加する唯一の試みであり、その言語はCであるということです...その中で、Webアプリケーションを書きたくないと思います！ XSSは、上から同じメモリを二重に解放するなどの脆弱性を追加するのに十分です。

解決策よりも問題を受け入れる方が常に簡単ですが、大丈夫です-（より多くの）矛盾する論文を提出する時が来ました。 私の個人的なNewWeb設計の中核はJVMです。 これは私を知っている人を驚かせるものではありません。 なぜJVMなのか？


多くの人が私の選択に同意しないことを理解しています。 問題ありません-PythonやV8、Go、Haskellなど、あなたが浮かんでいるものに基づいて同じアーキテクチャのアイデアを実装できます。 オープン仕様で競合する実装（JVMなど）が存在するものを選択することをお勧めします。

Javaにはオープンソースがあるため、Oracleポリシーは気にしません。 高品質で高性能なオープンソースランタイムの中には、選択肢がほとんどありません。 既存のプロジェクトは、過去に物議を醸す決定に不満を抱いた大企業によって作成されています。 開発のさまざまな段階で、WebはMicrosoft、Google、Mozilla、Appleの影響を受けたり直接制御されたりしました。 それらはすべて、私が非難できると考える行為をコミットしました。これは大企業の特徴です。 あなたは彼らの行動に常に同意したくありません。 オラクルが人気コンテストに勝つことはまずありませんが、オープンソースの利点はそれに参加する必要がないことです。

具体的には、Google Chromeから何かを借ります。 私のアプリケーションブラウザはWebGL（eGLなど）と同等のものをサポートする必要があり、Chromium ANGLEプロジェクトはこの目的に適しています。 アプリケーションブラウザーは、Chromeのようにサイレントに自動的に更新する必要があり、Google自動更新エンジンも無料ライセンスで配布されます。 最終的に、Pack200形式はコードを大幅に圧縮しますが、 Zopfliのような高品質のコーデックを使用しても害はありません。

RPC


バイナリデータ構造では不十分です。 バイナリプロトコルも必要です。 クライアントをサーバーに接続する標準的な方法はRPCです。

現在、英国で最もクールなスタートアップの1つはImprobableです。 開発者は最近、ブラウザからサーバーにREST + JSONからgRPC + protobufに切り替えた方法に関する素晴らしいブログ投稿を投稿しました 。 あり得ないことは、結果を「安全なタイピングのir」と説明しています。 ブラウザは、HTTP + XMLまたはJSONほど簡単にこれに対処できませんが、必要なJavaScriptライブラリを使用して、必要なスタックを一番上に固定できます。 それは良い考えです。 私たち全員がWebアプリケーションを作成する現実の世界に戻った場合、このオプションを必ず検討する必要があります。

RPCプロトコルは既存の経験を使用する必要があります。 私の理想的なRPCは以下をサポートしています：


繰り返しますが、Cordaプロジェクトでは、まさにこれらのプロパティを持つRPCスタックを設計しています。 個別のライブラリとしてはまだリリースしていませんが、将来的にはリリースする予定です。
HTTP / 2は、Webの最新かつ最も精巧な部分の1つであり、かなりまともなフレームトランスポートプロトコルです。 しかし、彼はHTTPスラッシュから多くのジャンクを継承しました。 とにかく決して使用されないHTTPメソッドを放棄すると、ハッキングが可能になることを想像してください 。 状態を記述するための奇妙なHTTPアプローチは必要ありません。 HTTP自体は実行中に状態を変更しませんが、アプリケーションはステートフルセッションを必要とするため、アプリケーション開発者は、簡単に盗むCookieやトークンなどのミッシュマッシュを使用して、プロトコルの上に独自の実装を追加する必要があります。 これは、 セッションコミット攻撃などの問題を引き起こします。

すべてをより明確にレイヤーに分割することをお勧めします。


明らかに、RPCスタックはデータ構造フレームワークと統合されているため、すべてのデータ転送が入力されます。 開発者が手動で解析を行う必要はありません。 RPCの命名は、単純な文字列比較です。 したがって、現在のディレクトリを終了することによる脆弱性はありません（パストラバーサル）。

ユーザー認証とセッション


NewWebはCookieを使用しません。 セッションの識別には、公開鍵と秘密鍵のペアが適しています。 Webはこの方向に進みますが、既存のWebアプリケーションとの互換性を維持するために、Cookieなどの所有者のトークンがホスト暗号化セッションに接続される複雑な「バインディング」ステージが必要です。これにより、重要なセキュリティコンポーネントがさらに複雑になります。完全な再設計。 セッションは、公開鍵によってのみサーバー側で識別されます。

ユーザー認証は、Webアプリケーションに適切に実装するのが難しい最も難しいことの1つです。 以前にこのテーマについていくつかの考えを述べたので、繰り返しはしません。 アプリケーションレベルでホイールを常に再発明するよりも、セッションをベースプラットフォーム側のメールアドレスにバインドする方が良いと言えば十分です。 クライアント側のTLS証明書は、基本的なシングルサインオンシステムを実装するのに十分であり、「レターを送信し、受信した場合は証明書に署名する」などのワークフローは非常に安価であるため、Let's Encryptスタイルの無料証明書のプロバイダーは非常に現実的です。

このアプローチは既存のテクノロジーに基づいていますが、フィッシング、パスワードによるデータベースのクラッキング、ブルートフォース、およびその他の多くのセキュリティ関連の問題を大幅に削減します。

おわりに


Webと競合したいプラットフォームは、セキュリティの問題に真剣に取り組む必要があります。これは、その作成と競争上の優位性のための最も重要な正当化であるためです。 これは、ウェブ上で簡単に修正できない主なものです。 つまり、安全なタイピングとバイナリAPIを備えたバイナリデータ構造、RPC、暗号化セッション、ユーザー識別が必要です。

また、新しいWebには、サンドボックスとストリーミングコンテンツでのコード分離、優れたレイアウトを備えたUIがありますが、同時に応答性が高く、スタイルがサポートされています。Webと同じようにドキュメントとアプリケーションを混在させる方法、および非常に生産的な開発環境です。新しいウェブのポリシーも検討する必要があります。

これらの問題については、次の記事で説明します。

Source: https://habr.com/ru/post/J339112/

More articles:


All Articles