Node学園 23時限目 (今回はリクルート（東京駅）でやります！) - connpassに参加してきたのメモ

npm@4、npm@5

node-gakuen-201610.md

  • npmは後方互換性を重んじている
    • Node.jsにbundleされているので
  • npm@2のbreaking changeについて

    • backwards-incompatible change to the way npm run-script handled its arguments

  • npm@3
    • flat directory
    • npm@2そのまま使い続ける人もいる
    • 大きな変更は移行の壁になるという話
  • npm@4
  • npm@5
    • bundlerとCargoインスパイアなlock files
    • Bundler
      • GemfileとGemfile.lock
      • Flatな依存(no nest)
      • Gemfileは常にgit管理下
    • Cargo
      • Cargo.toml と Cargo.lock
      • 依存はnestできる
  • yarn
  • Different
    • Library
    • Command
    • Application
    • とそれぞれ役割が違うので、ロックファイルがいるのかも違う
  • shrinkwrap
    • ライブラリ向けに設計されてなかった(production application向けだった)
    • 問題がある
  • source of truth
    • npm-shrinkwrap.json is a single source of truth.
  • npm LTS
    • Node.jsにbundleされるとLTSはどうなるという話
  • npm@5 2017年4月リリース目標
    • Node.js 8がnpm@5を含むかは知らないよ

API for Front-end - GraphQLの話

  • RESTful API再考
  • RESTful API
    • 貧弱なSQLをAPIを目指しているわけではない
  • SPAなフロントエンドはつらい?
    • ただのViewではないから
    • サーバサイド、クライアントサイドそれぞれにMVCがいる
    • 最近のサーバサイドはMicroServiceになってきている
    • クライアントサイドもMicroservicesの一つなのでは
  • フロントエンド
    • サーバ <-> フロントエンド
    • 物理的に遠いので、時間がかかる
    • 他のMicroservicesと違ってやり取りに時間がかかる
    • 先頭から3件だけ欲しいとか細かい指定をしてリクエストしたい
  • オーケストレーション層のパターン
    • サーバに手を入れる必要がある
    • ドキュメントは別途必要
  • GraphSQL
  • N + 1問題
  • GraphQLの仕様

Client-side JS for infeed layout native ad at fluct SSP

Client-side JS for infeed layout native ad at fluct SSP // Speaker Deck

  • fluct in VOYAGE
  • document.write()
  • 広告業界
    • SSP
      • 問屋業
      • 枠を売買
      • Adのリクエストを管理する
      • タグマネージャー的に動く
    • DSP
      • 広告枠を買って広告案件を流したい
      • Real Time Bidding (RTB)というオークションを介してSSPから枠を買う
    • Adnetwork
      • 広告枠を買って広告案件を流したい
      • RTBに参加するか否かが概ねDSPとの違い
  • Infeed Layout web ad
    • いわゆるネイティブ広告
    • 従来の広告はimgとかで貼ってたりした
    • ネイティブアドはデザインテンプレートと広告コンテンツを合わせてる
  • ネイティブ広告
    • SDKスタイル
      • SDKを開発者に配って実装してもらう
    • コンサルティングスタイル
      • 開発者がいないとデザインできないので、代わりにやるスタイル
      • タグを貼ってくれれば広告がでる
  • OpenRTB protocol
    • デファクトの仕様
    • 最近のW3CやIETFに比べてザルな仕様
  • iABという業界団体
    • リクエストとレスポンスのフォーマットを決めた
    • 多くの会社はサブセットとかスーパーセットを定義してる
  • OpenRTB - js-tracker
    • DSPが任意のJavaScriptを埋め込める素敵な仕様
      • 悪意があればマルウェアも仕込める
    • document.write()とかも仕込めてしまう
      • 非同期読み込みの障害なので自社用の拡張仕様を作って縛る
  • SSPのサポートする範囲
    • 網羅できるものが多いほど強い
    • RTB一回やAd network一社だけでは売れない場合があるので色々なAd networkに多段する
  • Data flow overview
    • Web Page -> リクエスト -> SSP <-> DSP
      • SSP <-> DSP
      • 広告オークションを行う
    • Web Page <- レスポンス <- SSP
    • オークションが成功したらこれでOK
    • 失敗した場合は、Ad networkへクライアントからリクエスト投げる
      • クッキーとかクレデンシャルがあるのでクライアントから
  • Construct JavaScript in ad server
    • JavaScriptを文字列で組み立てるのは危険
    • 一端 JSON.stringify で文字列リテラルとして評価できるようにする
  • 非同期処理をサポートする広告
  • 一つの画面に複数の広告
    • 非同期だと問題が
      • 今まではdocument.writeばかりなのでparser blockingして同期的に動いてた
      • deferもasyncもない普通のscript要素も同期的に動いてくれた
    • document.currentScriptが使えない環境で問題がある
    • 自分がどのAd Scriptタグなのかわからない問題
    • 最後のscriptタグ !== 自分
      • async属性などがあるため
    • リクエスト時にuniqueなidを振って、レスポンスでそれを使うことで解決する
  • 優先度付きのリトライ
    • 並列にリクエストを投げて最初に返ってきたものを取るというのを上手くやる仕組み
  • Construct DOM
    • テンプレートな文字列を安全にやるのは難しい(XSS)
    • クライアントのDOM APIを使ったほうが安全
  • Implementation Style
  • Limitation
    • ファイルサイズ
    • サードパーティのライブラリを含めるとファイルサイズがネックになる
    • Promiseのpolyfillが使えない
  • 自前で実装
    • 10kb~ / response ぐらい
  • 他の問題
  • Telemetry Reporter
    • 広告タグはいろんな環境で動かす必要がある
    • 動かない環境とかもあるのか調べる方法が必要
    • ログを上手く取る方法が必要
    • またサイズを気にする必要がある
  • Open Source
    • JavaScriptのコードは重要だけど、SSPは問屋業がコアバリュー