connecting...
Google translation for articles :
1 NEMBER donated to you!!

NEM Blockchain SDKにReactiveXを使用する理由 (開発者Aleix氏の投稿和訳と所感)

nem8.45xem (1) 361 0 0
44uk_i3 2018-09-23 11:16:40

先日(といってももう数日経っていますが)、nem-library 開発者である Aleix 氏が投稿した、

Why ReactiveX for NEM Blockchain SDKs – Aleix Morgadas – Medium

(NEM Blockchain SDK に ReactiveX を使用する理由)

という記事を読み、機械翻訳と若干の手修正したものと所感を述べてみます。

和訳

貼り付けの都合で画像は省略してしまいました。

不便で申し訳ないですが、元記事と突き合わせていただければと思います。


ReactiveX以前

NEM Blockchainで開発を始めたとき、Futures/Promisesと一種の暗号化機能に基づくAPIラッパーを用意しました。

NEM Blockchainの開発を開始するには、ブロックチェーンの概念に精通していれば十分でした。数週間で実用的なアプリケーションを提供することができました。NEMで開発するのは簡単だったように見えました。

しかし、当時の生産現場でアプリケーションを使用するときに問題が発生したため、知識が不足していてテストできていない、すべてのケースで防御プログラミングを追加する必要がありました。(あなたが接続しているノードのことではありません)。

私たちはこの問題を防げたでしょうか?当時、私たちは初心者でした(そしておそらく未だに)。ほとんどの場合、あなたが壁にぶつかるまで、誰もあなたに警告しません。

Blockchain開発の本質(その一部)を理解する

  1. あなたはネットワーク内で一人ではありません 。予期しない方法で他の人があなたとやりとりすることを予期してください。
  2. ネットワークは常に稼働しているが、ノードはそうではありません 。実行時にノードを切り替えることが必要です。
  3. 論理遅延 。セキュリティ上の問題についていくつかのビジネスロジックを適用できるようになるまで、いくつかのブロックを待つ必要があります。
  4. ネットワーク待ち時間 。積極的にキャッシュしないと、アプリケーションは遅く、非常に遅くなります。ほとんどのリクエストは同じ結果を返します。TPSだけではありません。
  5. 変更に反応する 。ほとんどの場合、トランザクションをアナウンスするのではなく、特定のアカウントに新しいブロックや新しいトランザクションのようなチェーンの更新に積極的に反応したいはずです。

これらは、SDKなどで解決しようとしている特質です。

イベントベースであること

ブロックチェーンアプリケーションをデータベースの代わりにイベントストリームとしてモデル化します。ビジネスロジックのほとんどは、確認された新しいトランザクション(イベント)または新しいブロック(別のイベント)に基づいて行われます。

可能であれば、非ブロッキング実装でイベントストリームを非同期で処理するソフトウェアが必要でした。

Futures/Promiseベースでは、その問題を解決することができなかったのか?

ReactiveXを使わなくても同じ問題を解決することは可能ですが、リクエストの再試行やエラー処理など、車輪の再発明をするよりも、ビルドするほうがずっと簡単です。しかし、最も重要な特徴は、Promiseは一度しか度解決しない、ObservableはN回解決するということです。

NEMは、事象Xがチェーン内で発生するたびに通知されるWebSocketインターフェイスを提供するので(アカウント、新しいブロックなどで確認された新しいトランザクション)、WebSocketおよびHTTP APIとやりとりするために同じメソッドを提供したかったのです。

ReactiveXは、 WebSocket→n回のイベントHTTP API→1回のイベントの両方のケースを統一します。どちらも同じ方法で共有します。

承認済みトランザクションを扱う際の共通のシナリオのコードを共有しましょう。お気づきでしょうが、取引所を使用する際にはトランザクションがブロックに含まれた後にNブロックを待ちます。理由はここで確認してください 。

サンプルコードは、ブロックチェーンがどのように動作しているかをReactiveXと組み合わせることがどれほど強力であるかを示しています。

重要なコード行は14〜20です。以下説明(TypeScript、RxJSとNEMに慣れている必要があります):

  1. アドレス(14-15)が与えられた承認済みのトランザクションがあれば、
  2. 新しいブロックを監視し始める(17)
  3. 次のN個のブロックイベントを無視する(18)
  4. 1つのイベントのみを取得する(19)
  5. info(20)のブロック高さのトランザクションを返します。
  6. 特定のビジネスロジックを適用する(22-26)
  7. どこかのステップで起きた何かのエラーを処理します(26-28)

コードが不完全であるため、確認済みのトランザクションがブロック内にまだ存在することを確認する必要があります。このロジックは、19行と20行の間になければなりません。

このフィーチャ/ロジックをSDK内に含める必要があります(そう、必要なんです)が、デモンストレーションの目的で私たちはこのロジックを自分で処理します。

誰かがPromiseを使った同様のコードを共有したいのであれば、記事でそれを共有したいと思っています。

すべてのコードはこちら 。

Observablesを公開するのはなぜ重要なのでしょうか?

サンプルコードは、ネットワークイベント/データを処理する方法を示していますが、さらに理由があります。

NEMデザインの使い方の考え方を知るためには、NEMデザインに精通していなければなりません。

NEMのコンセプト

NEMのデザインとは、1つのタスクだけをうまく実行し、それらのコンポーネントを組み合わせてより大きな機能を実現するコンポーネントを作成することです。

NEMのアプローチは、よくチェックされたコンポーネントを提供し、チェーンチェーン上のスマートコントラクトを提供するのではなく、ブロックチェーンが解決する主要なユースケース向けのアプリケーションを作成します。したがって、NEMはすべてのブロックチェーンユースケースをカバーするわけではなく、完全分散アプリケーションにも使用できます。

これは、特定のアプリケーションのビジネスロジックがブロックチェーンの外部に移動し、他の場所でホストされていることを意味します。これは、ライブラリ、モバイルアプリケーション、サーバーアプリケーションなど、プロジェクトが今日使用していることをすでに知っているものであってもかまいません。

副作用と不変性

nem-library(およびnem2-sdkも同様)は、NEMモデル(前述のコンセプトのセクション)とネットワークの相互作用に関する主な懸念事項があります。モデルが生成できるエラーの量を最小限に抑えるために、 レポジトリ・パターンアクティブ・レコード・ パターンよりも選択し、リポジトリ・レベルでそれらを渡すようにしました。

このアプローチでは、純粋な関数(副作用なし)でビジネスロジックをよりテスト可能に分離することができます。これは、任意のシステムにとって望ましいプロパティです。NEMアプリケーションは、これらの機能を作成し、それらを一元的にテストすることができます。

開発者がネットワークレスポンスをシミュレートしたい場合は、 この記事の例のように共有しているリポジトリを偽造する可能性があります。これにより、NEMアプリケーションのテストは、どこからでも統合テストを行う必要がなく、より軽量になります。私は間違ってはいけません。 統合テストが必要ですが、どこにあるのが理にかなっています 。

書き込みはシステムによって(一意に)行われません

ユーザーがシステムとやりとりする方法には大きな違いがあります。 一般的なシステムでは、データの入力 と検証 を制御する一方、ブロックチェーンシステムではユーザーが直接ブロックチェーンとやりとりし、システムは何らかのプッシュメカニズムで通知されますおそらくWebSockets)。

このプラットフォーム設計の結果、確認後にユーザー入力(トランザクション)を検証する必要があります。

Observablesは無効なデータをフィルタリングするのに役立ちます 。一般的に、特定のタイプのトランザクションに反応し、 filtermap関数を適用すると、他のケースを単純に無視するのに役立ちます。

コンポジション

Observablesを組み合わせることができます。

これまで共有してきたように、NEMはビジネスロジックをチェーンの外側に置き、それらのロジックを互いに呼び出すライブラリやシステムなどの異なる再利用可能なコンポーネントに配置します。

Observablesは、副作用を伴う関数を公開するときに同じ構造を共有するため、異なるライブラリを統合するのに役立ちます。

ObservablesはAPI結果の作成に役立ちます(図4)。たとえば、WebページがNEM APIとカスタムシステムを呼び出すことが一般的です。この場合、NEM APIとシステム応答をクライアント側で作成するのではなく、この責任をシステムに追加して、システムへの負荷を軽減し、コールをNEMに直接委任します。

この例は、サーバー側のアプリケーションにも適用されます。

まとめ

nem-libraryはObservablesを最初からこれまでの1年間使用されています。我々はこの設計に重い脆弱性を発見しておらず、今日まで複数のプロジェクトを作成し、より安定した開発を迅速に行うことができました。

 


 

所感

私は nem-library に RxJS が使われるという時点で、RxJS へ依存することによるバージョンアップへの追従と仕様変更の発生などを危惧していました。(あとぶっちゃけ RxJS 覚えるのめどい…とか。おっと歳か?イカンイカン)

実際、RxJS 5 から RxJS 6 で大きな変更があり、サンプルコードもすべて書き直しとなりました。

nem-libraryにおいては、1.x はRxJS 5、2.x で RxJS 6にアップデートする見込みのようです。

(すでに 1.x で作ったものは、2.x を使う場合にはそこそこ書き直しが必要と思われます)

JavaScriptには標準実装として Promise または await/async という仕組みがあり、非同期プログラミングにおいては十分な役割を果たします。

しかし、文中にもあるようにストリーム(次から次へと流れてくるデータに対する処理)を扱うには少し役不足かもしれません。

そこを理解していなかったので、腑に落ちなかったようです。

確かに nem-library をインストールすればほぼすべての操作をするのにこまることは無いでしょう(なにせ公式なんですから。まだ多少 buggy ではあるけども)

しかし、もっと軽量な nem クライアントライブラリがあっても良いと思います。

例えばサーバレス環境でなるべくフットプリントを軽くしたい、ページにアクセスしてきたひとへダウンロードさせるjsの容量を減らしたい等、RxJS が必要ないシチュエーションもあるはずです。

(もしくはストリームを扱えるもっと軽量なライブラリと一緒に使う、など依存しないような方法で)

何にせよ、nem 自体まだまだ発展途上ですし、いま nem を使ったアプリケーションを作っているひとはそれだけである意味とてもアーリーアダプターなのです。

(むしろ早すぎるくらい…?!)

その中で不便に思ったり、不都合を感じる事があればどんどん提案していきましょう。

また、開発が進むに連れ、いろいろ振り回されるシーンもこれから起こりうると思われます。

正直ついていくのはそれなりに大変だと思います。

そういった時に助け合えるコミュティは大切にしていきたいですね。

(すでに telegram や slack や discord コミュニティ、各地もくもく会等の存在は大きいと思います)

Why don't you get crypt currency 'nem' by posting your blog article?

nemlog is blog posting service which has donation feature by crypt currency nem.
nemlog was launched to create environment which can be donated nem among NEMbers via blog articles.
Let's get nem by posting good blogs.

Nem prize event is being held frequently, Please join us on this opportunity!

nemlog registration from here
Register

NEMber who posted this article

Twitter: @44uk_i3
2648
0