Inside Frontend行ってきた #insideFE

先週土曜日にInside Frontend行ってきたのでレポート。

Inside Frontend

inside-frontend.com

CyberとYahooの共同主催のフロントエンドのイベント。

国内だとHTML5 Conferenceに次ぐくらいの大きさかな？？

会場はAbema Towers。

行く途中で中本でラーメン食べたから、イベント中腹壊したらどうしようと思っていたが杞憂で終わってよかった・・・

TypeScript: Why and how we adopted it at Slack

  • SlackをTypeScriptで作り直した話
  • Reactも導入しているっぽい
  • 2017年4月ごろっぽい
  • JSはVanila JSで書くのが好きで、ライブラリとか入れない予定だったけどTSで書いたらTS最高だった
  • Battle Field 1のUIはReactとTSで作っているらしい
  • 他にもNvidia,Adobe,Skype,Visual Studio InstallerとかもJS(Electronっぽい)
  • C++で書かれたnode.jsモジュールがある
  • JSDoc書いていたけどメンテされないし、Objectで渡ってきたら中身わからないし・・・
  • そこでTS、TS書いても既存のJS破壊しない（JSにコンパイルされるから）
  • エディターがTSを強力にサポートしている
  • JSは実行するまでエラーに気づけない（コンパイラを求めていた
  • Coffeeは使ったことない
  • TSは実行せずともエディターがエラーを出してくれる
  • 最初は.jsを.tsにかえるだけでOK
  • デモでJSをTSにして、コンパイルしたJSを見せる
  • 少しずつTSに移行していった
  • TS書いていたらVanila JSが汚く見えてきた
  • TSで型が定義されるのでメソッドのサジェストが助かった
  • koa使うときほとんどドキュメント見なかった
  • 当時TSLintにはお世話になった
  • 今はESLintのほうがいい
  • 想定より早く移行が終わった

そもそもSlackってElectronで作られているのが初耳だった

TS最高だぞという話。結構エディターのサポートが強力という話が多かった気がする。

Introduction to Lucet

前提のwasmの知識がなくかなり難しかった

途中からコンパイルの仕組みとかの話でかなり難しかった・・・

Nuxt.jsで中規模サービスを統合した話

www.slideshare.net

  • 無料まんが・試し読みが豊富！eBookJapan｜まんが（漫画）・電子書籍をお得に買うなら、無料で読むならeBookJapan
  • フロントはYahoo
  • バックはEBJI
  • Yahooのデザイナーはマークアップまでできる
  • Vue.js,Nuxt.js,Node.js,Express
  • 他社で分担しているので風土が違う
  • Yahooは属人化をさけるが制約が多い
  • EBJIはスピードが速く自由度が高いが属人化しがち
  • そこでスクラムを導入し吸収した
  • 1週間スプリント
  • 部署や役割ごちゃ混ぜでAとBチームを作った
  • Atomic Designを導入
    • デザイナーがHTML,CSSをエンジニアにわたす
    • エンジニアはAtomicデザイン通りのVueファイルを作る
    • エンジニアとデザイナーで溝ができた（アトミックデザインの共有とか）
  • デザイナーはAtomic Designの共有を受けていなかった
  • 最初からデザイナーに共有をしてデザイナーがAtmoic Design通りにVueファイルを作る流れのほうが良かった
  • 大は小をかねるので大量の項目を返すAPIを作っていた
  • でかすぎるのでmixinで絞る処理を書いた
  • Vueファイル以外で使ってバグった
  • 直列でAPI叩いていたからタイムアウトしていた
  • 目に見えるものをスクラムで作りまくっていたので目に見えない処理とかが後手後手だった
  • 比較的若いエンジニアが多かった
  • 名古屋チーム（一人）を作った
  • スクラムは機能追加
  • 名古屋チームは、スクラムに入らずFEのサポート、レビュー、相談、パフォーマンス改善
  • FEエンジニアで会話する場を作る
  • 新しいこと、実装時の課題を拾う（スクラムで拾えないのを拾う
  • 直列でAPIを呼んでいたところをリファクタリング
  • APIを小さくした
  • webpack bundle analyzerでJSを削る
    • 7MBくらいあった
  • 名古屋チームもスクラムに混ぜた
  • 7割機能追加、3割改善
  • Q APIのドキュメント方法
    • A エクセル、swaggerなどAPIによって違う（辛い
  • GrapshQLは検討中
  • NuxtにしたのはSSRしたいのとwebpackメンテが嫌だった
  • 1週間スプリントは実装の割合が減るが、仕様等がコロコロ変わるので1週間スプリントにした
  • 機能開発はJIRAで管理、改善系はGitHubで管理
  • スクリュードライバーというCIでデプロイ
  • UnitTestは書いてあるが、e2eはない
  • 2つのチームは同じPO

Nuxt.jsがメインと言うよりは、チーム作りや開発体制などの話がメインだった。

違う会社を同じスクラムに混ぜて開発するのめっちゃ大変だったんだろうなという印象。

いちからデザインシステムを作ってみて学んだこと

speakerdeck.com

  • Yahooの広告配信管理ツールのデザインシステムを作った話
  • 20社以上1000人が関わる
  • それぞれ独自に作るのでばらばらになってしまう
  • デザイナー4人で開発
  • スタイルガイド
    • 原則定義
    • 色とかの定義
    • モーションの定義
  • デザインキット、コンポーネントライブラリ
  • コンポーネントを洗い出して名前をつけた
  • 名前付けは時間がかかった
  • Card?Panel?Plate?
  • シンプルが故に難しい
  • サービス特有の謎パーツも難しい
  • 見た目ではなく機能・役割を考えて言葉を選ぶ
  • 全員が納得するまで議論
  • Sketch使ってAbstract?でレビュー
  • 全員の承認が必要
  • エンジニアがレビューに入っていたから実装目線でも会話ができてよかった
    • ホバー
    • エラー
    • 入力量
  • HTML,CSS,JSスニペット提供(BEM記法
  • Fractal(スタイルガイドジェネレーター
  • 作ったはいいがReactのコンポーネントで提供してほしいと言われた
  • npmで提供できるようにした
  • TSは有識者いなかったが導入した
  • Storybook
  • sassの型解決できずなやんだ（typings-for-css-modules-loaderで解決
  • スタイルガイドはGatsbyで作って、自動的に同期して更新漏れが発生しないようにした

作ったあとにReactコンポーネントで書き直すのはなかなかつらみがあるな・・・

Web Componentsもこんな感じで配布したい

BFFのDeveloper Experience

speakerdeck.com

  • Backends For Frontend
  • 全然詳しくない
  • BFFはUXのためにある
  • Micro ServiceとUXをつなぐ
  • MSはドメイン注力、シンプルなAPI、サービスごとに技術最適
  • API Aggregation(node.js/koa)
  • SSR(React, Redux)
  • バックエンドはドメインごとの開発に注力
  • フロントはUI要求をAPI化
  • フロントの仕事が増えている・・・
  • そこでBFFをサクサク開発する必要がある
  • APIのインターフェイスの合意をバックエンドとフロントエンドで取る必要がある
  • Interface Definition Language　e.g. Swagger
  • Thriftを採用
  • 並行開発をよりよくする
  • モックデータを作る
  • Cross cutting concern（関心ごとの分離
  • マイクロサービスのモックデータは横断として考える
  • インターセプターする
  • Aspect Oriented Programming
  • Dev用の画面もBFFで作る（デバッグにつかう
  • フロント複雑になっているからエンジニアリングで解決していこうな

BFFは単語だけ知っていたので興味本位で聞いていた

手を動かしてみないと実際のところはわからないが・・・

フロントエンドの仕事が増えてきたのは同意

node.jsの存在がフロントエンドの垣根を壊しているイメージ

Loading Performanceとの向き合い方

speakerdeck.com

  • 日経電子版は7月に2度目のリニューアルをする
  • LightHouse100点だけどユーザーの状況によっては低くなる（速度制限とか
  • 広告のスクリプトが速度低下の原因
  • 簡単に導入でき、確実に表示され、正確に計測ができるが
  • document.write...
  • 自由度がない
  • 外せないので最適化をする
  • minifyされたコードを読みデバッガーで頑張る
  • スクリプトを読み込む処理を探し、スクリプトをダウンロード、呼び出しを潰して、連結してminifyしFastlyで配信
  • onScrollも上書きしてintersectoin obseverにする
  • UIの表示以外はWebWorkerに任せる
  • comlinkを利用
  • どこかで失敗したら従来どおりの読み込みをする
  • 最適化もレベルを分けて実施して、効果を図る
  • handlebarsからJSX
  • vanila jsはそのまま
  • 通常のSSRサイトなのでReactとかいらなかった
  • Web Components使う
  • 泥臭いの作業は業務後にやっている
  • Edge,IE11はスルー
  • lit-elementは使わない
  • なお、リニューアルは天の声が・・・

広告最適化の泥臭さやばい

広告のJSはドキュメントがほしいと言っていた

それにしてもリニューアルでWebComponents使うの楽しそう・・・

懇親会

寿司！ビール！ピザ！

終わり

node.jsが存在するおかげで、フロントエンドもサーバーサイド書くっしょみたいな風潮がより強くなってきた気がする

個人的にはWeb Componentsが好きだからデザインシステムとかもWeb Componetsとかどうだろうとか思いながら聞いていた

実はCall For Proposalで2つほど申し込んだけど残念ながら、落選していた(・∀・)

次回こそ・・・

Frontrend × Bonfire Frontend 参加してきた #frontrend_bonfire

Frontrend × Bonfire Frontend 参加してきました

FrontrendもBonfire Frontend参加したことなかったけど、名前だけ知っていた（うっすら）

Frontrend × Bonfire Frontend

frontrend.connpass.com

会場は何かと話題のAbema Towers

広い・綺麗

アベマタワーズに入りたかったから開催したらしいですw

テーマは「新しい挑戦と学び」のため、新人が多い

ライブ配信もしていた。

Roppongi.vue開催時はライブ配信LT会あまりないかなーと想っていたけど最近のLT会はライブ配信めっちゃしている(・∀・)

新卒3年目、ヤフーで学んだ2年間を振り返る

以下メモ

  • 濱田唯
  • 1994年
  • ヤフーの2年間の振り返り
  • 6ヶ月OJT
  • 未経験
  • 10月からFrontEnd
  • 3ヶ月基礎研修・OJT
  • いろんなチームの雰囲気把握のためローテしたりする
  • TS,Atomic Design,Redux
  • TSｶﾝﾍﾟｷﾆﾘｶｲｼﾀ
  • インプットアウトプットの習慣づけ
  • チーム内LT

ローテはいいなって思った

チーム内LTの合意の取り方気になる

AbemaTV 新卒1年目エンジニア実録

以下メモ

  • 野口 直寛 @nodaguti
  • 新卒2年目
  • 560PR
  • 10万行くらい
  • Prettierで2万行稼いだ
  • 1ヶ月くらいが新卒採用
  • 研修でSlack作った
  • 小さいUI変更を最初やっていた
  • 2週間スプリント
  • Flux独自実装
  • intersection Observerを使う
  • スマホ実装
  • 仕様固まっていたからひたすら実装をする
  • モバイルブラウザをどうプロダクトとして伸ばすか
  • 再生前の離脱ユーザー
  • 数字をあげるのが課題
  • 12月は負債返したりリファクタリングしたり
  • 機能開発がどうKPIに影響するか見ている
  • テックリードを目指す
    • リーダーシップ
    • 専門性
  • 技術から事業に貢献
  • パフォーマンス改善とリファクタリングは優先度さがりがち
  • パフォーマンスがビジネスの指標にどう貢献できるか見える化する

HTML5Conferenceで新卒研修でSlack作ったネタで登壇していた人だった

機能に重きをおかず、開発スタイルに重きを置いた（テスト・カバレッジ・英語で書くなど）話をしていて印象に残っていた

Webフロントエンド&デザインで学んだ2年間を総括

以下メモ

  • 内藤 秀彦 @innovate_7110
  • ヤフーショッピング
  • 3年目
  • 機械学習・デザイナー・フロントエンドエンジニア
  • デザインにおける改善
  • 解決したい課題を探す
  • チームで解決する課題を決める
  • ビジネス貢献考えUIを作る
  • ABテスト
  • 抽象的キーワードが多く、商品にたどり着けない
  • CTRが多い（ページネーションが多くクリックされる
  • その他で絞り込むからではなく、もっと絞り込むに変える
  • FVで商品見えるようにした
  • 1テストで1つの変更にしないと勝った理由がわからない（勝つだけが目的じゃない
  • モジュールとエレメントで管理
  • gulp
  • テスト→勝ち筋→施策
  • KPI分解
  • CVRめっちゃ追うチーム
  • CSS上書きで調整
  • ストーリーブック
  • PHP,jQuery
  • 独自jQueryライブラリ
  • React Atomic Design Next Redux
  • D3.jsでデータビジュアライズ

UIのABテストをまわす話とか前職を思い出した

こえのブログでのPWA 〜開発現場編〜

以下メモ

  • 原 一成 @herablog
  • IE 6対応。。。。
  • なぜwebアプリ
  • クロスプラットフォーム
  • 小さくリリースできる
  • ブラウザ機能の充実
  • ネイティブアプリに近づけた
  • 早い・オフライン
  • クライアントサイドレンダリングでつよつよに
  • time to interactive（操作可能
  • 遅くなりがち
  • HTML読んだあとにすぐJS呼ぶ（初期表示に必要なJSは減らす
  • ネットワークの速度（CDN使おう
  • PRPL Pattern
  • Push,Render Pre cache , Lazy Load
  • type moduleで
  • HTTP2 server push
  • HTML返却と同時にHTTP2 PUSH
  • スクリプトをとにかく読む
  • on loadでSW
  • SWがその後読み込む
  • CDNヒット率がとても高い
  • イベントドリブンでCDNのキャッシュパージ
  • ビルド時とか
  • LitElement
  • 捨てやすさ＞再利用性
  • cssのカスタムプロパティ
  • 166kb
  • LHつよい
  • マイク関連
  • 音声の圧縮
  • 開発フロー
  • 細かく出す
  • 間違ったら直す
  • 再利用より捨てやすさ
  • 最速でプロトタイプ
  • FireBaseでプロトタイプ
  • HTML, Pure JSで作って、コンポーネント下
  • アクセシビリティ
  • デプロイ
  • 心理的安全性を・・・高める
  • パフォーマンスバジェット設定
  • FCP,TTI,SpeedIndex
  • 競合より20%早いと差が出る
  • OSSのように社内で開発

こえのブログの開発ブログは読んでいて、今回一番楽しみだった

「捨てやすさ＞再利用性」これに結構頭ガツンと殴られた

懇親会

寿司うまー

まとめ

BGM良かった

「PWA Night vol.3 ～PWAのミライや活用方法をみんなで考えよう～」で登壇してきた #pwanight

PWA Night vol.3で「Cache APIに触れる」というタイトルで登壇をしてきました。

pwanight.connpass.com

PWA Nightは第2回のイベントページをどこかで発見して、予定に被っているなーと呟いたところ

主催者に拾っていただき、登壇もしたいとリプを送ったところなんとOKをもらって今回登壇させていただきました。

ありがとうございます！

vol.3の会場はオイシックスで、めちゃくちゃお洒落（壁に絵が書いてあった）（写真を撮り忘れた）。

懇親会ではオイシックスの野菜がいくつかあって（ちょうどテレビで見たトマトもあった）(ﾟдﾟ)ｳﾏｰ　だった

f:id:tiwu:20190512180308j:plain

登壇資料

speakerdeck.com

登壇内容はCache APIについて。

キャッシュはService Workerの機能ではないく Cache APIがやっていて、Service Workerはキャッシュから取り出して返しているという話

workboxとかでラップされているのでCache APIをあまり意識することは普段ないのかもしれない

それにしてもブラウザにキャッシュできる機構はLSとかIndexedDBとかCookieとかたくさんあるな・・・

「Meguro.es # 20 @ Drecom」と「【第8回】フロントエンド× ビアバッシュ初心者勉強会 酒がナイト in 銀座」でLTしてきた #meguroes #sakenight8

2つともほぼ同じような内容だったのでまとめてブログにしてみた。

会社のブログでよく書いているから、個人ブログのテンションがよくわからない・・・

Meguro.es # 20 @ Drecom

目黒周辺のES系勉強会

meguro.es

meguroes.connpass.com

目黒.cssというのもあるらしくて、こっちも参加してみたい。

LTに申し込んだけど先着順で補欠だった

ただ、ツイッターで懇親会中に飛び込みLTもあるのでぜひということでLT資料作って参加（ありがとうございます！

会場はドリコムさんで、めちゃくちゃお洒落だった

名札があってシール貼ったりして懇親会の話のネタにするのすごいいいアイデアだなと思った

懇親会はエンジニアらしく？ビールとビザ（最高

f:id:tiwu:20190421164748j:plain

発表資料

speakerdeck.com

デモURL

informal-meguro-es-web-components.netlify.com

こんなかんじだった。盛り上がりを感じて楽しかった

帰りに目黒駅近くの中本食べたら無事死んだ

f:id:tiwu:20190421165921j:plain

【第8回】フロントエンド× ビアバッシュ初心者勉強会 酒がナイト in 銀座

sakeganaito.connpass.com

酒がないとプログラム書けないという強い勉強会で見つけた瞬間申し込んだw

会場はリンクアンドモチベーションさんで、銀座SIX内でめちゃくちゃお洒落だった

f:id:tiwu:20190421170033j:plain

いい感じにお酒飲んでLT聞いて、懇親会して、2次会行ってただただ楽しかった

発表スライドはMeguro.esとほぼ同じような内容

speakerdeck.com

デモURL

informal-sakeganaito-web-components.netlify.com

発表資料について

両方Web Componentsの話

Web ComponentsはMeguro.esでは8割くらい知っていて書いたことある人は2割くらい

酒がナイトは1割くらい

ロゴとか表示するだけといったようなただの静的なコンポーネントなら作るのは本当に楽で1時間もかからない

VueやReactのような開発環境構築がいらないのが始めやすくて嬉しいと思う

動的な表示はconnpassのAPIがJSONPでそこに詰まったのとconstructorとconnectedCallbackで詰まった。

APIで取ったあとにループして動的に表示させようとしたら値が渡せず悩んでいて（constructor値を受け取る処理を書いていた）

constructorに初期化時だけ呼ばれて、connectedCallbackはDOMに挿入されるたびに呼ばれるからこっちに書かないといけなかった・・・

凡ミスと発想が足りなかった・・・

WEB+DB PRESS Vol.109

At the front 筆一本は いかにして実現したか？

  • 結城 浩
  • 執筆で生きていくには？
  • 良い文章を書くには？
  • 本に近い状態（印刷）で読んで、直すを繰り返す
  • Vim,LaTeX,Git,Evernote,Simplenote,Slack
  • ロングセラー > ベストセラー
  • 大学時代に「ある程度の長さを持った文章を定期的に書こう」と意識していた
  • 自分自身を含めたメタ分析（何を考えこの文章を書いたか）
  • プログラムを書くためのプログラムに似て、「プログラミング言語の本を書く」ってい うのは「言葉の本を言葉で書く」こと
  • ECMA-262というJSの規格書は文章ではなくコンパイルしてコードとして読む
  • 文書の上手い人は読まれたときにどう処理されるか予測できる人
  • 自分の欲求を満たすのではなく読者の欲求を満たすことを考える

縁の下のUIデザイン 中国のスマートフォンアプリの共通項

  • 池田 拓司
  • カラフルなデザインが多い
  • グラデーションを利用し下層へ導線を張る
  • アプリ内でキャプチャをするとキャラが出てくる
  • 住んでる場所、いる場所を指定できるUIが多い

最新CDN入門

CDNとは何か

  • 佐藤 歩
  • CDNの基本は、分散ネットワークによるキャッシュと配信
  • CDNの分散ネットワークは、PoP（Point of Presence）と呼ばれる世界中に置かれたエッジサーバ群で構成される
  • キャッシュ、伝送距離の短縮がメインの高速化
  • アクセス集中時の安定化
  • オリジンの通信費の削減
  • HTTP/2の恩恵
  • PoPが日本にあるかチェックしよう

HTTPキャッシュの基礎知識

  • ローカルキャッシュ（ブラウザなど）
  • シェアードキャッシュ（プロキシサーバー、CDN）
  • ナビゲーションリソース（HTML,APIレスポンス）
    • ブラウザでURLを入力したりリンクを選択したりしたときに発生する画面遷移に必要な最初のリソース
  • 静的リソース （CSS、JavaScript、画像）
    • HTMLにより取得される
  • Cache-Controlが基本
    • public,max-ageなどはディレクティブという
    • publicはCDNなどでシェアードキャッシュされる
    • privageCDNなどでシェアードキャッシュされない
    • no-storeはキャッシュされない（Fastlyはキャッシュする）
    • immutableはリロード時もキャッシュを返す
  • Expiresヘッダは古い規格で日付を指定する（Cache-Controlが優先される）
  • 期限が切れたら有効性検証を行う
    • 更新されていなかったら304 Not Modifiedを返す
  • no-cacheは有効性検証をしてからキャッシュする
  • must-revalidateは有効性検証時にオリジンサーバに到達できない場合は504 Gateway Timeoutを返す
  • Etagレスポンスヘッダがあれば、検証時にIf-None-Matchヘッダをつける
    • ハッシュを送ってサーバーでチェックする
  • Last-ModifiedとIf-Modified-SinceはEtagとほぼ同じ（こっちは日付）
  • stale-whilerevalidate=60を指定するとキャッシュが切れても1分は古いキャッシュを使う
    • 裏でキャッシュ更新する意図で使われる
  • stale-if-error=60を指定するとサーバーでエラーが起きていても1分はキャッシュを使う
  • UAを見て同じURLでも違うコンテンツを返す可能性がある
  • Varyヘッダを使ってCDNキャッシュをコントロールできる
  • Fastlyは50ドルの無料枠がある
  • Fastly内のキャッシュが利用されたかはx-cacheで確認できる
  • オリジンサーバーはFastlyのみアクセスできるといった保護が必要（セキュリティ目線）
  • Basic認証をVCL（Varnish Configuration Language）で付与する
  • もしくはIP制限
  • TLS配信
  • Surrogateヘッダ
    • Surrogate-Controlヘッダ
    • SurrogateCapabilityヘッダ
    • Surrogate-Keyヘッダ
  • Surrogate-Keyヘッダ
    • スペースで区切られたキーに従ってURLを関連付ける
    • Surrogate-Key: key1 key2
  • キャッシュパージ
    • 有効期限を待たずキャッシュを削除する機能
  • Fastlyは150ミリ秒で消せる
  • ソフトパージするとTTLを0にする
  • Surrogate-key単位で消せる
  • シールドPOPという複数POPが存在する際のオリジンと通信する唯一のPOP
  • FastlyはVarnishベール
  • サブルーチンごとの処理が大切
  • クライアントからのリクエスト情報に関するreq.*変数
  • オリジンサーバからのレスポンスに関するberesp.*変数
  • Fastlyからクライアントへのレスポンスに関するresp.*変数
  • Fastly VCL boilerplateというテンプレートが準備されている
  • VCL snippetsはスニペットを作って埋め込みができる
  • Custom VCLは全体を直接いじれる
  • API,Terraformも対応している
  • CDN前提の設計が必要
  • キャッシュサーバー、エッジサーバーの処理の委譲は根幹に関わる設計
  • 誰でも同じ情報であるパブリックコンテンツとユーザーごとに異なるプライベートコンテンツを適切に分離する
  • パブリックコンテンツは積極的なキャッシュとヒット率の向上を目指す
  • TTLを更新頻度、反映遅延許容度に合わせて決める
  • パージも利用する
  • ESI
<body>
 <main>
 <!-- 通常のコンテンツ -->
 <esi:include src="/foo-contents.html" />
 </main>
 <aside>
 <!-- 新着情報 -->
 <esi:include src="/bar-updates.html" />
 </aside>
</body>
  • privateなものはシェアードキャッシュを禁止させる
  • リクエストヘッダへのユーザー属性付与はABテストなどに利用ができる
  • UAは数千パターンあるので正規化したフラグに変換する
  • 同じURLでもUAとかで返す情報が違うので、そこも考慮する必要がある
  • 静的リソースはrivvingというファイル名にハッシュ値とかを入れてキャッシュさせる
  • SWはrivving適用しないほうが良い
  • 画像は入稿されるものとUIのものは区別して戦略を考える
  • フォントは強くキャッシュ
  • 画像を最適に配信する
  • リサイズやクロップ
  • 画像の圧縮
  • webpへの変換
  • セキュリティも一部任せられる
  • DDosやBotとか
  • エッジコンピューティング
  • Lambdaとか
  • クライアントからCloudFrontへのリクエストおよびレスポンス
  • CloudFrontからオリジンサーバへのリクエストおよびレスポンス
  • クッキーを見てABテストしたり
  • Cloudflare Worker
  • SW形式
addEventListener('fetch', event => {
 let url = new URL(event.request.url);
// リクエストヘッダに"X-Use-Dev"が含まれる場合は
// ホスト名に"dev."を追加する
 if (event.request.headers.has('X-Use-Dev')) {
 url.host = "dev." + url.host;
 }
// プロトコルはhttps固定にする
 url.protocol = 'https:';
// 変更したURLでオリジンサーバにリクエストする
 event.respondWith(fetch(url, event.request));
});

Kotlin

Puppeteer

  • ヘッドレスchromeと扱うライブラリ