- 東京Node学園祭2018に参加してきました。
- 去年に続き海外スピーカーが多く登壇されNodeのコアなテーマが多くありました。
- 個人的にはGraphQL系の2セッションの大盛況ぶりがとても印象的でした。
- Keynoteでは来年からはNodeFestではなくJSConf in Japanとして開催する計画であると発表されました。
LTタイトル | 発表者 |
---|---|
おまいらちゃんとリソース解放してますか | Taro Odashima |
食べたいIoT | へっぽこまるこ |
What developers can learn from Soviet space program failures | Andrey Sitnik |
power-assert 2 | 和田 卓人 |
How to choose the best npm library? | Sota Sugiura |
Squoosh裏話 | Mariko Kosaka |
JavaScriptで機械学習はじめよう
- Shuhei Iitsukaさん(Google)
JS × ML
- Tensorflow.jsの例
emojiscavengerhunt.withgoogle.com
機械学習とは
- データを活用して有用な予測を行う
- ロジックで記述することが難しい時にデータからロジックを得るアプローチ
機械学習の実装方法
K近傍法
- 最も似てるK個で多数決する
- データが増えると複雑
線形モデル
- 線を引いてグループ分け
- 平面で分離できないと対応できない
ニューラルネットワーク
- 脳細胞のネットワークをヒントにしたモデル
- 行列演算を繰り返す
- 調整するパラメータが多い
- ニューラルネットワークを重ねる -> DeepLearning
- 膨大な数のパラメータ調整が必要
- そこでTensorFlow
- 膨大な数のパラメータ調整が必要
TensorFlow
TensorFlow.js
- TensorFlowのjs版
- ブラウザからでもNodeでも
なぜJSで機械学習?
- オンブラウザ機械学習
- 高速な推論
- プライバシーの保護
- スケーリングが容易
- 学習済みモデルの軽量化が課題
デモ
- 3×3マスのマルバツゲーム
- 手書きの○と×を認識させる
https://tushuhei.github.io/tfjs-tutorial/
Diagnose your Node.js app
- Daiki Araiさん(Yahoo)
Node初学者の悩み
- 非同期処理が難しい
- エラーハンドリングが難しい
- debugが難しい
非同期処理が難しい
- ブラウザ or NodeやNodeのバージョンによって挙動が違うことも
- node v11から変わった
for (let i = 0; i < 2; i++) { setTimeout(() => { console.log(`Timeout ${i}`); Promise.resolve(`Promise ${i}`).then(console.log); }, 4); }
- 非同期処理は順番/時間に依存しない設計が重要
- フロー制御できているかどう確認?
- Async Hooks
- Async Hooks | Node.js v11.3.0 Documentation
エラーハンドリングが難しい
- 非同期処理の種類によってエラーハンドリングのしかたが違う
- callback
- EventEmmiter
- Promise
- async/await
- unhandledRejection/multipleResolvesのdebugは必ずするべき
debugが難しい
- node v12からasyncスタックトレースが強化される!?
- 非同期処理中にクラッシュしてもスタックトレースが表示される
- post-mortem debugging
- クラッシュ時のメモリイメージから指標を取る
State of SEO for SPA
- seyaさん
SEOとは
SPAでのSEOの課題
- よく言われること
- Googlebotはjs実行しない/ajax実行してくれない
- -> そんなことない
- Googlebotはjs実行しない/ajax実行してくれない
- Chrome41相当のレンダリングエンジンしか持ってない
- アロー関数等々動かない
- WebSocket対応していない
- ユーザの同意を必要とする機能使えない
- jsを含むページだとRenderQueueに入るから反映が遅い
SPAでのSEOの課題の解決策
- babel使ってchrome41で動くJSにする
- fetch as googleで確認できる
- ただし1日10回までの制限
- fetch as googleで確認できる
- メタ情報だけSSR
- Dynamic Rendering(prerender)
- prerender.io
- アクセスしたのがGoogleBotだったらPrerenderServiceがHeadlessChromeがレンダリングしたHTMLを返す
- StaticSiteGenerator
- SSR
解決策の選び方
- 判断ポイント
- インデックスに信頼性を求めるか
- メタ情報の対応が必要/不要
- 頻繁に更新される & すぐにインデックスしてほしいかどうか
React におけるパフォーマンスチューニング
SPAに何を求めるか
- いろいろなことを求められるようになっている
- ユーザの操作に迅速に応えることが重要
事例
- お客さんからパフォーマンスが悪いと問い合わせ
- Scriptingに時間がかかっていた
- Reduxの処理だろうと思い調査
- うまくいかなかった
- 推測するな測定せよ
調査
何をするか
- Scriptingの内訳を見る
- 関数のコールスタックを調べる
- React内部で何が起きているか調べる
どうやって調べる
- Chrome Devtoolsを活用する
- ReactDevTools
- HighlightUpdate
- Profiler
- Network Timing
User Timing
- React内部で計測の処理を入れてくれている
- redux-action-timing-middlewareと組み合わせ
- actionごとのパフォーマンスが見られるようになる github.com
React Virtualize
- 画面に表示されてない要素を描画しない
まとめ
- 推測ではなく測定することが重要
- 顧客と同等の環境で動作確認しないと気づけない
- DevToolsの機能で性能を調整できる
- 定期的なパフォーマンス測定が重要
- 機能追加とともにパフォーマンスも劣化していく
WebアプリをNativeアプリにする Capacitor が広げるWebの可能性
- 榊原 昌彦さん
Capacitor
- Cordovaの後継
- HTMLでモバイル/Web/デスクトップアプリを作れる
- WebViewの中でHTMLを表示している
- SPAであればいいので任意FWで作れる
- デザインガイドラインに沿ったアプリを簡単にHTMLで作れる
Cordovaの課題
Capacitorの特徴
- コアプラグインとして、よく使われるネイティブにアクセスする機能を持っている
- Cordova -> Cordova Plugin -> Objective-C/Java -> NativeAPI
- Capacitor -> Swift/Kotlin -> NativeAPI
- Native UI Shell
- モバイルでWebViewの中にネイティブのパーツを出せる
- 小さいパーツはHTMLで再現ではなくネイティブを呼んでしまう
- アラートなど
- Webの時はデザインされたパーツを出してくれる
- モバイルでWebViewの中にネイティブのパーツを出せる
- HTMLアプリだからネイティブより遅いでしょ?
- 速くはないけど遅くはない
- 遅いから使い物にならないという時代ではない
- PWAをサポートしてることがCordovaとの違い
- スマホアプリよりもWebの方が利用率が高いというデータ
- アプリの新規インストールはあまりされなくなってきている
実践GraphQL for クライアント側
- 鈴木 亮太さん(Fringe81)
GraphQLってなに
- 型システムとともにあるクエリ言語
- Facebookが2015年にRelayとともに紹介
- HTTPの場合はPOSTのボディにクエリを入れる
Query/Mutation
- query
- RESTでいうGET
- mutation
- RESTでいうGET以外
- ネストした情報も一発でとってこれる
型システム
- データに型を指定できる
GraphQLを使ったプロダクト
- データ同士の関連が複雑
GraphQLによって解消された苦しみ
サーバ/クライアント間のいけてなさ
データ取得の複雑化
- before
- エンドポイントがたくさん
- 一つの画面を表示するのにたくさんのエンドポイントとのやりとり
- レスポンスを扱うコードへの不安
- after
- 一発でデータがとれる
- 取得したデータのスキーマが保証される
データ取得のパフォーマンスボトルネック化
- before
- リクエストの数だけ時間がかかる
- 使わないデータも送られてくる
- after
- 一発で手に入るので
- 不要なフィールドの値は送られてこない
なぜGraphQL選んだか
- GraphQLの課題
- BFFやSwagger使ったりすればGraphQL使わなくても実現できる
- リクエストが全て
/graphql
になる
- GraphQLだけ覚えればやりたいことできるから
- クライアントサイドに依存したサーバサイドにならなくていい
GraphQLを使うにあたって工夫したこと
- Query/Mutationに名前をつける
- リクエストの文脈がわかる
- エンドポイントが全部おなじになる問題の対応
- queryの再利用性を高める
- fragmentを積極的に使う
React + Apollo Client (GraphQL) により変化するアプリケーション設計
- 宮崎 優太郎さん(メルカリ)
メルカリWeb
- 今GraphQLを使ってるわけではない
- リファクタリング中でそこで取り入れてる
ReactとGraphQL
- GraphQLを使うとReduxがいらなくなってコード量が減る
- 実際にそうだった
- GraphQLとApolloClientを使って作ってる
Reducing our Redux code with React Apollo – Apollo GraphQL
Moving from Redux to GraphQL - Speaker Deck
GraphQL
- RESTの置き換え
- BFFとして
Apollo
Apollo Client
React Apollo
- ApolloClientを内包している
- ReactのHOCとして提供
- クエリをGraphQLサーバに投げてくれる
- 結果をHOCに流す
Apollo Link State
- ローカルステートとサーバからとってきた情報を混ぜて扱える
Redux -> Apollo
- Redux
- ビジネスロジック
- データアクセス
- エンドポイント管理
- ステート管理
- プレゼンテーションロジック
- ビジネスロジック
- Apollo
- データアクセス
- React Apolloによって抽象化され書かなくて良くなった
- エンドポイント管理
- GraphQLサーバに一回アクセスすればいい
- データアクセス
- GraphQLとApolloの抽象化によってReduxが置き換わった
- プレゼンテーションロジックが複雑なものはもしかすると難しいかも
まとめ
- ApolloとGraphQLを使うとReduxでやってたところが抽象化される
- UIやプレゼンテーションロジックにフォーカスできるようになる