「東京Node学園祭2018」に参加してきました

  • 東京Node学園祭2018に参加してきました。

nodefest.jp

  • 去年に続き海外スピーカーが多く登壇されNodeのコアなテーマが多くありました。
  • 個人的にはGraphQL系の2セッションの大盛況ぶりがとても印象的でした。
  • Keynoteでは来年からはNodeFestではなくJSConf in Japanとして開催する計画であると発表されました。
RoomA RoomB RoomE
Keynote
古川陽介
- -
Offline-First Collaborative Data Structures
Mathias Buus
JavaScriptで機械学習はじめよう
Shuhei Iitsuka
How I made critical code run much faster
Vladimir de Turckheim
Node.js: The Road to Workers
Anna Henningsen
Node.jsでつくるNode.js ミニインタープリター&コンパイラー
がねこまさし
Accessibility vs latest Web APIs. Can’t we just get along?
Mauricio Palma
JavaScript Class Features: A case study in TC39
Daniel Ehrenberg
Diagnose your Node.js app
Daiki Arai
A trillion points with Node.js
Martin Heidegger
Who Takes Out Your Trash
Sanne Kalkman
State of SEO for SPA
seya
Navi: painless routing for React
James K Nelson
libuv: What's a Unicorn Velociraptor?
Colin Ihrig
React におけるパフォーマンスチューニング
辻 健人
Node.jsアプリの開発をモダン化するために取り組んできたこと
Daiki Yokoi
Leak Hunting: Finding and debugging a memory leak in Node.js
Giovanny Gongora
WebアプリをNativeアプリにする Capacitor が広げるWebの可能性
榊原 昌彦
ブロックチェーンアプリケーション開発でのJavascriptの話
Koji Hirano
Look What You MIDI Me Do!
Rachel White
実践GraphQL for クライアント側
鈴木 亮太
Angular Universal on Google App Engine
今村 謙士
Visualizing the Decentralized Web
Jim Pick
Service Workerを用いたキャッシング戦略 〜Wikiアプリケーションを例に〜
飯塚 大貴
React + Apollo Client (GraphQL) により変化するアプリケーション設計
宮崎 優太郎
Real-Time Machine Learning in JavaScript
Athan Reines
貢献できるOSSの見つけ方 -完結編-
Masato Ohba
-
Haute Codeture
Stephanie Nemeth
Vue.js/Nuxt.js で 実現できた PWA の リアルタイム動画ラップ・バトル・アプリ
lulzneko
-
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)

docs.google.com

JS × ML

  • Tensorflow.jsの例

emojiscavengerhunt.withgoogle.com

landing.google.co.jp

機械学習とは

  • データを活用して有用な予測を行う
  • ロジックで記述することが難しい時にデータからロジックを得るアプローチ

機械学習の実装方法

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);
}

エラーハンドリングが難しい

  • 非同期処理の種類によってエラーハンドリングのしかたが違う
    • callback
    • EventEmmiter
    • Promise
    • async/await
  • unhandledRejection/multipleResolvesのdebugは必ずするべき

debugが難しい

State of SEO for SPA

  • seyaさん

qiita.com

SEOとは

  • Search Engine Optimization
  • Google botにインデックスされること
    • Google botにクロールされること
    • HTMLが適切に解釈されること

SPAでのSEOの課題

  • よく言われること
    • Googlebotはjs実行しない/ajax実行してくれない
      • -> そんなことない
  • Chrome41相当のレンダリングエンジンしか持ってない
    • アロー関数等々動かない
  • WebSocket対応していない
  • ユーザの同意を必要とする機能使えない
  • jsを含むページだとRenderQueueに入るから反映が遅い

SPAでのSEOの課題の解決策

  • babel使ってchrome41で動くJSにする
  • メタ情報だけSSR
  • Dynamic Rendering(prerender)
    • prerender.io
    • アクセスしたのがGoogleBotだったらPrerenderServiceがHeadlessChromeがレンダリングしたHTMLを返す
  • StaticSiteGenerator
    • SEOしたいところだけ使うってのもありではないか
    • SEOしたいページで認証通しておきたいとかないだろうし
  • 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

capacitor.ionicframework.com

  • Cordovaの後継
  • HTMLでモバイル/Web/デスクトップアプリを作れる
    • WebViewの中でHTMLを表示している
    • SPAであればいいので任意FWで作れる
  • デザインガイドラインに沿ったアプリを簡単にHTMLで作れる

Cordovaの課題

  • バージョン
  • プラグイン
    • ネイティブAPIをたたくプラグインはほしいのがなければ自作しないといけない
  • デザイン
    • OSのデザインも変わっていく
  • 開発スピード
    • OSSなのでFW自体の開発スピードが遅いことも

Capacitorの特徴

  • コアプラグインとして、よく使われるネイティブにアクセスする機能を持っている
    • Cordova -> Cordova Plugin -> Objective-C/Java -> NativeAPI
    • Capacitor -> Swift/Kotlin -> NativeAPI
  • Native UI Shell
    • モバイルでWebViewの中にネイティブのパーツを出せる
      • 小さいパーツはHTMLで再現ではなくネイティブを呼んでしまう
      • アラートなど
    • Webの時はデザインされたパーツを出してくれる
  • HTMLアプリだからネイティブより遅いでしょ?
    • 速くはないけど遅くはない
    • 遅いから使い物にならないという時代ではない
  • PWAをサポートしてることがCordovaとの違い
    • スマホアプリよりもWebの方が利用率が高いというデータ
    • アプリの新規インストールはあまりされなくなってきている

実践GraphQL for クライアント側

  • 鈴木 亮太さん(Fringe81)

GraphQLってなに

  • 型システムとともにあるクエリ言語
  • Facebookが2015年にRelayとともに紹介
  • HTTPの場合はPOSTのボディにクエリを入れる

Query/Mutation

  • query
    • RESTでいうGET
  • mutation
    • RESTでいうGET以外
  • ネストした情報も一発でとってこれる

型システム

  • データに型を指定できる

GraphQLを使ったプロダクト

  • データ同士の関連が複雑

GraphQLによって解消された苦しみ

サーバ/クライアント間のいけてなさ

  • before
    • API仕様のやりとりがつらい
  • after
    • コミュニケーションの中心がGraphQLのスキーマになった
    • 共有されるドキュメントはコードから自動生成

データ取得の複雑化

  • before
    • エンドポイントがたくさん
    • 一つの画面を表示するのにたくさんのエンドポイントとのやりとり
    • レスポンスを扱うコードへの不安
  • after
    • 一発でデータがとれる
    • 取得したデータのスキーマが保証される

データ取得のパフォーマンスボトルネック

  • before
    • リクエストの数だけ時間がかかる
    • 使わないデータも送られてくる
  • after
    • 一発で手に入るので
    • 不要なフィールドの値は送られてこない

なぜGraphQL選んだか

  • GraphQLの課題
    • BFFやSwagger使ったりすればGraphQL使わなくても実現できる
    • リクエストが全て/graphqlになる
  • GraphQLだけ覚えればやりたいことできるから
  • クライアントサイドに依存したサーバサイドにならなくていい

GraphQLを使うにあたって工夫したこと

  • Query/Mutationに名前をつける
    • リクエストの文脈がわかる
    • エンドポイントが全部おなじになる問題の対応
  • queryの再利用性を高める
    • fragmentを積極的に使う

React + Apollo Client (GraphQL) により変化するアプリケーション設計

  • 宮崎 優太郎さん(メルカリ)

blog.vwxyutarooo.me

メルカリWeb

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

www.apollographql.com

  • GraphQLのクライアントとサーバそれぞれに必要なプラットフォームを提供してくれる
  • Apolloの構成
    • Gateway(ApolloEngine)
    • Library
    • Development

Apollo Client

React Apollo

www.apollographql.com

  • ApolloClientを内包している
    • ReactのHOCとして提供
  • クエリをGraphQLサーバに投げてくれる
    • 結果をHOCに流す

Apollo Link State

  • ローカルステートとサーバからとってきた情報を混ぜて扱える

Redux -> Apollo

  • Redux
    • ビジネスロジック
      • データアクセス
      • エンドポイント管理
      • ステート管理
    • プレゼンテーションロジック
  • Apollo
    • データアクセス
      • React Apolloによって抽象化され書かなくて良くなった
    • エンドポイント管理
      • GraphQLサーバに一回アクセスすればいい
  • GraphQLとApolloの抽象化によってReduxが置き換わった
    • プレゼンテーションロジックが複雑なものはもしかすると難しいかも

まとめ

  • ApolloとGraphQLを使うとReduxでやってたところが抽象化される
    • UIやプレゼンテーションロジックにフォーカスできるようになる