【勉強会メモ】関西Node学園 5時限目
- 日時:2019/02/01(金) 18:40 〜 21:00
- 場所:サイボウズ株式会社 大阪オフィス
いつの間にか5時限目のNode学園。関西も回を追うごとに盛り上がっているように感じます。最近あまりこの領域の技術に関われていないので付いていくのがやっとというか、なんとか食らいついていますが、ハッシュタグ #kng5 を追いかけるだけでも、とても勉強になります。
Design Mistakes in Node & Deno
@shisama_ さん
Node.jsの設計ミスを設計者自身が改善しようとしている
※参考
yosuke-furukawa.hatenablog.com
Deno
TypesScriptをV8で実行
- トランスパイルする必要ない
- TSファイルを直接実行できる
- 実行時にDenoがビルド
ES Modulesによるモジュール解決
- CJSではなくSDMを使ったmoduleローディング
- package.jspn不要
- importでインターネット上のリソースを読み込める
Secureな実行環境
- 安全でない環境では実行できない
- 実行オプションをつける
- 許可しなかった場合はパーミッションエラー
Node.jsからの改善
- Node.jsはCallbackベース
- DenoはPromiseベース
Deno Core
- Privilgedな領域とUnprivilegedな領域がある
3つのレイヤー
Deno for Users
まだ試行段階
TypeScriptとVue
@Daikids2 さん
vue-cli
はdeprecatedになった→@vue/cli
を使う- TypeScriptとscssを選べる
TypeScriptのサポート
Class-Style ComponentでTypeScriptそのものの型が使える
Callbackを撲滅した後に ~ Promise化だけでは終わらない
@Ajido さん
↑Promiseを撲滅した後に残った課題の話
CallbackとPromiseのインターフェースを両立させる
- Callbackを省略した時にPromiseが返る→オススメ
- 段階的なPromise化が可能
- 将来的なCallbackの廃止
- Promise型のモジュールを返す
- ライブラリを一気にPromise化する必要がある(段階的にできない)
- メソッドチェーンからPromiseを返す
.promise()
- Suffix月の関数からPromiseを返す
- 実装が楽
- 互換性への対処が難しい
性能
- パフォーマンスを計測→現時点ではCallbackが最速
- async/awaitはPromiseよりも速くなる
- V8 7.2以上ではawaitの仕様変更に伴う最適化
- Node-v12に入るかも
現代的なフロー制御は高速なのか?
- async/awaitはNodeのバージョンアップに伴い速度が向上
- 速度はCallbackに迫りつつある
- Promiseよりもasync/waitを
- async/awaitを使うならメジャーバージョンアップは積極的に
ストリーム対応
Streamをフロー制御にどう組み込む?
- Streamとフロー制御は相性が悪い
- Streamのエラーハンドリングは独特
- EventEmitterのエラーハンドリングは独特、ハンドリング漏れはクラッシュにつながる
AsyncIteratorを使ったStreamのフロー制御
- ES2018の新機能
- 統一的なエラーハンドリング
エラー処理
非同期処理のスタックトレースはどう見える?
- 課題1
- 呼び出し元エラーの発生箇所が特定できない
- 課題2
- awaitで中断した関数はマイクロスタックキューから処理
課題への対処
ブラウザで使えるnpmライブラリ
@mochiya98 さん
Asynchronous Modle Definition
- CommonJS
- サーバ向け
- nodeでお馴染み
- ES Modules
- ECMAScriptに組み込まれたWeb標準
- import/export
- 従来型
<script>
- 全部のせ
- 1つのファイルでAMD、CJS、従来型として使える
- ESMは構文だから古い環境への互換性を失う
- 基本的にmain
- ESMを活用するツールはmodelを見てくれる
- mainにUMD、moduleにESMを指定
{ "main": "hoge.umd.js", "module": "hoge.esm.js" }
Managing multi-package repositories
@kamiyam さん
www.slideshare.net
Lernaについて
gitとnpmを使ってマルチパッケージリポジトリを管理するワークフローを最適化するツール
※参考
モノレポ化
- メリット
- 依存関係がある複数レポジトリ管理
- モノレポ内で共通モジュールを作成
- packages以下の各プロジェクトをそれぞれ独立してnpm publishすることも可能
- デメリット
- コマンドが若干煩雑
- ファイル構成が大きくなる
- デプロイ(公開モジュールが複数あるなど)
始め方
$ npm install $ lerna init
package以下にプロジェクト配置
- packagesフォルダの下に各プロジェクト
- その下にpackege.json
管理モード
- 固定モード
- 独立モード
モードの違い→packages以下の管理バージョンを固定/独立選べる
$ lerna add xxxx
→基本 npm installは使わない
--scope
で対象プロジェクトを絞る
各プロジェクト間の依存モジュール
$ lerna add @others --scope xxx
モジュール全体
$ lerna run xxxx
各モジュールの依存関係を解決
lerna bootstrap
たまにモジュールのロードがおかしくなる
$ lerna clean $ lerna bootstrap
- 導入は難しくない
- 大規模開発環境を細かくbuild/publish
分散データの基本
Node.jsで分散ストレージ
同じデータ?
- ハッシュする
- 正しいファイルであることと誰が開発したかがわかる
Buffer.compare()
繋がりがなくなったら?
- IDをつけたほうが良い
crypto.randomBytes(32)
分散する
bitfield
- ブロック単位でどれを持っているかわかる
bitfield
は3種類、メモリの使い方などが違う
すべてのブロックが揃っているかをどうやって確認する?
- ハッシュをつける
- 順番が確認できない
- 前後のブロクのハッシュからハッシュを作る
- さらにそのハッシュと次のハッシュでハッシュ→回帰的に
- 正しい順番かどうかを確認できる
merkle-tree-stream
誰が情報を更新したか?
- publickKey, privateKey
- signatureを作る
hypercoreというモジュールがある
- これらすべてのことができる
※参考