「JAMSTACK Meetup #1 with microCMS」に参加してきました

  • JAMSTACK Meetup #1 with microCMSに参加してきました。

re-build.connpass.com

タイトル 発表者
Janstack × microCMS実装編 柴田さん(microCMS)
Nuxt.js + microCMS + Netlifyでコーポレートサイトをリニューアルした話 カンボさん(Re:Build)
WordPress(Shifter)をHeadlessCMSにした自社サイトをGridsomeとNetlifyで作ってる話 阿部さん(necco)
Jamstack で開発してすると、今までのつらみ😇がなくなって、ちょっとコストも下がる話 shota_coffeeさん
GitHub Actionsで始めるお手軽Jamstack 西畑一馬さん(トューアール)

Janstack × microCMS実装編

  • 柴田さん(microCMS)

Jamstackとは

  • Webサーバに依存しないサーバーレス
  • 事前にビルドした静的ファイルをCDNで配信
  • APIはJS経由で呼び出す

Jamstackのいいところ

  • 静的ファイルをホスティングするだけでいい
  • APIコールはビルド時のみ
  • 高セキュリティで高パフォーマンス
    • 静的ファイルをCDNで配信するだけだから

microCMSとは

  • 日本製HeadlessCMS

microcms.io

  • 技術構成
    • AWS Amplify
    • サーバーレス
    • React

microCMSのいいところ

  • 開発者と非開発者が使うけど双方に使いやすく
  • GUIAPIを作成
    • 項目を選択して入力フォームを作る
    • 入力して投稿した内容をAPIで取得できる
  • 権限管理もできる(有料プラン)
    • APIの構成(記事の入力フォーム)の作成までできる権限
    • 記事の投稿だけできる権限
    • 記事の下書きのみできる権限
  • 画像の加工もURLで対応できる
    • サイズとか

Jamstackの実装(Nuxt)

  • 主な静的サイトジェネレーター
Rest API GraphQL
React系 Next.js Gatsby
Vue系 Nuxt Gridsome
  • 動的なコンテンツ
    • ビルド時にAPI叩いてURLを生成
    • ブログ記事一覧をとってきて、みたいな感じ

まとめ

  • Jamstackは速くてセキュアで安い
  • microCMSすごい
  • 実装はちょっとむずい(SPA詳しければできちゃう)

Nuxt.js + microCMS + Netlifyでコーポレートサイトをリニューアルした話

  • カンボさん(Re:Build)

JAMstackの実装

  • コーポレートサイトをJAMstack化
    • レスポンス速度が向上
  • Nuxt + Netlify + microCMS
    • NuxtをNetlifyにデプロイ
    • ビルド時にmicroCMSを叩いてデータを取得
  • GitLabのmasterにプッシュされたら自動でビルドデプロイ
  • microCMS
    • APIのクエリがいろいろあってドキュメントも親切(日本語)
    • APIのレスポンスのプレビューも見られる

WordPress(Shifter)をHeadlessCMSにした自社サイトをGridsomeとNetlifyで作ってる話

  • 阿部さん(necco)

Jamstackのいいところ

  • コンテンツとフロントエンドの開発を分離できる
  • 非エンジニアがどんどんコンテンツを更新できる

構成例

Jamstack で開発してすると、今までのつらみ😇がなくなって、ちょっとコストも下がる話

  • shota_coffeeさん

CMS導入事例

  • JS
    • Nuxt
    • Next
  • API
  • hosting
    • Netlify
    • Firebase
  • 変更可能性のあるものは全てAPIにする
    • 編集者はコンテンツを気軽に変更できる
    • 開発者は何も待たずにサクサク開発できる
  • コミュニケーションコストが大幅に下がった

GitHub Actionsで始めるお手軽Jamstack

  • 西畑一馬さん(トューアール)

Gatsbyのいいところ

  • GatsbyのImage
    • 画像をいろんな形式いろんなサイズにビルドしてくれる
    • LazyLoadしてる間スケルトン出してくれる

Jamstackのデプロイフロー

  • 一連の流れ
    • pushしてコンテナでクローンビルドされてデプロイされる
  • コード管理
  • CI
    • GitHub Actions
    • GitLabCI
    • CircleCI
    • Jenkins
  • ホスティング
    • Netlify
    • now
    • S3
    • FirebaseHosting
    • GitHub Pages
  • プレイヤーが多くてややこしい

「Mercari x Merpay Frontend Tech Talk vol.4」に参加してきました

  • Mercari x Merpay Frontend Tech Talk vol.4に参加してきました。

mercari.connpass.com

タイトル 発表者
Pros and Cons of SSR and JAMStack @_sskyu
NoCode で CMS と連携するデザインツールを作っている話 @miyaoka
TypeScriptで型安全に入門したい @atsuco_02
Web Assembly と画像・動画 @Leonardo_engr

Pros and Cons of SSR and JAMStack

  • @_sskyuさん

SSRパフォーマンス

  • キャンペーンページのSSRのパフォーマンスがでない
    • NuxtでSSRしてる
  • Podをスケールして負荷に耐えていた(20Pod)
    • 単純なLPを配信したいだけなのに...
  • 負荷試験してみた
    • コンテンツの量でrpsに差が出た
    • SSRしない範囲を増やすと多少改善できた

nuxt generate(JAMStack)

  • nuxt generate
    • NuxtでhtmlをSSR時ではなくビルド時に生成する
  • 課題
    • nuxt generate時にuseragentがとれない
      • ios/android/web/appのwebviewで画面が違う
      • navigator.userAgentSSR時はとれない
      • v-showisAndroidとか使えばSSR時はotherになるけどクライアント側で正しい値取れて画面出せる

JAMStackに移行

  • キャッシュレスキャンペーンでJAMStackに移行
    • 2019/10/1-2020/6/30に出してるキャンペーン
  • 移行手順
    • JAMStack環境作る
      • 旧版と並行稼動
      • 社内のみからアクセス
    • 本番にデプロイ
      • テスト
    • 本番有効化
      • 切り替え
  • staticなファイルなので全てFastlyで配信
    • 以前はk8s上のNodeから配信
  • URL
    • 旧版と同じオリジンにおいた
    • 新版のURLにネームスペース付けた
      • そのままだとassets読み取れないけど相対パスで指定するようにして解決

Pros and Cons

  • SSR
    • サーバを運用してる
    • オンコール体制
    • スケールアウトでコスト増
  • JAMStack
    • 静的なassetを配信するだけなのでオンコール不要
      • ぺらいちなサイトに向いてる
    • 管理画面のようなサイトは不向き
  • パフォーマンスの比較記事

developers.google.com

NoCode で CMS と連携するデザインツールを作っている話

  • @miyaokaさん

Studio

  • GUIでWebページが作れるサービス
  • やってるユーザの操作に応じてstate更新して画面に反映してるだけ
    • 操作してる人からするとGUIだけで画面が作れちゃう
  • 課題
    • 静的なサイトはこれでできる
    • 動的なデータの概念がないので動的なサイトが作れない

動的ページを作る

CMSと連携

  • zero configで使えるようにしたい
    • 独自で作った
  • CMSで作ったコンテンツをデザインに注入できるように

TypeScriptで型安全に入門したい

  • @atsuco_02さん

型安全に入門したい

  • 型安全の良さを理解したい

環境構築めんどくさそう

  • CodeSandboxで環境構築いらず

TypeScriptって何者?

  • TSはJSにコンパイルされるスーパーセット
  • コンパイル前に型チェックが行われる
  • 値に対して型が決まると実行できる操作が明確になる=型安全
    • 型があると操作が限定される=>意図せぬエラーが防げる

JSとTSの方の違い

  • JSにも型ってあるよね
  • JS
    • 実行時に型を判別
    • 自動で型変換される
  • TS
    • 実行前に型を判別

TSの型の良さ

  • 型を明示的なので可能な操作が明確
  • 暗黙的な変換がされない
  • コンパイル時にある程度エラーがわかる

Web Assemblyと画像・動画

  • @Leonardo_engrさん

JavaScriptだけで画像加工

github.com

  • PWAのアプリが増えてきている
    • 画像加工のような処理もクライアント側でやりたい
  • ImageMagickにできることならだいたいできる
  • 画像を比較してdiff出せたりする

JavaScriptだけで動画をエンコード

  • ffmpeg.js
    • あまりメンテされてない

github.com

  • スマホの処理性能上がってきてる
    • リアルタイムで画像にエフェクトとかアプリだとでてきてる
  • WebWorkerと組み合わせて使えるように用意してくれてる

「#webbundle_study」に参加してきました

  • webbundle_studyに参加してきました。

web-study.connpass.com

タイトル 発表者
Web Packaging: Web Bundles @horo
WebPackaging Spec @jxck

Web Packaging: Web Bundles

  • @horoさん

Web Packaging

  • Webリソースをひとまとめにする技術
  • W3Cで検討されている仕様
  • その中にWeb Bundles

Web Bundles

  • HTTPリソースをまとめるための仕様
  • .wbn
  • 近くにいる人にwbnをシェアすることもできる
    • アプリで
    • USBで
  • ファイルがローカルにあるので表示がはやい

Web Bundleの作り方

www.npmjs.com

Subresources Web Bundles

  • linkタグでwbnからとってくると指定できるようになる
  • htmlごとbundleするのではなくcssとかjsだけbundleするようなシーン

Page Web Bundle

  • 同一originでなくても同一originのようにロードできる
  • アセットがたくさんあるような場面で使うイメージ

Save as Web bundle

  • ページを右クリックからwbnで保存できるようにする
  • 印刷して保存するような雰囲気
    • cacheにアクセスしたりとかはできない

TWA

  • PWAをPlayストアにAndroidアプリとしてあげられる
  • 動きとしては特定のURLを開く
  • 課題として初回アクセス時オフラインだと表示できない
    • Web Bundleでかいけつできるのではないか

WebPackaging Spec

WebPackaging Spec

  • SXG
  • Web Bundles
  • Loading

Web Bundles Spec

  • どういう風にbundleが動くかしか定義してない
  • arrayをcborというフォーマットでバンドルする
  • index/response/signetureなどどこに入ってるか決まってるから全部パースしなくても欲しい情報をとれる
    • zipとかだとそういうことできないからわざわざwbnを使ってる
  • どのaccept-type来たらどのcontent-type返すかとかハンドリングできる
    • 多言語用意しておいてaccept-languageによってどれ返すか制御したりとかが想定ユースケース
    • 配布することも考えると多言語全て入れておいた方がいいかもとかっていう話も
  • bundleしてる各ファイルに対して署名しないといけない

Serve Web Bundle

  • HTTP
Content-Type: application/webbundle
X-Content-Type-Options: nosniff

「年の瀬に振り返る Figma & React コンポーネントでのサービス開発」に参加してきました

spacemarket.connpass.com

タイトル 発表者
Figma・Storybookでのコンポーネント運用から考えるデザインシステムとの付き合い方 伊東 将太
2019年の Atomic Design コンポーネント設計 原口 渉
パネルディスカッション 横井 麻里乃 / 小林 春彦

Figma・Storybookでのコンポーネント運用から考えるデザインシステムとの付き合い方

  • 伊東 将太さん

FigmaでUIコンポーネントを運用

  • どんなコンポーネントがあるか視認性を高めたい
  • 操作感を確かめられるようにしたい
  • AtomicDesign
    • Atomsはデザイナー
    • それ以降は実装しながら
  • デザイナーとフロントエンドエンジニアの協業が楽になった

運用していく中で

デザインシステム

  • デザイン原則
  • ガイドライン
  • カラーパレット
  • アイコン
  • パターンライブラリ

Storybook

  • コードでデザインシステムを可視化できるのがいい
    • より本番に近い状態

まとめ

  • プロダクトの方向性を明確にして開発効率/一貫性を向上したければ取り入れる価値ありそう

2019年の Atomic Design コンポーネント設計

  • 原口 渉さん

マークアップ

コンポーネント推進PJ

共通コンポーネントの反映

  • せっかく用意してあるのに使われていないページがあった
    • 同じコンポーネントwpそれぞれで実装しているため修正もれやデザインのばらつきが起きる
  • 共通ライブラリを変更したら利用者も更新されるようにした

コンポーネントの粒度と命名規則の策定

  • 明確に決めてなかったので作業者によってばらついていた
  • 似た見た目でもコンポーネントを分ける
    • 再利用性は副次的なものと考えた
  • OrganismsとMoleculesの基準
    • 単体で意味を成せばOrganisms
  • 命名規則
    • Page名を接頭辞につける

課題管理フローの策定

  • JIRAで可視化

プロダクトとStorybookの状態が異なる

  • 本番だけ反映されてStorybookが更新されていないことがあった
    • storiesのファイルを先に書くようにした?
    • 定期的にチェックするようにした

まとめ

  • デザイナーとエンジニアで共通の認識を持つことができた
  • デザイナーと連携とりやすくなった

パネルディスカッション

  • 横井 麻里乃さん
  • 小林 春彦さん

なぜAtomicDesign

  • photoshopのファイル数が150超
    • 管理しきれなくなった
  • もともとデザイナーとエンジニアで別リポジトリで同じようなもの管理してた

組織的なコンポーネント運用の課題

  • リリース優先でコンポーネントをきれいに運用することは後回しになりがち
    • Atomsだけはきれいに管理すると決めている
  • 同じ設計ルールで誰でも作れるようにする工夫が必要
    • 自動化とか仕組み化をしていきたい

なぜFigma

  • いろいろ変遷してる
    • コミュニケーションがしやすいからFigmaにした
    • Figmaにコメント書くとSlack連携できるように

「【We Are JavaScripters! 3周年記念】 WeJS Festival !」に参加してきました

  • 【We Are JavaScripters! 3周年記念】 WeJS Festival !に参加してきました。

wajs.connpass.com

  • WeJSの3周年記念のイベントに参加してきました
  • 自分が初めてWeJSに参加したのも2017年7月に開催された9thなのでもう2年以上前です。勉強会に行き始めたころなので懐かしいものです。
発表枠 タイトル 発表者
初心者LT はじめてのユニバーサルJavaScript @りゅーそう
初心者LT A story about making a cli twitter client with typescript @azawakh
初心者LT styled-components の ` ←について @kimizuy
初心者LT 逆算して考える広告ライブラリ @ta__ho
初心者LT Node.js/serverlessでおこなうDX改善 @Ayami Otani
通常LT おさらいVue Composition API Morita_Masatoshi
通常LT Lighthouse CI入門 @yinm
通常LT Reactの歴史 @mqtsuo02
通常LT 執筆の進捗を支える技術〜Could RunでBot作ったらとても便利だった件〜 @kyasbal
通常LT angular歴3ヶ月がAngularと本気で向き合ってみた @EmiYaegashi
Demo LT PlayCanvasでできたこととデモ @sushucorn
Demo LT TensorFlow.jsとobnizで作る笑顔あふれる職場 @boiyama
Demo LT Ma_gician <Vue にはできないこと(2)> @StewEucen
Demo LT 今日から始めるWeb USB @takanorip
Demo LT Joy-ConをJavaScriptでプレゼンリモコンにした話 @mascii_k
Short Session Introduction to ReasonML @Naturalclar
Short Session JSXでつくる宣言的プレゼンテーション @mottox2
Short Session JSでの時間の使い方の話 @chikoski
Long Session Behind the scene @brn227
Long Session Babel plugin を作って AST と Babel を学ぶ(ライブコーディング) @mki_skt

Introduction to ReasonML

  • @Naturalclarさん

Reason

  • State of JS 2018
    • 半分は聞いたこと無い
    • 使ってる人の満足度は高い
  • Reactの作者Jordan Walkeが作っている
  • Ocamkを別のSyntaxで書いたもの
  • 強力な型
  • BuckleScript
    • JSにトランスパイルする
  • 特徴
    • JSのように書ける
    • React書ける人は馴染みやすい
  • 利点
    • ビルドが高速
      • 規模が大きくなっても数秒
    • バンドルサイズが小さい
      • 結果が自明なものはトランスパイル時に変換してくれる
    • Prettier完備
      • もともとはReasonのフォーマッターが優秀でそれをJSでも使えるように作ったのがPrettier
    • 型安全性
    • エラーメッセージがわかりやすい
  • gentype
    • tsxを生成したりできるライブラリ
    • 徐々に移行したいときはこれを使うといい
  • reason-react-native
  • reason-native

JSXでつくる宣言的プレゼンテーション

  • @mottox2さん

KOBIT

  • GoogleAnaryticsと連携するとPowerPointのレポートができるサービス
  • PowerPointはzipされたxmlの集合体
  • レポートなのでmarkdown to pptxでは表現できない

課題

  • コードから生成後の見た目が想像しづらい
    • JSXで宣言的に書く
  • 座標計算が大変
  • JSXからSketchを生成するReact Sketch.appを参考に

仕組み

  • react-test-renderer
    • JSXをObject化できる

github.com

JSでの時間の使い方の話

  • @chikoskiさん

JavaScriptの実行タイミング

  • どんな順番で呼ばれるの?
    • addEventListener
    • requestAnimationFrame
    • requestIdleCallback

EventQueue

  • タスクはキューにたまっていく
  • キューの中の処理でスタックがたまっていく
  • いろんな処理が全て同じキューに溜まっていく(メインスレッド)
  • Chromeのdevtoolsのperformanceでタスクキューを見れる

実行の順序

  • Dont yield
    • 普通のJSの処理
  • Microtask
    • awaitとか
  • requestAnimationFrame
  • Inter-frame
  • requestIdleCallback
    • CPUが暇な時に動く

Worker

  • 全部メインスレッドでやるのをやめようという話もある
  • UIスレッドをわける
  • Worker
    • EventQueueをもう1つ作る
    • 並列に実行される
    • コンストラクタの第2引数に{type: module}でESModulesも使えるようになる
    • postMessageはJSオブジェクトなら渡せる
      • コピーして渡される
        • 処理時間は無視できる程度
  • Comlink
    • postMessageを抽象化してくれる
  • SchedulingAPI
  • 無限ループを書きたい時
    • priorityを設定できるようになる仕組みも考えられている
    • それを使えばブロックしないようにできる

Behind the scene

  • @brn227さん

Scriptのクリティカルパス

  • HTMLをparse
  • リソースをfetch
  • V8が実行

Resource Fetch

Scriptタグの種類

  • ClassicScript
    • 普通のscriptタグ
  • ModuleScript
    • ESModleに対応したscriptタグ
    • import/exportを解決できる
  • Async
    • scriptタグの順番待ちが発生しないロードも実行も非同期
  • Defer
    • ロードは非同期だけど実行は順番を待つ

Connection

  • HTTP1.1だと同時接続数の上限がある
    • 大抵のブラウザは6まで
    • なので非同期で同時にたくさん取りに行っても上限を超えると待たされる
  • HTTP2だと1つのコネクションで複数のやりとりできるので解決される

Fetching

  • ブラウザキャッシュがあるかチェック
    • ETag
      • リソースに対して一意に発行されるハッシュ
      • Cache-ControlとETagを組み合わせてキャッシュを使うか決める
    • ServiceWorker
      • リクエストをインタラプトできる
      • ChacheStorageに入れておいてそれを返すことができる

最適化

  • Preload
    • link rel=preload
      • 事前にリソースをリロードさせておける
  • Compress response
    • gzipではなくBrotliを使うと更に圧縮率高められる
  • CDN
    • 地理的に近いところから取得
  • webpackプラグイン
    • Workbox
    • sw-precache
  • Code Splitting
    • 必要なものだけを取得できるように

Futuer

  • HTTP/3 Quic
    • Transport層を置き換える
  • Priority-hints
    • linkやscriptにimportance属性が追加される
    • highがついてれば優先的に取得する等
  • WebBundle/WebPackaging
    • Webのコンテンツを1つにパッケージングして配信
      • 画像でも動画でも全部
      • request/responseとか証明書とかも
      • Webサイトまるごとpackagingして配信して使える

Parsing

  • fetchしたscriptをASTに変換するフェーズ
  • parse処理は重い
    • ページする度に全部parseしてるとおもすぎる
    • 最初は関数と行数だけparseしておく
    • 呼び出されると関数の中身までparse
  • parseも全部メインスレッドで動いている
    • parseが始まった段階でHTMLの表示がとまる
    • deferとかasyncをつけると変わる

Streaming

  • Streamingで逐次取得しながらparseする

bundle size

  • 50-100KB目安に分割するとよい
    • モバイルとかも考えると
    • CPU/メモリ使用量がかかる

Transpile

  • 古いブラウザようのコードは新しいブラウザにとっては無駄なコード
  • ブラウザに応じて調整すると無駄なものを減らせる

JSON.parse

  • objectにこれをつけておくと遅延してparseされるのではやくなる

Polyfill

  • CoreJS全部入れちゃったりすると無駄が多すぎる
  • polyfill.ioを使って必要なものだけにするといい

Futuer

  • Binary AST
  • ASTで直接配信する
    • ブラウザごとに共通仕様ができればいける

Babel plugin を作って AST と Babel を学ぶ(ライブコーディング)

  • @mki_sktさん

AST

  • Abstract Syntax Tree
  • プログラムの構造を示したデータ
  • JSではJSON
  • 仕様はESTreeに準拠
  • AST Explorerを使うとJSのコードがどう変換されるか見られる

astexplorer.net

Babel

  • JSのコンパイラ
  • もともとは6to5だった
    • ES6 to ES5
  • そこからいろんな機能が追加されていった
  • 新しい構文で書いたJSを古いブラウザでも動かしたい時に使う

構文変換

  • TS/JSX/JSなど -> Babel -> JS
  • 変換のフェーズ
    • Parsing
    • Transformation
    • Code Generate
Parsing
  • @babel/parser
  • コードをparse関数に通すとJSONで出力される
  • acorn
    • 軽量なJS parser
    • webpackで使われてる
Code Generate
  • @babel/generate
  • ASTをJSに変換する
Transformation
  • @babel/traverse
  • constとletをvarに変えるといった変換を行う

ライブコーディング

github.com

「JSConf JP(Day2)」に参加してきました

  • JSConf JPに参加してきました。
  • 2日目の参加メモです

jsconf.jp

タイムテーブル

時間 タイトル 発表者
11:00- 時間はただの幻想である… JavaScriptにおいては Jennifer Wong
InversifyJSを用いたレイヤードアーキテクチャの構築 奥野 賢太郎
Vue.js で D3.js を使ったインタラクティブなデータの可視化 Shirley Wu
11:30- ストリームの人生 Dominic Tarr
Build and scale multiple Voice application by using TypeScript Hidetaka Okamoto
13:00- Web の体積 Jxck
正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終 Masato Nishihara
パスワードは90年代の代物だ Sam Bellen
13:30- JavaScript, Rust and Wasm Walk into a Ramen Shop ... Irina Shestak
Migration from React Native to PWA ohbarye
npm i -g @next-and-beyond: Building the future of package management Claudia Hernández
14:15- JSConf Panel Talks Jan Lehnardt and Yosuke Furukawa
GraphQLを用いたECサイトにおけるパフォーマンス改善 澤井宣彦
Minimum Hands-on Node.js 栗山 太希
14:45- 悪用された npm パッケージの分析 Jarrod Overson
JavaScriptのままでTypeScriptを始める 高梨ギンペイ
15:30- Browser APIs: 知られざるヒーロー達 Rowdy Rabouw
Your benchmark may not guide a real application performance Tetsuharu OHZEKI
16:00- Anatomy of a Click Benjamin Gruenbaum
JavaScriptとSwift/JavaをつなげるCapacitorと、これからのWeb Frontned. 榊原昌彦
Recruit Speed Hackathon 新井 智士
16:45- AIとJavaScript による生物認識 Jonny Kalambay
大規模アプリケーション開発でのElm実践 海老原 圭吾
17:15- Pika: レジストリの再創造 Fred K. Schott
最新のWeb技術でIoT開発をする 木戸 康平

InversifyJSを用いたレイヤードアーキテクチャの構築

  • 奥野 賢太郎さん

密結合とは

  • 修正を加えた時にその影響箇所が見つけづらい状態
    • 予期しないところに影響が及ぶかもしれない状態
    • DBの構造
    • 外部サービス
    • APIの構造
    • 画面の構造
    • 画面の入力フォームの構造のままテーブル設計してしまった
    • 画面の構成変えたけどDBいじる余裕ないから無理やり対応することに・・・
  • 抽象化する中間の層が必要

レイヤードアーキテクチャ

  • DDD
    • Domain Driven Design
  • MDD
    • Model Driven Development
  • Repository

DIP

  • InversifyJS
    • DIの機能を提供するライブラリ
    • constructor injectionできる
    • TypeScriptで書いた方が相性が良い
  • TSyringe
    • Microsoft
    • InversifyJSと同じ感じのやつ
    • 好みではあるけど登壇者はこっちの方が好き
  • レイヤーごとにmodel objectを用意する
    • バグが起きたときの影響範囲がわかりやすいように寿命を短くするとよい
  • value objectを作るようにする
    • バリデーションはconstructorで
  • knex
    • ORMapper

Build and scale multiple Voice application by using TypeScript

  • Hidetaka Okamotoさん

スマートスピーカーのバックエンド

  • 音声/言語処理系の知識がなくても開発できる
    • Speach To Textや自然言語処理はサービス側の責務
    • バックエンドには処理後のJSONが送られる
  • Webhookの開発と同じような感じ
    • SlackやLINEのbotに近い
  • 文脈を覚えておくためにDBも持っておくことが多い

Alexa開発

  • ask-adkを使う
  • スキルが増えると起こる課題
    • スキルが増えるとLambdaも増えるからruntimeの更新など面倒
    • 同じような処理がいろんなスキルに存在してしまう
  • 多機能な1スキルか単機能な複数スキルか
    • 単機能なスキルの方が使いやすい
    • でも見つけてもらうのが大変かも
  • ServerlessFrameworkを使うと便利
    • 全部yamlで管理できる
    • runtimeのアップデートなども設定かえるだけ

まとめ

  • VUIはWebhookライク
  • in/outのフォーマットが一定のためTS相性良し
  • 汎用FWがまだない

正攻法はあるのか !? 泥臭く戦った Node.js バージョンアップ一部始終

  • Masato Nishiharaさん

背景

  • Node6を使ってたが2019/4にEOL
  • Node8は2019/10にEOLだったので一気に10に
    • 10のEOLは2021/4

やったこと

  • Node変更差分確認
  • 依存パッケージの変更差分確認
  • 全機能テストを複数回

パッケージの差分

  • 依存ライブラリのリリースノート全部見たりするのは現実的でない
  • Node10に対応しているか明記していないものもあった
  • =>全機能テストで動けばよいとすることに

全機能テスト

  • ブラウザバリエーションもあるので大変
  • 1回目で不具合を出して対応して2,3回目もやった

リリース後

  • CPU100%にはりつくトラブル
  • スレッドの切り替えをする処理が多発していた
    • Nodeはシングルスレッドじゃないのか?
    • 内部的にはマルチスレッドで動くところもある
    • libvuの中でマルチスレッドを利用している
  • このケースでは原因はDBサーバだった
    • 障害のあったサーバからDBサーバへのアクセスが遅延していた

まとめ

  • こまめに上げるようにするとよさそう
  • コアな部分だけでも自動テストはあった方がいい

Migration from React Native to PWA

  • ohbaryeさん

React NativeからPWAへ

  • iOS/Andorid対応のRNアプリをiOS/Android/Web対応のPWAにする
    • 後者のiOS/AndroidはWebViewでPWAを表示する

なぜReactNativeだったか

  • プッシュ通知など使いたいからスマホアプリがいい
  • iOSエンジニアがいなかった

BYOD化

  • 端末を用意してインストールして渡してた
    • 端末配布をやめてBYOD化することにした
    • Android版の提供も始めることにした

マルチプラットフォーム対応

  • iOSで動くのにAndroidで動かないとかがかなりあった
  • JSのエラーなのかライブラリの中身が悪いのかネイティブのレイヤーが悪いのか

パッケージ管理

  • ReactNativeはnpmでライブラリ管理してるがその先にiOS/Androidのライブラリがある

ビルドデプロイシステム

脱ReactNativeの選択肢

  • PWA
  • Nativeで書き直す?
  • Flutter
  • => ブラウザで見たいという要件もあったのでPWAで
    • React使った

通知

  • Push Notificationの実現
    • AndroidはWebでも使える
    • iOSはWebViewとして使うのでネイティブの機能を使う

WebViewで苦労したこと

  • キャッシュのレイヤーが増えることに注意
  • WebViewのキャッシュを無効化するメソッド用意したりとか

PWAで供料したこと

  • Android ChromeだとアイコンにつけるバッヂはまだExperimental
  • フォアグラウンドでの通知がAndroid PWAだけ挙動が違った

テスト

  • cypressでintegrationテスト書いてる
  • ReactNative時代はスナップショットテストとかやってた

運用してみて

  • Webなので即時反映されるのでいい

まとめ

  • チームメンバーのスキルセットにあった技術選定が大事
    • 開発できる = 運用できるではない
  • モバイルアプリに近い体験要求されてもWebでもできるかも

GraphQLを用いたサイトにおけるパフォーマンス改善(ECサイトを題材に)

  • 澤井宣彦さん

背景

  • 歴史が長くページ遷移が遅い
  • 全社のリブランディング
  • ページ遷移の改善
  • 技術スタックの改善

リニューアル

  • フロントはReactをTSで
  • Backendは既存RailsAPI
  • API定義はGraphQL
    • トップページをリッチにしたい構想
    • フロント側に自由度をもたせたいから

パフォーマンス改善

計測

  • 実機で行うテスト
  • 合成環境で行うテスト
    • PageSpeed Insighrsを使った

ボトルネックの特定

  • ChromeのAudit
  • Opportunitiesの改善項目

改善

フロント側の改善
サーバ側の改善
  • APMを活用
    • 既に入れていたDataDogを活用
  • N+1のDBアクセス問題
    • batch-loader(rubyの場合)などを使って対応するようにする
QueryとSchemaの改善
  • ページングのない配列のrequest
    • 関連するレコードが全件取得されるので性能が劣化
    • ページングをつけて件数指定する
    • schemaのlinterで未然に防げそう
  • 全く使ってないデータを取得している
    • queryを消せばよい
    • なぜ画面に紐付いてないqueryが書かれてしまうか
    • FragmentとColocation
    • Fragment
      • queryを部分的に切り出したもの
      • 再利用できる
      • 部分定義できる
    • Colocation
      • Fragmentを集約して1つのqueryにまとめる
    • Reactコンポーネントの階層とqueryの階層をあわせるようにする

今後

  • Cacheの活用を検討
    • リアルタイム性が低いコンテンツもある
    • ゲストユーザは同じものが基本的に表示される
    • CDNのレイヤーでHTML/responseどちらもできるはず

JavaScriptのままでTypeScriptを始める

  • 高梨ギンペイさん

TypeScriptのいいところ

  • JSのスーパーセットであること
  • 型を持つこと

Typed-JavaScript

型がつくと何ができるようになるか

  • バリデーションできる
    • 関数を呼ぶ時にどんな引数を渡さないといけないか?
      • ドキュメント見る?
      • 動かしてみる?
      • 型があればすぐに分かる
      • エディタが対応してればその場でわかる
  • エディタの補完がきく
    • 自分で作ったAPIの補完も型を用意しておけば補完される
    • 標準関数なんかもググらなくてもその場で候補がでる
  • リファクタリングがしやすい
    • 変数名後から変えたり型を後から変えたり
    • 変更漏れがあればコンパイルエラーになってくれる

使い方

  • tsconfig.json
    • allowJsをtrueで.js対象になる
    • checkJSをtrueでjsもチェック対象になる
    • noEmitをtrueで型チェックだけするようになる
    • checkJSをfalseにしてチェックしたいファイルにコメントで@ts-checkつけるでもいける

まとめ

Your benchmark may not guide a real application performance

  • Tetsuharu OHZEKIさん

ソフトウェアのパフォーマンス

  • 遅いソフトウェアより速いソフトウェアの方がよい
  • どのように速くするか
    • Dont't guess, measure
  • ベンチマークを使う

ベンチマーク

  • シナリオに沿ったベンチマークになってますか?
  • 一般的な指標はベンチマークの1つでしかない
    • Lighthouseだけやってればいいわけではないケースも多い

JSの最適化

  • 一度の実行だと数ミリsecで差がわかりづらい
    • じゃあ数万回実行しよう
    • =>それでいいの?
      • 何度も実行されるとJSVMが複数レベルで最適化してくれる
      • その処理は何度も呼ばれるような処理なのか?

どのように改善を進めるか

  • プログラムを速くするには遅くなるようなことをやらないことが重要
  • CIとしてベンチマークを計測して継続してプロットするといい
    • 容易に起動できて再現可能であるようにする
    • 細かい上下は必ず起きる
    • 長期での傾向をチェックする

まとめ

  • パフォーマンスを改善するにはリアルなシナリオが必要
  • 闇雲に測定するのではなくリアルなシナリオに基づくこと
  • ベンチマークテストをテストケースの1つとして追加し実行できるようにすること
  • まずはどのように使われていてどのように速くなると嬉しいのか調べるところから

JavaScriptとSwift/JavaをつなげるCapacitorと、これからのWeb Frontned.

  • 榊原昌彦さん

Capacitor

  • Webでアプリを作ってWebViewで表示できる
  • ネイティブの機能にアクセスできる
  • デスクトップアプリとしても作れる

Capacitorの使い勝ったあ

  • @capacitor/core
  • @capacitor/cli

iOS

  • SwiftをどうやってHTML/JSにつなげるのか
    • npx cap init
    • WebViewを100%表示されるものができる
    • Poddileでnode_modulesの中から引っ張ってきてる
  • HTML/JSがどうやってSwiftにアクセスしているか
    • ブリッジがwindowオブジェクトに値を埋め込んでる
  • Androidもだいたい同じ

UI

  • iOS/Androidそれぞれガイドに沿った見た目にできる

「JSConf JP(Day1)」に参加してきました

  • JSConf JPに参加してきました。
  • 1日目の参加メモです

jsconf.jp

タイムテーブル

時間 タイトル 発表者
13:00- Opening talk yosuke furukawa
13:30- The State of JavaScript Raphaël Benitte and Sacha Greif
14:15- 「繋がり」の可視化 Nadieh Bremer
WebAuthnで実現する安全・快適なログイン Eiji Kitamura / えーじ
JavaScript AST プログラミング: 入門とその1歩先へ Takuto Wada
14:45- オープンソース」の定義 Henry Zhu
覚醒するアクセシビリティ Lena Morita
4年分のプロシージャルなJS Andy Hall
15:30- Building and Deploying for the Modern Web with JAMstack Guillermo Rauch
Wrap-up: High Performance JavaScript Sho Miyamoto
JS開発者のためのSEOテクニック Martin Splitt
16:00- Write What Not How Jorge Bucaran
How to Boost Your Code with WebAssembly FUJI Goro / @gfx
Playing Pokémon Together with Node.js Samuel Agnew
16:45- Deno - JavaScript の新たな道筋 Kitson Kelly
Streams APIをちゃんと理解する 加藤 健志
You might also like... Maria Clara
17:15- Headers for Hackers Andrew Betts
Make it Declarative with React Toru Kobayashi
Web Accessibilityのすゝめ Nazanin Delam
18:45- 予測的 Prefetching によるパフォーマンス改善 Praveen Yedidi
18:55- Web Components era phase 2 Yoshiki Shibukawa
19:05- Cache Me If You Can Maxi Ferreira
19:15- Node.js でつくる Node.js - WASM/WASI ミニミニコンパイラー がねこまさし
19:25- React アプリのライセンス違反について dynamis

The State of JavaScript

  • Raphaël Benitte
  • Sacha Greif

JavaScriptの歴史

stateofjs.com

stateofcss.com

ES2019

  • Array.flat()
  • Object.formEntries()
  • Optional Catch Binding

フレームワーク

  • React
    • 使ってる人多いしそのほとんどがまた使いたいと言ってる
  • Vue
    • Reactよりは少ないけどのびてる
  • Svelte
    • 使ってる人は少ないけど学んでみたいという人は多い
  • Gatsby
    • 横ばい
  • Next.js
    • のびてる
  • ホスティングサービスも充実してきている
    • Netlify
    • Now
  • TypeScriptは60%くらいの人が使っている

WebAuthnで実現する安全・快適なログイン

  • Eiji Kitamuraさん

パスワードの問題点

  • Weak
  • Forgotten
  • Reused
  • Stolen

パスワードどうやって盗まれるか

ハックされる確率

  • キーロガーだと通常の40倍
  • フィッシングだと500倍
    • パスワード以外の情報もとられているケースが多いから
  • 被害の80%がフィッシング

パスワードが盗まれないようにする対策

  • 2段階認証
  • ワンタイムパスワード
    • SMS
    • フィッシングには弱い
    • 短時間有効なパスワードでもその場で送られたら意味がない
  • そこでWebAuthn

WebAuthn

  • これまでよりも強力なブラウザの認証
    • EdgeもFFも対応
    • Safariは部分的(でも時期に対応するだろう)
  • ハードウェアの鍵を使う(Authenticator)
  • 公開鍵暗号を活用した方式
  • Authenticatorにキーペアを作らせる
    • 公開鍵をサービスに送ってRegistrationする
  • 秘密鍵で署名をしてそれをサービスに送る
    • サービスは公開鍵で検証
    • 同じハードウェアを持っている人であると証明できる
  • 鍵はWebサイトのオリジンと紐付いて生成される
    • フィッシングに強い
    • たとえ盗んでも成功しない

二要素認証

  • ハードウェアをもっているという認証 + 記憶による認証
    • 多要素と多段階は違う
    • 記憶、所持、生体といった要素を複数組み合わせるのが多要素認証
  • セキュリティキー
    • PCに接続するとブラウザにポップアップ出る
    • ジェスチャーをすると署名を生成して送ってくれる
    • 名前をつけて登録する
      • キーをなくしてしまったら消せるように
    • SMS Codeも強いけどセキュリティキーの方が強固
  • 署名をサーバに送って登録されているものと同一であることを確認する
    • このサーバをFIDOサーバと呼ぶ

Authenticator

Roaming Authenticator

  • Authenticatorの1つにセキュリティキーがある
    • U2FかFIDO2に対応しているAuthenticatorであれば間違いない
  • R持ち運びできるからoaming Authenticatorと呼ばれる

Platform Authenticator

  • バイスに埋まってるから専用のものを買わせる必要がない
  • 指紋認証などで使うことも多いけど端末のロックNoなども同等の扱い
  • Local User Verification(LUV)
    • ローカルで生体と所持の二要素認証する
    • スマホで生体認証とかするとこれが実現できる
    • 生体情報はデバイスにしかないから安心(だからLocal User Verification)
      • つまり新しいデバイスに替えたら再登録が必要

再認証(Re-authentication)

  • お金を払う手前とかで再度認証させるやつとか
    • ログインしてる状態でもう一度認証を求めるやつ
  • Pixel4の顔認証はまだ使えないけどChrome79から使える

参考

  • https:/goo.gle/FIDO
  • WebAuthnのコードラボもある

覚醒するアクセシビリティ

アクセシビリティ

  • 蔑ろにされることが多い
    • 不便と思う人を低く見積もりすぎ
    • 誰でも使えるようになることのよさを知らない
  • 障害者/健常者という区別がよくない
    • 環境や状況によって不便に感じることは誰でも起こりうる

Webにおけるアクセシビリティ

  • Webは世界中どこからでもアクセスできる
    • ブラウザの拡張などでカスタマイズできる

広義のアクセシビリティ

Wrap-up: High Performance JavaScript

  • Sho Miyamotoさん

intro

Layers

  • JavaScriptのレイヤー
    • Product
    • Runtime
      • Node
      • ブラウザ
      • Electron
    • Engine
  • JavaScriptの実装
    • サーバサイド
    • クライアントサイド

RuntimeとEngine

  • RuntimeとEngineどう違うか
    • Engine
      • parser/compile/execute
      • JIT/VM
    • Runtime
      • Engineが埋め込まれている
      • プラットフォームそれぞれのGlobalObjectを持っている
      • EventLoopをオーバーライドしてる

Optimization

  • 最適化
    • Product-level
      • memo化
      • キャッシュ
    • Runtime-level
      • 非同期
    • Engine-level
      • インラインキャッシュ
  • 効果
    • Product > Runtime > Engine
  • Micro Optimizationをするな
    • 自分でやらなくてもエンジンがやってくれる

Optimization

Server Side runtime

  • Node.js
  • イベントループ
    • 処理に時間のかかる動機処理があるとループをとめてしまう
    • 非同期でできるものはそうした方がよい
  • StreamAPI
    • Fileの読み出しとかを効率的に行える
    • Streamでないと情報を全てメモリにおいてそれを扱ってとなってしまって効率悪い

Client Side Runtime

  • ブラウザでJSが動くまで
    • fetch -> load -> parse -> compile -> execute
  • できるだけCodeCachingを使う
    • 次使う時にcompile済みになってるようにする
    • 頻繁に使われるものはServiceWorkerでcacheするといい
  • ESModules
    • ブラウザ上でimport/export
    • Preloading scripts
      • 実行はしないけどparseとcompileをしておいてくれる
  • idling
    • Idle Until Urgent
    • requestIdleCallbackを使うとCPUとかが暇な時に実行してくれる

Engine

  • V8
    • たくさん使われた処理ははやくとれるようにとか最適化してくれる
  • Inline Cache
    • Objectにどんな情報があるかを予め用意しておく?
    • ヒットしたらはやい

How to Boost Your Code with WebAssembly

  • FUJI Goroさん

WebAssemblyとは

  • ブラウザに搭載するバイトコードとその処理系仕様
  • JVMに近いけどランタイムはない

WebAssembly前夜

  • EmscriptenによってC/C++をJSにコンパイルすることができていた(2012)
    • ただし動作が非常に遅い
  • WebAssemblyに仕様議論開始(2015)
  • ブラウザにMVPレベルのサポート完了(2017)

WebAssemblyの価値

  • ブラウザにおいてはJSとできることは同じ
  • JSよりも速い
    • それが圧倒的価値
    • JSだと遅くて現実的でないことが可能になる
  • Cよりは数倍遅い
    • 安全性のために未定義動作(UB)をなくしてるから
    • この安全性が大きな利点

WebAssemblyのサポート状況

  • IE11以外は使える
    • 9割くらいのシェアのブラウザで使える

WebAssemblyの事例

  • eBayの事例
    • バーコードスキャナ

tech.ebayinc.com

言語ごとの速度イメージ

  • 1倍: C, C++, Rust
  • 3倍: Java, C#, Go, Swift
  • 5倍: JS(V8), Dart
  • 50倍: Ruby, Python, Perl, PHP
  • WebAssembly
    • WasmをV8で動かすと5倍の中では速い方

Streams APIをちゃんと理解する

  • 加藤 健志さん

StreamAPI

  • Readable Stream
  • Transform Stream
  • Writable Stream

Readable Stream

  • 読み込み可能なストリーム
  • データを分割して少しずつ読み込むことができる
  • fetchAPIのレスポンスのbodyは実はReadableStream

Writable Stream

  • 書込み可能なストリーム
  • pipeTo()を使うとReadableStreemのデータをそのままWritableStremに書き込める
  • 書き込み時にPromiseを返すと解決するまで待つので順序を保証できる
  • 分割されたデータを1つずつ順番に書き込むことができる

Transform Stream

  • 変換ストリーム
  • WritableStreamに書き込まれたデータをTransformStreamで変換してReadableStreamで読み込む
  • ReadableStreamからpipeThrough()でTransfirmStreamに渡してpipeTo()でWritableStreamに書き込める

バックプレッシャー

  • キューに空きがなくなったら通知して止めてもらう
  • Underlying Source
    • Push Source
      • 自発的にenqueueする
    • Pull Source
      • リクエストに応じてenqueueする
  • QueuingStrategy
    • highWaterMark
      • キャパシティを設定する
    • size(chunk)
      • 何をもってキューのサイズを決めるか

Streamsの今後

  • 5Gが来る
    • これまでボトルネックとされていたことが改善される
    • 大容量のファイルを配信できるようになる github.com

      - クライアントがボトルネックになる
          - Streamが役立つ!
      

Live Demo

「Mercari x Merpay Frontend Tech Talk vol.3」に参加してきました

  • Mercari x Merpay Frontend Tech Talk vol.3に参加してきました。

mercari.connpass.com

タイトル 発表者
Creating Serverless CMS from Scratch @sottar_
Vue.jsでのCSS設計 @tacamy
The Challenge of Web re-architecture using GraphQL and Apollo @lightnet328
Practical tips for making a global EC site @yayoc_

Creating Serverless CMS from Scratch

  • @sottar_さん

キャンペーンのページを作るまで

  • 従来のフロー
    • PMからどんなターゲットでどんあんことをしたいか伝えられる
    • デザイナーがコードを書く
    • フロントエンドエンジニアがレビューする
    • PMに返して問題なければリリース
  • 課題
    • デザイナーがコード角の大変(pug/css)
    • フロントエンドエンジニアがレビューするの大変
    • 一文字とか一部分変えるだけでもGitHubでフロー回さないといけない
  • キャンペーンページ作るのに時間かかる
    • 一ヶ月に1,2本くらいしか作れない

CMSを作った

  • コンポーネントを作ってCMS上で組み合わせるようなものがほしい
  • 必要なページ
    • キャンペーンの一覧ページ(過去に作ったものとか)
    • 編集ページ
  • なんでOSSを使わなかったか
  • 考えないといけないこと
    • 権限周り
    • セキュリティ
    • 履歴管理
    • プレビュー
    • => いろいろあるけどまずはMVPを作ってさわってもらう

アーキテクチャ

  • S3にCMSページの静的ファイルを配置
  • Cloud Storageにキャンペーンページを置いておいてそれをdynamic importして表示
  • GCPAWS混ざってる
    • 基本はGCPを使ってる
    • 社内版GitHubPages的なものをS3で作ってる
  • 認証はAuth0

Vue.jsでのCSS設計

  • @tacamyさん

コンポーネント

  • 機能が自己完結する
  • 再利用できる
  • Vueではscopedをつけると擬似的にスコープをもたせることができる
    • ShadowDOMとは違う

Scoped CSSの留意点

コンポーネント命名規則

ディレクトリ構成

  • assetsの中にscssに変数とかmixin
    • 実態はcomponentsの中
  • 階層が深くなりすぎないようにした方がよさそう
  • 細かすぎる分割はパフォーマンスにも影響
  • 最初はシンプルに作って規模に応じて変更していくと良さそう

The Challenge of Web re-architecture using GraphQL and Apollo

  • @lightnet328さん

メルカリWebにリアーキテクチャ

  • 新しい技術で作り直してる
    • TS
    • Next
    • React
    • Apollo
    • GraphQL
  • ページごとに部分的に公開している

GraphQLとApollo

  • なぜGraphQL
    • スキーマはドキュメントより実装と乖離するリスクが小さい
    • クエリの可読性高い
  • なぜApollo Clients
    • リモートデータの取得管理を任せたい
    • キャッシュによってリクエストが減る
  • なぜApollo Server
    • BFFとしての役割
      • スキーマをフロントエンドのために整理
      • ロギング
      • 認証
      • 将来的にgRPCでマイクロサービスに接続
      • クライアントが1つのエンドポイントだけ知ってればよい

Practical tips for making a global EC site

  • @yayoc_さん

UNIQLO Global EC

  • 特徴
    • 22カ国
    • O2Oもサポート
    • 機能が国によって異なる
  • これまで
    • 国ごとに異なるアプリ
    • クライアントヘビー
  • これらを解決させるプロジェクト
    • 1つのコードで複数の国対応
    • パフォーマンスはやく
    • a11y
    • コンシューマだけでなく管理画面のUXも改善
  • ページによってSSR
  • 国別にリダイレクトリライト

グローバルサイト構築

URL構造

  • /:country/:language
  • countryなかったらCDNの国
  • languageなかったらAccespt-Languageの言語

SEO

  • GoogleBot以外も考慮
  • JSレンダリングしてくれなかったのでHTML返した方が無難(SSR)

CMS

パフォーマンス

  • 毎日WebPAgeTest/Lighthouseを国別で実行
  • Performance Budget
    • total 200kb
    • chunk 80kb
  • webpack-bundle-analyzer
    • バンドルファイル内の内訳を可視化

ローカライゼーション

  • i18n- webpack-plugin
  • エントリーポイントを分けている
  • ルーティングベースでコードスプリッティングしてるから余計なのは入らない
  • 一部プレースホルダーで出し分け
    • 単数系/複数形とか
  • 決済フローなんかは国によって異なったりするのでコンポーネント出し分けてる
  • minificationで不要なものは削除される

a11y

  • ビジネスサイドからの要件も強い
  • Lighthouseでスコアとるだけでなくそれ以外の項目もチェック
    • 画像説明
    • CSSなしで動くか

画像

  • 一般的に画像が大きいほどコンバージョンは高い
  • CDNでWebPに変換してサイズ圧縮
  • プレースホルダーおいてリフロー防ぐ
  • 遅延ロード

BFF

  • マイクロサービスへのAPIリクエストを束ねる
    • クライアントヘビーな実装軽減
    • クライアントが扱いやすいような構造に整形
  • キャッシュ
    • max-ageを見て設定
  • ロギング
  • HMAC認証をサポート

「PWA Night vol.10 ~PWA × 技術~」に参加してきました

  • PWA Night vol.10 ~PWA × 技術~に参加してきました。

pwanight.connpass.com

タイトル 発表者
とある個人開発PWAのSEO奮戦記 大岡由佳さん
PWA×クラウドゲーミング おりばーさん
コードサイズの大きなプログラムのロード時間:WebAssemblyの場合 @chikoskiさん
うわさのJAMStackでPWAをさわってみた のまどまんさん
Monaca × PWA × 3D VMT-Yamashitaさん

とある個人開発PWAのSEO奮戦記

  • 大岡由佳さん(@oukayuka)

Mangarel

  • 個人でPWAなアプリを作った
  • Googleで検索しても3件しかひっかからない
    • 1万ページ以上存在してるのに
    • 最近のクローラーはJS解釈してくれるんじゃなかったのか・・
  • Problem
    • ページがインデックスされない
    • タイトルや詳細が個別に表示されない
    • コンテンツがレンダリングされない

ページがインデックスされない

  • サイトマップを作って送った
  • 正常に処理されましたと返ってきたけど
    • 認識はされるけどExclusionに入ってる
    • 内部リンクされてないのが原因?
  • ページを増やして内部リンクを増やした
    • 少しずつインデックスされるページが増えてきた!

タイトルや詳細が個別に表示されない

  • React HelmetでHTMLヘッダを上書き
    • ブラウザからは書き換わってるけどGoogle上では変わってない
  • CloudFunctionsで動的にヘッダを書き換えた
    • ボットからのアクセスの時だけ発動するように

コンテンツがレンダリングされない

  • SearchConsoleで試してみたらFirestoreからデータをとってくるはずがとってこれてない
    • ページによっては運がよければ表示される
    • レンダリングに時間がかかると諦めてるっぽい
  • Lighthouseで計測したらパフォーマンス50点台
  • TreeShakingした
    • ビルド時に不要なコードを削除
  • CodeSplitting
    • 初回のレンダリング時には必要なJSだけロードしそれ以外は遅延ロード
  • Lighthouse60点台
  • 無限スクロール

PWA×クラウドゲーミング

  • おりばーさん@Black Inc.(@oliver_diary)

クラウドゲーミング

OOParts

  • 開発してるクラウドゲーミング
  • ゲームをWebブラウザでアクセスするときの残念なところ
    • アドレスバーが邪魔
    • 余白がもったいない
    • アクセスするまでの導線が長い
    • => PWA化で解決!
  • 他にも
    • 起動時の初期表示が速い
    • アプリと違って審査いらない
  • PWAとクラウドゲーミングの相性抜群

コードサイズの大きなプログラムのロード時間:WebAssemblyの場合

  • @chikoskiさん

WebAssembly

WebAssemblyのいいところ

  • JSあるのになぜWebAssembly?
    • エコシステム
      • 他の言語の資産を使える
    • パフォーマンス
      • 速いけどそれだけじゃなくてブレが少なくて安定感が高い
  • 音声ファイルの扱い
    • ファイルサイズでかいので圧縮してmp3にして扱いたいとか
    • でもJSだけではできないのでWebAssemblyが役立つ

WebAssemblyの注意点

  • コンパイルするとjsとwasmが出力される
    • ファイルサイズがでかい
    • キャッシュを活用する
    • ネイティブのコードはブラウザにキャッシュされる
  • キャッシュにのったコードをいかに使い続けるか
    • 不必要なコードの変更をしない
      • ドメインとファイルを対応づけて保存されている
      • コンテンツが変わったら破棄されてしまう
    • URLを変更しない
      • クエリも変わらないように
    • ステータスコードを正しく返す
      • 200が返ると新しいコンテンツが来たと認識する
      • 変わってなければ304を返す
    • wasmのファイルを小さくしすぎない
      • 小さすぎるとキャッシュが破棄される(150kb以下くらい)
    • 最適化オプションをつける
    • システムライブラリをシェアする
    • application/wasmをつける
      • 全部のデータをダウンロードする前にある程度溜まったらコンパイルするという動きをしてくれる

うわさのJAMStackでPWAをさわってみた

  • のまどまんさん

JAMStack

  • 動的なデータコンテンツを取り扱う静的サイト
  • 事前に静的ページを生成しておく

JAMStack作ってみた

PWA化してみた

  • GatsbyにPWAのプラグインがある
  • キャッシュ使ったらパフォーマンス上がった
    • コンテンツがユーザ単位などで頻繁に変わる場合はキャッシュが活かしきれないかも

Monaca × PWA × 3D

  • VMT-Yamashitaさん

Monaca

  • ハイブリット開発環境
  • PWAのテンプレートがある

「LINE DEVELOPER DAY 2019 Day1」に参加してきました

  • LINE DEVELOPER DAY 2019に参加してきました。

linedevday.linecorp.com

  • セッションの資料はこちらに随時公開されるとのこと

speakerdeck.com

  • 今回はDay1の午後だけ参加してきました
  • 以下セッションのメモです

Inside of Blog; 15年熟成されたサービスの光と影、カオスとレガシーへの挑戦

  • 大森 貴博さん

livedoor Blog

  • 構成
    • LAMP
    • 30近くのサブシステム
  • 15年での蓄積
    • Developper
      • 70+
    • サーバ
      • 750+
      • 200がDB
    • DBテーブル数
      • 550+
    • ファイル数
      • 43500+
    • プログラムファイル数
    • コードの行数
      • 410000+
  • 今動いているブロジェクト

カオスとレガシー

ドキュメントがない

  • セットアップ方法がわからない
  • デプロイ方法がわからない
  • 普段触ってないサブシステムだと特に

開発サーバがない

  • 誰からも忘れられていて安定して動いたサブシステム
    • それに手を入れようとしたら環境がない
  • 開発サーバはあるか?
  • 正常に動いているか?
  • 本番との差分がないか?
  • 本番のデータを使っていないか?

テストがない

DNSレコードが多すぎる

  • 300レコード以上
    • ユーザが設定してる独自ドメインとかは入ってない
    • 調査したら230が不要だった
    • 古い機能とか過去のキャンペーンでの残骸
    • 整理して削除するだけで数ヶ月

機能が多すぎる

  • 目に見えるもの見えないものたくさん削除してる

Perl

  • Perlのバージョンがとても古い
    • 5.6(2002年)
    • ローンチしてから変えてない
  • 新しいバージョンのPerlも一部使ってる
    • バージョンが混在している
    • 環境など全て2倍必要

MySQL

  • MySQLのバージョンが古すぎる
    • 4.0(2003年)
    • ローンチしてから変えてない
  • 4.0でできないこと
    • Online DDL
    • Fast Index Creation
    • Trigger
    • => オンラインでalter tableできない
      • テーブルコピーしてデータ移行して、、と無理やり頑張った(数ヶ月かかる)
      • データが2倍だからディスク容量が逼迫
  • バージョンを上げないのか?
    • サーバマイグレーションのタイミングで考えた
    • ブログの特殊な事情と時間的制約で断念
      • 1つのテーブルに複数文字コードが混ざってる
      • そのせいで正攻法でのバージョンアップができない

LINE BLOG

  • LINEとの連携が強い
  • 2014年リリース
  • 2016年リニューアル
    • 一般公開
    • 独立したサービスに
      • livedoor Blogをフォークした
      • livedoor Blogのカオスとレガシーも引き継いだ
      • => LINEのエンジニアが本気出して数々の問題を解決

Next 15 Yeras

  • 15年後を考えて開発していくことが大切
  • 小さなことからでも始めること
    • コメント一行書くだけでも
    • 不要なファイルを削除しておくだけでも

LINE NEWSの記事配信を支える技術

  • 稲葉 大樹さん

LINE News

  • 2013年開始
  • 2017年からLINEのタブに加わった
  • ニュース以外に運行情報や地震速報なども
  • 月間680万ユーザ
  • インフラ
    • Amon2(Perl) 44台
    • Spring Boot(Java) 30台
  • DB

Personalized Recommendation

  • 多大な記事数ユーザ数をもとに記事をレコメンドしている
  • ML + Manual(運営の手動)
  • 表示対象かつ表示期間中のものがユーザに表示される

MLによるレコメンド

  • 社内のMLチームで生成されたものをもとにレコメンド
    • 1億人超えのデータが入っている
    • ユーザ一人に付き200件の記事を選んでる

手動によるレコメンド

  • 運営チームがCMS上で設定
  • 属性に応じてどの記事を表示するか選ぶ
    • どの媒体をフォローしてるかとかも属性として選べる

MLのレコメンドだけを使っていた時代

  • CDNを活用して記事を取得していた

    • レコメンドを取り入れると属性が必要なのでCDN活用できなくなった
  • ユーザからの記事取得リクエストの流れ

    • Redisにレコメンドした記事を事前に入れておく
    • ユーザから記事取得のリクエストが来るとRedisから取得する
    • 取得した記事をキャッシュに保存しておく
    • 次からはキャッシュにあればそこから、なければMySQLから取得する

ML + Manualでレコメンドしていた時代

  • Central Dogma
    • jsonとかyamlの設定ファイルを管理する
    • 変更をwatchすることができる
  • Datalakeから対象ユーザのIDを取得してCMSにアップロード
  • 記事IDとユーザのマッピングをRedisにあげる
  • Central Dogmaに記事の情報をあげる
  • 課題
    • 記事とユーザのマッピングデータの形式の影響でスケーラビリティがない
    • パフォーマンス

今後

  • 今はユーザからのレスポンスが反映されるまで1時間かかったる
    • リアルタイムに反映させたい
    • 今ABテストで一部のユーザに適用
  • レコメンド適用範囲の拡大
    • ダイジェストは今全員同じものを出してる

コミュニケーションアプリ「LINE」の機能改善を支えるデータサイエンス

  • 高口 太朗さん

LINE App Improvement Project

  • Uesrs First
  • Data Driven
  • Diverse Team
  • In-houes Developmemt

データサイエンスチーム

  • Data Science And Engineering Center
    • Data Labs
      • Data Science Team
  • Data Science Team
    • LIENマンガ
    • LINEトップ
    • LINE Pay
    • LINE ad

プロジェクトのサイクル

  • ユーザリサーチ -> 計画 -> 開発 -> テスト -> フィードバック -> 計画 -> ...

ユーザリサーチ

  • Focused Interview
  • Online Suvey
  • Dashboard Monitoring
  • 定量と定性を組み合わせる

計画/開発

  • 計画
    • どうデータではかれば良いか考える
  • 開発
    • どのようなログを集めればよいか定義など

テスト/フィードバック

  • テスト
    • オンラインでのABテスト
    • 2018~で20回以上者ABテストをやってきてる

LINEアプリ改善の取り組み

  • LINEアプリならでは
    • ユーザが多い
    • 使い方もさまざま
  • LINEアプリを評価する単独のKPIが存在しない
    • メッセンジャーは無料の機能
    • すでに多くのユーザを獲得してるからユーザ数xx増加とかもやりづらい
  • LINEのコアバリュー
    • LINEのミッション
      • Closing the Distance
    • メッセンジャーアプリにあてはめると
      • 身近な友達と簡単にやりとりできること
    • そのために改善すべき機能を考える
  • 友達ネットワークを分析
    • 社会的なネットワークが反映されている
    • グループ機能の改善がターゲットに

グループ機能の改善

  • ユーザリサーチ
    • グループ作成の手順がわかりづらい
    • 当初
      • グループ名やアイコン決めてからメンバー選択
      • 急にグループ名聞かれても困るのでは
  • 計画
    • グループ名選択よりも前にメンバー選択を持ってくる
  • ABテスト
    • 入れ替えてもグループ作成成功率は変わらなかった
  • フィードバック
    • どこに目をつけるか
      • 成功したユーザに着目?
      • 失敗したユーザに着目?
      • 時間帯に着目?
      • 地域に着目?
    • グループ名アイコンを選ぶ画面まで進んでない人が多い
      • スムーズにメンバーを選べていない
      • テスト期間中に複数回失敗したユーザ30%程度
  • 計画
    • 最近トークした友達を上に持ってくる
    • グループ名アイコンとメンバー選択を一画面で
  • ABテスト
    • 2種類×2の4通りテスト
      • 比較のパターンが多いので偶然の差異を拾ってしまう可能性がある
      • 組み合わせの一つを諦めて3パターンを検証
  • フィードバック
    • 大きな差はでなかった
    • グループ作成までにかかる時間が短くなってれば成功なのでは?
      • 最近トークした友達を上に持ってくると短縮されていた
    • 1画面にした結果はネガティブ
      • メンバー1人でグループ作成が増えた
      • メンバー2人以上だけをみると作成成功率低下
    • 2画面のままで最近トークした友達を上に持っていくのを採用

データサイエンスツール

  • 分析の環境とツールによってこれらの改善は支えられている
  • ABテストするためには
    • 必要なサンプルサイズの選定
    • テストユーザ選定
      • LIBRA
    • モニタリングダッシュボード
      • LIBRA REPORT
        • GitHubを通じて集計に必要なクエリを登録
        • ブラウザベースのダッシュボードに出力してくれる
      • R Shiny
        • より高頻度でチェックしたい
    • テスト結果のレポート

XXE、SSRF、安全でないデシリアライゼーション入門

  • 徳丸浩さん

XXE

  • XML外部実体参照
  • 外部実体参照
    • XMLはentityを定義して参照することができる
  • 攻撃の例
    • SYSTEM /etc/hostsとか指定すると内容がとれてしまう
    • URLを指定するとその内容が読み込まれてXMLに展開される
      • SSRF(Server Side Request Forgery)
  • 原因
    • XMLのもともと保つ機能
  • 対策
    • XMLを使わずJSONを使う
    • XMLを使わなければいけない場合はどうする?
      • Javaの場合DTD(Document Type Definition)を禁止する
      • PHPだと外部実体参照を停止する設定になっている
      • RailsではREXMLを使う
        • nokogiriだとNOENTオプションを設定しない

SSRF

  • Server Side Request Forgery
  • 攻撃イメージ
    • 直接アクセス不可の内部サーバがある
    • 公開サーバを通して内部サーバにアクセスを許可している
    • 公開サーバを踏み台にして内部サーバにアクセスすること
  • 攻撃の例
    • プレビュー機能でのSSRF攻撃
    • http://169.254.169.254にアクセスするとEC2のインスタンス情報をとれる
    • このURLをプレビューするとSecretAccessKeyなどとれてしまう
    • EC2インスタンスを踏み台にしてクレデンシャルな情報にアクセスできてしまう
  • 原因
  • 事例
    • Capital Oneの例はSSRFだった
    • WAFの設定ミスによるもの
    • HostヘッダにEC2インスタンスを指定することによる攻撃
    • WAFの権限がS3へのアクセスなど広く与えられすぎていた
  • 対策
    • ホスト名がIPアドレスであることをチェックするだけではダメ
      • リダイレクトされてしまうなどさまざまなケースが有る
    • ネットワーク的にチェックする
      • 許可されたURLかどうかチェックする

安全でないデシリアライゼーション

  • シリアライズ
    • バイト列に変換してオブジェクトに格納できるようにする
  • 外部から来たシリアライズデータをデシリアライズするとどんなオブジェクトでも作れてしまう
    • メソッドをいじったりとかはできない
      • プロパティを工夫するといろいろできてしまう
  • 対策
    • シリアライズ形式でなくJSONを使う
    • クッキーやhiddenパラメータではなくセッション変数を使う

LINEのメッセージングプラットフォームにおけるマイクロサービス化への長い道のり

  • 井出 真広さん

LINE Messaging Platform

  • 2011年ローンチ当初はモノリシックだった
    • talk-server/redis/msql
    • 1つのチーム/1つのサーバでうまくいっていた
    • どんな機能を追加していくか同じ方向を向いてできていた
  • 追加したい機能がたくさん増えてきてチーム全体で調整する必要がでてきた
    • 速度を持って進められなくなってきた
    • チームを分割してサービスを分けるようにしていった
    • チーム単位でそれぞれコントロールできるようになった
    • スタンプ/メッセージング/認証/...
  • 現在は多くのサービスが連携し合いながら動いている
    • チームごとにやりたいことにフォーカスしながら開発している
  • マイクロサービス化して
    • よかったこと
      • コンフリクトが少なくなった
    • よくなかったこと
      • ネットワークレイテンシ
      • 障害

マイクロサービスを構築するためのツール

  • Coneectivity
  • Directory Service
  • Routing

Coneectivity

  • Armeria
  • 非同期なRPC/RESTライブラリ
  • Java/Netty/HTTP2
  • ロギングや分散トレーシングの仕組み
  • 障害を伝播させないためのサーキットブレーカーの仕組み

Directory Service

  • Central Dogma
  • サービス間で設定を共有したい
  • 通信先のサービスがどこにあるのか把握したい
  • どのホストが度のサービスを配信しているか
  • gitをバックエンドとしたバージョン管理の仕組み
    • どの時点でどの設定だったか管理

Routing

事例

  • スタンプが普及してきた
  • 1ユーザで万単位で持っている人もでてきた
  • スタンプを購入するたびにRedisにスタンプの所有情報を再構築していた
    • その時にスロークエリが発生して一瞬talk-serverが止まる
    • talk-serverにはいろんな場所からリクエストがくる
    • メッセージングプラットフォーム全体の障害となりかねない
  • どこかが一瞬とまるようなことがあっても波及しない構成に再構築
    • サーキットブレーカーなどの仕組みをいれる
    • レイテンシを悪化させないように
    • スケール

「Android Dev Summit 2019 Extended Tokyo #gdgtokyo」に参加してきました

  • Android Dev Summit 2019 Extended Tokyo #gdgtokyoに参加してきました。

gdg-tokyo.connpass.com

  • 普段Anrdoidの開発をしているわけではありませんが、新しい機能を知ることができて便利な機能がたくさん登場してきていることを実感できました。
タイトル 発表者
【Session1】Conference Overview & Keynote Session mhidaka
【Session2】Android Studio 4.0 最新アップデート Daichi Furiya / Wasabeef
【Session3】かんたんべんりなMotionEditorの使い方講座 mochico
【Session4】What's new in CameraX Takasy
【Session5】Jetpack Composeの解説です! Yuki Anzai
【Session6】Jetpack Roomの最新情報が届きます! Yuichi Araki

【Session1】Conference Overview & Keynote Session

  • mhidakaさん

概要

  • 10/23-24
  • 700人
  • 60セッション

キーワード

  • Modern Development
    • 素早く簡単に
  • Modern distribution channel
    • PlayStoreの強化
  • Modern OS
    • OSのリリース戦略

Keynote

  • Androidはユーザと開発者をつなぐプラットフォーム

Modern Development

  • Innovation
    • 利用シーンの拡大
  • Updatability
    • 柔軟な機能アップデート
    • Android10からAPKだけでなくAPEXに対応
    • APKだとなかなかアップデートしてくれない
    • APEXだと動的に自動でアップデート(ユーザの同意が必要)
  • Secirity & Privacy
    • Popup Block
  • Developer Experience
    • PlayStoreのTop1000のうち60%がKotlin
    • 開発者の53%がKotlinを使用(母数は何?)

Modern OS

  • Android11からα,βといった提供になる
    • 今まではstable1,2,finalみたいな感じだった
  • targetSDKは1つ前までしか認めなくなる
    • どんどん上げていかないといけなくなる

【Session2】Android Studio 4.0 最新アップデート

  • Daichi Furiyaさん

Desugaring in D8 & R8

  • 新たにいろいろなパッケージ、クラスがサポートされた

Multi Preview

  • さまざまな解像度のデバイスでプレビューできる
  • 各国の言語設定でもプレビューできる

Build Speed

  • ビルドのどこにどれくらい時間かかってるか可視化できるようになった

Google Maps Emulator Integration

  • Google Mapsのナビゲーションをシミュレートできるようになたt

Proguard Editing

  • コード補完の精度向上
    • クラス名とかきかなかったけど補完されるようになった

Live Layout Inspector

  • エミュレータで動作しているものを3Dで要素の階層とか見られる
    • 要素をクリックするとプロパティが表示されたり
  • Experimentalなので設定をonにしないと使えない

Emulator embedded inside the IDE

【Session3】かんたんべんりなMotionEditorの使い方講座

  • mochicoさん

Motion Editor

  • Motion Layoutを使ってアニメーション
  • Motion Layout
    • ConstraintLaayoutのサブクラス
    • motionをXMLで定義できる

Modern Editorの使い方

  • 要件
    • Android Studio4.0+
    • ConstraintLaayout2.0.0beta3+
  • エディター上でアニメーションのstartとendを設定できる
    • 動かすとアニメーションしてくれる
  • keyframesでもっといろいろ設定できる

【Session4】What's new in CameraX

  • Takasyさん

Camera2 API

  • 高度な機能の実装ができる
  • でも細かなことができるせいで使いづらい
  • 様々なデバイスで動くものを作るのが大変

CameraX 3

  • Camera2をラップしたもの
  • 新機能を追加するときデバイス固有のものを使わないようにしてる
  • 2億台のactiveなデバイスでテストしてるから様々な機種で動く

CameraXのユースケース

  • プレビュー
  • 画像解析
  • 画像キャプチャ
  • CameraViewが簡単に使えて便利

新しいAPI

  • Tap to focus
  • Pinch to zoom
  • Zoom Slider

【Session5】Jetpack Composeの解説です!

Jetpack Compose

  • AndroidのUIを作るためのモダンなツールキット
  • 既存のコードと混ぜて使える(予定)

Jetpack Composeはやりたいこと

  • シンプルにしたい
    • UIを作るのにたくさんコード書かないといけない場面がある
    • フレームワークからはさわれるけど3rdパーティからはさわれないとかいう場面がある
    • Material + AnimationなUIを作りたい
  • Single Source of Truethにしたい
    • CheckBoxの状態とModekの状態どっちが正しいの?ってなっている
  • ReactiveなUIにしたい
    • Modelで状態を管理し変更されたら再描画
  • UIパーツの再利用性高めたい
    • 従来はカスタムViewあるけど作るの大変
    • 小さなcomponentを組み合わせてUIを作っていく

Jetpack Composeの今後

  • まだ開発中
    • 本番で使うな危険
  • 来年betaが出る(来年のいつだかは不明)

【Session6】Jetpack Roomの最新情報が届きます!

  • Yuichi Arakiさん

Jetpack Room

  • N対Nにも対応するようになった
  • デフォルト値設定できるようになった
  • Incremental Build
    • Buildがはやくなる
  • Expand Projection
    • select文の結果で一部のカラムしか必要ない時に対応できるようになった
    • 空気を呼んで全カラム返さなくなる

「LINE API × Tech API Vol. 1 Powered by AWS」に参加してきました

  • LINE API × Tech API Vol. 1 Powered by AWSに参加してきました。

linedev.connpass.com

後半のハンズオンではLINE botを作成してバックエンドにAWSを使いました。 コピペ部分も多かったですが、初めてCloud9を使ったりLINE botを作ったりいい経験になりました。

タイトル 発表者
What and Why AWS Serverless Satoshi Suzuki
サーバーレスだからこそフロント実装もカジュアルに!LINE APIでAWS上でアプリを作ろう! 比企 宏之
LINE APIとAWSを使ったハンズオン Satoshi Suzuki

What and Why AWS Serverless

  • Satoshi Suzukiさん(AWS)

トレンドのワード

  • microservices/serverless
  • それぞれ2014年くらいから伸びている

サーバーレスとは

現場のニーズ

  • Business Personの気持ち
    • 早くリリースしたい
    • 新機能ほしい
    • スタートアップ時にインフラコスト抑えたい
  • Developerの気持ち
    • インフラ管理したくない
    • ビジネススケールしたときにサービススケールさせるの大変
  • ビジネスロジックに集中したい
    • => サーバーレス

サーバーレスの特徴

  • インフラのプロビジョニング管理が不要
    • マシンの事前調達不要
  • 自動でスケール
  • 価値に対する支払い
    • 実行した分だけ払う課金体系
  • 高可用かつ安全
    • メンテナンスや定期的なダウンタイムはない

AWSのサービス

  • 処理
    • Lambda
  • 外部I/F
  • 認証
    • Cognito
  • ストリーム
  • データ保持管理
    • DynamoDB
    • RDS
    • Aurora
    • SQS
    • S3

Amazon API Gateway

  • インターフェースの抽象化
  • HTTPのエンドポイントを作れる
  • リクエストを受け付けてどこにパスするか設定できる
  • 作成可能なAPIの種類
    • REST
    • WebSocket
  • メトリクスも確認できる

AWS Lambda

  • リソース管理
  • リトライ
  • ログ出力
    • Cloud Watch Logsに書き出してチェックできる
  • いろんなイベントをトリガーに実行できる
    • API呼び出し
    • データの変更
    • ファイルの配置
  • 処理対象
    • 自由に処理を書ける
    • DBアクセス
    • ファイル出力
  • 負荷に応じて柔軟にスケール

Amazon Simple Que Service

  • メッセージングキューをハンドリングするサービス
  • 標準キュー
    • 少なくとも1回は配信
  • FIFOキュー
    • 順序保証と1回限りの配信

Amazon Simple Storage Service

  • オブジェクトストレージ
  • 安価なストレージサービス

サーバーレスだからこそフロント実装もカジュアルに!LINE APIAWS上でアプリを作ろう!

  • 比企 宏之さん(LINE)

ITシステムの運用コスト

  • 運用と保守で75%

LINEのフレームワーク

  • LIFF(LINE Frontend Framework)
    • LINE内で動くWebアプリのプラットフォーム
    • HTML/JSで書ける
    • バックエンドAWSつないだりとかも自由にできる
    • LINEは8200万人のユーザがすでにインストールしてくれている

LINE Things

  • IoTアプリ

「FRONTEND CONFERENCE 2019」に参加してきました

  • FRONTEND CONFERENCE 2019に参加してきました。

2019.kfug.jp

タイムテーブル

11:00〜

タイトル 発表者
モダンJavaScript再入門 尾上 洋介
デザイン・設計の体幹とスキル 山下 一樹
PWAとCache API 田口 航

11:45〜

タイトル 発表者
ディレクトリ構成ベストプラクティス 〜 Angularアプリを作り続けてわかったこと okunokentaro
事例からみるアプリデザインの成長戦略とWeb Native Platform 榊原 昌彦
JavaScript も jQuery も未経験の新人エンジニアが 1 年間 Vue.js を学習して感じた話 川又由雅

13:00〜

タイトル 発表者
Adobe XDで作るマイクロインタラクション 松下 絵梨
UIデザイナが実装できる良さ コンチ
レガシーなフロントエンドをリプレイスする 小島大基

13:45〜

タイトル 発表者
2019年のUIパフォーマンス キリル ワシルツォフ
Nuxt.js + Firebaseでの開発と高速化に挑んだ話 カンボ@沖縄(鈴木孝之)

14:30〜

タイトル 発表者
AWSを活用したフロントエンド開発 前田 圭介
高齢者でも使えるプロダクトUIの挑戦 神保嘉秀

15:15〜

タイトル 発表者
私たちはなぜ SPA で開発するのか 花谷拓磨(@potato4d)
プロダクト開発とFigmaのより良い関係を求めて 大木尊紀
React Hooksで<video>を乗りこなす 浜田 真成

16:00〜

タイトル 発表者
フロントエンドエンジニアのためのセキュリティ対策 平野 昌士
Flutter For Webを用いて居酒屋で使えそうなゲームを作ってみた備忘録 大西 優司
Web 制作現場のディレクションを支える GitHub 後藤知宏

モダンJavaScript再入門

  • 尾上 洋介さん

なぜJS

  • 本格的なSPAが作れる
  • モダンなツールやフレームワークを学ぶのにJSの知識が必要なものが多い
  • ツールが移り変わっても通用する技術

基本的なオブジェクト

  • 数値/文字列/配列/オブジェクト

変数の宣言

  • const/let
    • 基本はconst
    • 再代入必要な時だけlet
    • varは使わない

アロー関数

  • 関数は第一級オブジェクト
    • 変数に入れたり関数へ渡したりできる

非同期処理

  • asyncをつけた関数内ではawaitが使える
  • awaitつけるとPromiseが解決されるまで待ってくれる

レガシーなフロントエンドをリプレイスする

  • 小島大基さん

レガシーとは

  • 古い
  • 代替すべき新しいシステムがある
  • フロントエンドにおいて
    • 新しい技術がすぐに入ってくる

アーキテクチャ

  • UIとロジックのディレクトリ(ファイル)を分ける
    • UIライブラリが変わっても使い回せる状態に
  • コンポーネントはなるべくステートレスに

テスト

苦労したところ

  • ライブラリのバージョン上げたらテストが通らなくなった
    • BootstrapVue 1.5 -> 2
  • class style apiが非推奨になってしまった

Nuxt.js + Firebaseでの開発と高速化に挑んだ話

  • カンボ@沖縄(鈴木孝之)さん

なぜFirebase

  • RDSも使ってる
    • FirebaseはChatの部分だけ
  • 使っているサービス
    • Firebase Authentication
    • Cloud Firestore
    • CloudFunction

チャット機能をFirebaseで

  • 候補
    • WebSocket
    • ロングポーリング
    • Firebase
      • Firebaseに決定
      • 導入コスト低くてメンテコストも低い
      • 採用のウリになりそう
  • 導入前の懸念
    • DBの無料枠1GB
    • 検索条件に制限

Firebase導入してどうだったか

  • Firestoreの構成
    • usersコレクション
    • roomsコレクション
    • usersのサブコレクションにrooms
      • 深い層への検索がやりづらそうだったから
  • CloudFunctionの初期起動遅い
    • 一定時間アクセスがないとスリープモードになる

ビルド高速化

  • Webpack Bundle Analyzer
    • webpackの処理で遅いloaderやpluginが分かる
    • bundleしたファイルがどのライブラリがどれくらい占めてるか分かる
  • バンドルサイズ
    • Chart.jsが重い
    • memoment.jsが重い
      • 不要なlocaleも入ってて重い
    • lodashが重い
      • ほとんど使ってないから消そうとした
      • 関数単位でimportするやり方があったからそれにした

AWSを活用したフロントエンド開発

  • 前田 圭介さん

AWS

  • 使ってるサービス
    • S3
      • ストレージ
    • Cognito
      • 認証サービス
  • 今後よさそう
    • AppSync
      • GraphQLでやりとりする
      • リアルタイムデータアクセス
      • オフラインのデータ同期

導入編

  • AWS Amplify
  • amplify initで雛形生成できる
    • Auth.signin()でCognito Signin
    • GraphQLのqueryを生成したりもできる
  • amplify pushでデプロイできる

まとめ

  • Amplifyで簡単に認証からAPI作成・実行Storage利用ができる

私たちはなぜ SPA で開発するのか

  • 花谷拓磨(@potato4d)さん

なぜSPAを選定するのか

  • User Experiences(UX)
    • 要件を満たすための選ぶ場面
  • Developer Experiences(DX)
    • 開発効率を上げて生産性を上げる
    • エンジニアを確保するために新しい技術を使う

UX要件の強い事例

  • InstagramがPWA/SPAで提供している
    • 新興国での利用など考慮してWebで提供
    • twitterも同じようなことしてる
  • ページ遷移にアニメーションをつけたりリッチにしたいけど各ページでURLは持ちたい

DX要件の強い事例

  • コーポレートサイトをSPAで作成
    • コンテンツのアップデートを簡単にやりたいからSPAを選択

SPAの技術をどこまで使うか

  • SPAに付随してくる技術はすべて必要?
    • たとえばReduxとか
  • 要件ごとに検討していく必要がある
    • 常にバランスが大事

間違った技術選定

フロントエンドエンジニアのためのセキュリティ対策

  • 平野 昌士さん

Webのセキュリティ動向

  • IPAが出している脆弱性届出受付数
    • Webがソフトウェアの倍以上
    • XSSが半分を占めている
  • 脆弱性の多くはWebサイトでXSSが多い

脆弱性(XSS)の仕組みと対策

XSS

被害例
XSSの種類
主な対策
  • 特殊文字エスケープ
    • & -> &amp;とか
  • 危険な文字列の削除
    • javascript:alert()とか入ってたら消すとか
    • 自前でやれなくもないけど大変
      • OSSなどを活用しましょう
      • 例えばReactはデフォルトでいろいろやってくれる
      • DOMPurify
  • ブラウザの機能を使う
    • Content Security Policy
      • HTTPレスポンスヘッダーに入れる
      • <meta>でも指定できる
    • Content-Security-Policy-Report-Only
      • レポートをとれるから本番適用前に確認すると良い
    • nonce
      • metaタグで設定したnonce値と同じ値が設定されたscriptタグしか実行できないようにする
      • nonceはリクエストの都度変える必要があり推測困難なランダムな値にする
    • Trusted Types
      • URLの文字列を安全な型に検証して扱う
      • まだexperimentalな機能
        • chromeはflag立てれば動く
        • Polyfillもある

セキュリティへの意識

  • 脆弱性とは悪用できるバグ by 徳丸先生
  • セキュリティに関しても
    • 要件定義でfixする
    • セキュリティテストする
  • どうやってチェックする?

「#webauthn_study」に参加してきました

  • webauthn_studyに参加してきました。

web-study.connpass.com

タイトル 発表者
WebAuthN を入れるには何を考えるべきか @ritou (mixi)
WebAuthN を実際に入れてみてどうだったか @kasecato (nulab)

WebAuthN を入れるには何を考えるべきか

  • @ritouさん(mixi)

リカバリーの話

  • 無効化/再設定
    • パスワード
    • TOTP
    • リカバリーコード
    • Auhtenticator
  • 別の認証方式or複数登録

パスワード認証におけるリカバリ

  • 忘れた
    • 別の認証方式 + 再設定

SMS通知におけるリカバリ

  • 番号/アドレスが変わった
    • 別の認証方式 + 無効化/再設定

FIDOにおけるリカバリ

  • 紛失盗難
    • 別の認証方式 or 複数登録可能にして無効化/再設定
  • FIDOだからといってそんなに問題ではない

導入事例

  • Google, GitHub
    • パスワード認証との組み合わせ
    • 2段階認証

2段階認証としての導入

導入時にどこに手を入れるか

  • アカウント設定
    • 追加認証を有効にする
    • リカバリー設定
      • 別の認証方式を登録
  • 認証
    • パスワード認証 + 追加認証を要求するように
    • 複数ある場合はどの方式か切り替えられるように
  • 再認証
    • GitHubではパスワード確認の場面でWebAuthnが利用可能に

検討事項

  • リカバリーの認証方式でカスタマーサポートの負担が決まる
  • 利用可能な環境の制限
    • user-agentによる判別
    • platform
    • Attestation
  • 追加認証要求のタイミング
    • パスワード認証に成功したら
    • パスワード認証の結果に関わらず
    • パスワード認証前に

パスワードレス認証としての導入

  • パスワードレスとは?
    • パスワードを使わない
      • 所持 or 生体 or 記憶
    • FIDO UV相当
      • 所持 + (記憶 or 生体)
  • 新規登録
    • リカバリーを考慮して効率的に2種類の認証方式を設定するには?

WebAuthN を実際に入れてみてどうだったか

  • @kasecatoさん(nulab)

WebAuthN導入前の話

WebAuthN導入のモチベーション

  • セキュリティキーや顔認証でログインしたい
  • 社内ハッカソンで作ってみた
  • しかし当時は仕様変更が続いていて不安
  • 今では2019/3にW3C仕様勧告

WebAuthN導入中

認証フローの設計

  • 2要素認証
    • 利便性の改善にはつながらない
  • 単要素パスワードレス認証
    • 多要素を強制したいフローで困る
  • 多要素パスワードレス認証 - 採用
    • 利便性と安全性を両立
  • ユーザネームレス認証
    • windows10以外で普及したと思えなかった
  • Email First Sign-in Flowを参考に実装

アカウントリカバリの設計

  • 盗難紛失
    • 従来のパスワード認証でログインし認証器の無効化
  • パスワードを削除したユーザ
    • リセットのEメールを送信

実装が困難だった点

  • macのtouchID複数登録の後勝ち問題
  • アカウント新規作成でパスワードレス

WebAuthN導入後

サポートへの問い合わせ

  • 指紋が変わって生体認証使えなくなったらどうすればいいか
    • PINで認証器解除して再登録をしてもらう

パスワード削除でモバイルから使えない

  • パスワード削除したらパスワードでログインしてるものを全部サインアウト
  • モバイルはFIDO対応してないからパスワード再発行しないといけない

Touch IDが使えなくなった

  • 公開鍵クレデンシャル登録時のChromeのProfileに紐づく

使用可能な認証器がわからない

  • いろんな認証器がある
  • これ使えますか?と問い合わせがくる

「ServerlessDays Tokyo 2019」に参加してきました

  • ServerlessDays Tokyo 2019に参加してきました。

tokyo.serverlessdays.io

  • 事例紹介のセッションではかなり踏み込んだ設計の話をしてくれることが多く参考になることが多かったです!
タイトル 発表者
10x Serverless Product Development for a Startup with Microsoft Azure Yutaka Tachibana(EBILAB)
Keynote Keisuke Nishitani (AWS)
Keynote: Infinite Scaling, Finite Failures: Serverless Resiliency Patterns and Lessons Learned Katy Shimizu (Microsoft)
グローバル展開のコネクティッドカーを支える大規模サーバーレスシステム事例 Yuya Urayama (TOYOTA), Takanori Suzuki (Acroquest Technology) and Eiichiro Uchiumi (AWS)
All You Need Is JavaScript Jensen Hussey / Cloudflare
Zero Scale Abstraction in Knative Serving Tsubasa Nagasawa (CyberAgent)
空調設備向けIoTシステムにおけるクラウドランニングコスト 野原 健太 / ダイキン工業株式会社
ISPがサーバレスに手を出した 伊藤良哉 & 松田丈司 (NTTコミュニケーションズ)
AWS Lake Formation で実現、マイクロサービスのサーバーレスな分散トレーシング 藤武司 & 岩井良和 (Sony Corporation)
Don’t think Serverless Security, think Application Security Ido Neeman (Nuweba)
Azure でサーバーレス、 Infrastructure as Code どうしてますか? Kazumi Ohira
The hidden cost and technical debt of running huge Serverless service on production James Nguyen / MaaS Global

10x Serverless Product Development for a Startup with Microsoft Azure

  • Yutaka Tachibana(EBILAB)

スタートアップ × Microsoft Azure

EBILAB

開発しているもの

  • BIツール
    • どれくらいの人が来客するか予測
  • 画像解析
    • 入店客の人数や属性をカウント
    • 通行人数もカウント

Microsoft Azureのサーバーレスコンポーネント

  • Functionse
    • DBにデータを入れるところまで
    • LogicApp
  • PwoerBI
    • エクセルのデータをもとに表示することもできる
    • DBとかAPIから取得したJSON
  • WebApp
    • Nuxt
    • Laravelで認証
    • PwoerBIで作ったレポートをiframeで呼び出し

サーバーレスで作ったメリット

  • 開発運用コストが従来のモノリシックより少ない
  • 責務分離が自然と行われる
  • 将来的にスケールしても問題ないと楽観視できる
  • 不要になったパーツを捨てやすい
  • 分業協業しやすい

Keynote

  • Keisuke Nishitani (AWS)

Event Driven

  • LambdaはサーバーレスよりもEvent Drivenをキーワードにしたサービスだった
  • 状態の変化をイベントとして捉えて処理を実行する
  • Event Driven出ない場合処理が増えると呼び出し元にも手を入れないといけない
  • Event Drivenならサブスクライブを追加するだけ

Lambda

  • 2014年に発表
  • 当初はEvent Drivenや関数実行がキーワードだった
  • 2015年にAPI Gatewayが出てきてサーバーレスという言われ方をし始めた

Lambdaのネットワーキング

  • Lambdaの実行環境ははサービスチームのVPCで動いている
  • ユーザのVPCにElastic network interfaceを通じて接続できる
  • スケールするとサブネット内のIPアドレスを使っていく
  • ENIの作成に10~30秒時間がかかる

AWS Hyperplane

  • internal network load balancing service
  • 内部的に動いてるサービス
  • ユーザは使えない

VPC環境の改善

  • AWS HyperplaneをベースにしたVPC to VPC NATを使う
    • コールドスタートレイテンシの改善
    • ネットワークインターフェースの共有
    • スケーリング
  • LambdaからRDSへの接続
    • VPCのコールドスタート問題が解決する

モダンアプリケーション

  • 特徴
  • アプリケーション実行環境
    • EC2
    • ECS/EKS/Fargate
    • Lambda
  • マイクロサービス
    • サービスごとにデータを永続化するので疎結合
  • APIはマイクロサービスの玄関
  • メッセージングを活用してコードからステートを取り除く
  • クラウドネイティブなアーキテクチャ

Keynote: Infinite Scaling, Finite Failures: Serverless Resiliency Patterns and Lessons Learned

サーバーレス

  • サーバの抽象化
  • イベント駆動型
  • 従量制課金

すべての依存は障害になりうる

  • レースコンディション
  • ネットワーク障害
  • レート制限
  • ハードウェア障害
  • => 再試行のデザインパターン

グローバル展開のコネクティッドカーを支える大規模サーバーレスシステム事例

  • Yuya Urayama (TOYOTA)
  • Takanori Suzuki (Acroquest Technology)
  • Eiichiro Uchiumi (AWS)

はじめての大規模アジャイル

トヨタのコネクティッドサービス

  • 車載デバイスがネットワークに繋がる
  • 車のヘルスチェックがスマホでわかる
  • 盗難の検知追跡エンジンの再始動停止

サーバーレス

  • 日中と夜でアクセス数の差が顕著
    • 通勤や業務で車に乗る人が多い
    • サーバーレスなら不必要にリソースを確保しなくていい
  • ライフサイクルが長い
    • 買い換えるまで7〜8年
  • コネクティッドカー国ごとにまだ法規制が違う
    • 国ごとにプラットフォームを確保
    • サーバーレスならシェアの大きい地域と小さい地域に合わたサイズにできる
  • データは蓄積せずにリアルタイムで流している

アーキテクチャ

指針

  • 十分にシンプルな粒度
  • ライフサイクルが異なるコンポーネントを自立
  • プロセスをステートレスに

アーキテクチャスタイル

  • Nティアー
    • 役割に応じていくつかの層に分割
    • Gateway
    • Logic
    • Data
  • ウェブキュー/イベントドリブン
  • マイクロサービス
    • ライフサイクルを共有できる単位のまとまり
  • 車載デバイスと地域サービスをつなぐプラットフォーム

AWSのサービス

開発の課題

クラウドで動かさないといけないのでテストしづらい

  • CI/CDでテスト実行環境整備
  • サービス単体テスト
    • LocalStack
    • プロキシで向き先無理やり変えてテストしてる
  • サービス間連携テスト
    • Karate

全体のトレーシングが難しい

  • ログはCloudWatchに
  • 想定以上にコストが高くなるから注意
  • X-Rayで分散トレーシング

自動スケール便利だが問題になるケースも

  • Lambda失敗して再試行するようにしてた
    • 再処理のLambdaが数千実行されてしまった
    • 同時実行数の上限はアカウント単位
    • 他のLambdaの起動を妨げる危険性
    • 変に上限までいかないように関数ごとに設定する

All You Need Is JavaScript

  • Jensen Hussey / Cloudflare

Cloudflare

  • 世界中にデータセンターがある
  • ユーザに近いデータセンターでJavaScriptを実行することができる

なぜJavaScript

  • 一番使われている言語だから
  • サーバーサイド
    • Node
  • モバイル
    • ReactNative
  • ネイティブ
    • Electron
  • サーバーレス
    • Cloudflare Workers

Cloudflare Workers

  • ServiceWorkerをベースに考えられたもの
  • v8で実行される
  • WebAssemblyにも対応している

Zero Scale Abstraction in Knative Serving

Knative

  • Build
    • 卒業してなくなった
    • Tektonになった
  • Serving
  • Eventing

Knative Serving

  • HTTPリクエスト駆動でスケールする
  • 素のk8sを使うとyamlをたくさん書かないといけない
    • Knative使うと簡単になる
  • Kanative Serviceを書いていく

事例

  • なぜKnative?
    • k8sを抽象化できるから
      • ネットワークのレイヤーも含めて抽象化
    • yaml地獄から脱却
    • ゼロスケールできること
      • パフォーマンス < 可用性 のサービス
    • Dual Stack
      • knativeとk8sのリソース併用
    • Portability
  • イベントを受けて処理をするところだけzero scalingを使う
  • Eventingはまだ未成熟だから採用見送り

空調設備向けIoTシステムにおけるクラウドランニングコスト

ダイキン工業とIoT

システム規模

  • 各機器から毎分データ発生
    • 膨大なアクセス
    • 高い処理性能とスケーラビリティ
    • 無限に発生するデータを扱えるストレージ
  • スモールスタート
    • 徐々に接続する機器を増やしていく
  • => サーバーレスでNoSQLで

サーバーレス開発

  • サーバーレス開発はクラウドランニングコストとの戦い
    • 目標のランニングコスト以内で動くシステムを作れるかどうか
    • IoTのように負荷が高いシステムだと従量課金でもコストは嵩む
    • サービスごとの課金体系を把握し設計する

システム構成

空調機 -> AWS

  • 変化のあった項目を毎分送るようにした

アプリ -> AWS

  • 一度のコールで同時に複数機器のデータを取得
  • 毎分データを取り出す

ランニングコスト

  • コストのかかる部分
    • Dynamoへの書き込みでのWCUコスト
    • データ取得時のLambdaの処理時間
  • DynamoDBのデータ構造が肝になる

DynamoDBのデータ構造

  • 数十kmの項目があると一部だけ更新する場合もWCUを消費してしまう
  • 運転データごとにアイテムをわける
    • 1機器Nアイテムとしてデータを持つ
  • Lambdaからアクセス時に機器数×N個分アクセスしないといけない
    • Partition Keyを建物IDとして建物ごとにまとめて取得できるようにした

まとめ

  • 今回の要件は書き込みは少しずつ、読み込みはまとめて
  • 要件にあった構成にすることでコストを削減できる
  • DynamoDBは書き込みのほうが読み込みより10倍課金額が高い

ISPがサーバレスに手を出した

ISP

  • Internet Service Privider
  • 家 - 回線 - ISP - インターネット

サーバーレスどこで使ってるか

  • 通信する前にルールを取得する必要がある
    • そのAPIをサーバーレスで作ってる

サーバーレス以外の選択肢

  • 選択肢
    • 物理サーバ
    • 自社IaaSサービス
    • 他社IaaSサービス
  • 納期3ヶ月
    • サーバーレスじゃなきゃ無理

社内基準と通信事業としての基準

  • 社内クラウドを使わない理由
    • IPv6対応してなかった
  • 信頼性の担保
  • 100万ユーザついているサービスが1時間止まると総務省に報告しないといけない

IPv6の受難

リリース後

テストの自動化

  • 全般
    • ローカルで軽量に行えること
    • デプロイして行うテストは最小限に

ローカルでテスト

  • Serverless Frameworkとプロアグ員を駆使
    • serverless-offline
    • serverless-dynamodb-local

負荷試験/長時間試験

  • Gatlingで叩いてる
    • レポートが見やすい
  • テストをやって・・・
    • DynamoDBのaute-scaling忘れに気がつくことができた

CIパイプライン

  • GitLab CI/CD
    • ローカルでしか動かないということがないように
    • dockerコンテナで実行することで環境が汚れない
    • commitとテスト結果をバインドすることで証跡を残せる
  • serverless-offlineのテストとかをCIで動かしてる

Infra as Code

  • Serverless Frameworkとにかく便利
    • ローカルでのテスト
    • 本番へのデプロイ
  • Azureは対応してるのが多くない
  • AWSもすべてをコード化できるわけではない
    • sls deployのあとにaws-cli使ってるところもある
  • 構成変更
    • 移行後の構成をsls deploy
    • 切り替えて古い方をsls remove

AWS Lake Formation で実現、マイクロサービスのサーバーレスな分散トレーシング

背景

  • aiboやMultifunctional Lightなどのバックエンドをサーバーレスで作ってる
  • マイクロサービス構成
  • 呼び出しチェーンが長い
  • 非同期も多い
  • クロスアカウントやオンプレとの連携も
  • 1ヶ月立ってから問い合わせや障害のトレースをすることがある

分散トレーシング

  • 分散アーキテクチャの処理の可視化や追跡性を向上させるための仕組み
    • どのサービスをどういう経路でたどったか
    • どこにどれくらい時間がかかったか
  • 共通のIDを受け渡していって経路を特定できるようにする

Lake Formation

  • 複数のAWSアカウントにまたがったログを集約分析できる
  • サーバーレスで実現できる
  • リアルタイムな分析はDataDogで長期的に残しておくのはLakeFormation

トレーシング基盤の構成

  • Step Functionsでログの出力
  • Lake Formationで各アカウントからログを集約

トレーシングIDの取得と伝播

  • X-Rayだけでは非同期イベントのトレースが困難
  • それぞれ工夫して対応した

Don’t think Serverless Security, think Application Security

  • Ido Neeman (Nuweba)

サーバーレスは新しい攻撃の窓口になりうる

  • イベント駆動アーキテクチャはサーバーレスに限った話ではない
  • むしろサーバーレスの方がセキュアな場面もある

サーバーレスはマネージしにくい

  • 小さい単位の関数にすることで管理しやすくなる

サーバーレスで過剰なアクセスがきたらどうするか

  • スケールするのが仇となって大量の課金につながる
  • 関数ごとに制限を設定しておく

サーバーレスの実行権限が広くなりすぎないか

  • IAMの権限を最小限にしぼっておくこと

Azure でサーバーレス、 Infrastructure as Code どうしてますか?

  • Kazumi Ohira

Infrastructure as Code

  • インフラのリソース構成/管理をコードで行うこと
  • メリット
    • 自動化できる
    • ミスが減る
    • レビューしやすい
    • バージョン管理できる

クラウドにおけるリソース管理

  • IaaS
    • Terraform
    • AWS Cloud formation
  • Container
  • Serverless

AzureでIaC

  • ARM templateを使う
    • 冪等性を管理してくれる
    • エラーハンドリングしてくれる
    • 差分デプロイ並列デプロイできる

The hidden cost and technical debt of running huge Serverless service on production

  • James Nguyen / MaaS Global

クラウドサービスを使うこと

  • クラウドベンダーに預けてるデータが壊れたら?
    • 最近もAWSの大規模障害があった
  • 技術的制約
    • Lambdaで最新のNodeが使えるようになるまで3ヶ月くらいかかる
    • 最新の情報を入手してアップデートし続けないといけない
      • 知らないところでAPIが廃止されてしまわないように
    • よりよいサービスに置き換わっていくこともある
      • 状況に合わせて移行していく必要がある
  • ベンダーロックイン
    • マルチベンダーは簡単ではない
    • Serverless Frameworkで抽象化はできる