GyazoでのPWA/WebAPIとの向き合い方

こんにちは

https://gyazo.com/422954eb4591d345c7d507cae73748ae

自己紹介

Pasta-K

Nota Inc エンジニア at 京都

主にGyazoのフロントエンドの面倒を見ています

マンガ / クラフトビール / サッカー観戦

過去にこういうトークをしました

https://gyazo.com/7730c96e015c9e30003ec3a46c7c0b4e

会社・サービス紹介

https://gyazo.com/7407c61d0a4f6adc06c7b1ecb2507c6a

Gyazoについて

スクリーンショット共有ツールです

https://gyazo.com/54cc441ea25198e38899ba6a8c5d8098

GyazoとPWA

PWAを目指そうという意図があるわけではない

所謂PWAが持っている要素もあまり満たしていない

https://gyazo.com/176912b6adcec4a6fde707ffbb263952

PWAはProgressive Web Appの略で、Webアプリケーションをよりネイティブアプリ（スマートフォン、タブレット、デスクトップ向けアプリケーション）に近づけるベストプラクティス集になります

ベストプラクティスの恩恵はしっかり受けている

Webで出来ることを積極的に取り込んでいる

この辺の話をします

Gyazoのアプリケーション構成について

クライアントアプリケーション

各種環境からのアップロードをする

Gyazo / GyazoGIF / Gyazo Replay

閲覧や共有、編集、検索などが出来る

クライアントアプリケーション

Gyazoは画像をアップロードするためのクライアントアプリケーションを各環境に提供している

Windows / macos / Linux

iOS / iPadOS / Android

一方で最近はブラウザ拡張から使い始めるユーザーも多くいる

ウェブブラウザでのアップロードが使い始める入り口になっている

GyazoとWebブラウザ

多くのユーザーは共有されたものをWebブラウザで閲覧する

画像に対する操作は全てウェブアプリケーションが担う

メタデータの編集

画像の加工

画像ファイルのアップロードはWebから出来る

→ 体験を向上させようとすると、究極的にはWebブラウザで出来ることに律速される

何がWebブラウザで出来るかを知っているかどうかに律速される

Web APIと僕

利用できそうなものがあれば積極的に取り入れる

Webブラウザが持っているAPIを使うことで自然とユーザーの体験を向上できる

WebアプリケーションがOSの機能を呼び出して利用する部分をラップしてくれる

OS間の差分などもブラウザが吸収してくれる

ユーザーは既に知っているUIで新たな体験が出来るので学習コストが低い

事例紹介という題目を頂いていたのでいくつか例を紹介します

<input type=color />

それまではカラーピッカーをReactで実装したライブラリを使っていた

OSの提供しているUIが利用できる結果、画面内から色を取ってくるスポイトツールなども利用できるようになった

現在はChromiumのinput関係のUIはアクセシビリティなどのために変更された

Web Share Target Lv2を使ったアップロード

PWAを使えるようにすることで利用できる人を増やす

アプリがバージョンの都合で入れられない

容量が気になるので入れたくない

Web Share Target Lv2について

OSの共有メニューなどからインストール済みのWebアプリケーションに送信できるようにするAPIがWeb Share Target API

以前はtitleやURLなどのみだったがLv2でファイルも含められるように

POSTが使えるようになっています

Chrome for Androidではリリース済み

Chrome for desktopでもM89から利用可能になります

Web Share Target Lv2とServiceWorkerを組み合わせています

Web Share Targetの共有先はインストールしたscopeの中しか指定できない

Gyazoのアップロードのエンドポイントはupload.gyazo.comなので、素朴には送信できない

この問題を解決するためにWeb Share TargetからのPOSTを一度ServiceWorkerでプロクシしている

example

code: serviceworker.ts

const formdata = await event.request.formData();

const imagedata = formdata.get('imagedata');

if (!imagedata) throw new Error('imagedata is empty');

const filename = (imagedata as File).name;

if (filename) {

const metadata = {

title: filename

};

formdata.append('metadata', JSON.stringify(metadata));

}

method: 'POST',

body: formdata,

credentials: 'include'

}));

const responseUrl = new URL(await res.text()).pathname;

return Response.redirect(responseUrl, 303);

Local Font Accessを使ったフォントの利用

ユーザー自身の環境にインストールされているフォントをWebブラウザで読み込めるAPI

これまではcanvasを使っていくつかのフォントがインストールされているか確認する振る舞いを実装していた

Tokenをrenewするにはフィードバックが必要

ユーザーから報告されていたタブがクラッシュする現象などをフィードバックして修正されたりしました

今後使えたら良いなと思っているもの

※実際に今後実装するものを約束するものではありません

この資料を作っている間に使えるようになりました

コラム: Web APIと標準化

ちょっと横道に逸れます

「このAPIはChrome独自かWeb標準か」「Safariはどうなっているんですか」

Chromiumに先行で実装されがち

Chromiumは機能を載せる際に標準化のプロセスに乗せることは基本になっている

最終的な仕様までたどり着けるかは別として、Chromiumに入る新しいFeatureは標準化のプロセスに乗っかっていないと開発ステージ先に進めないようになっています。

MozillaにはMozillaのスタンスがある

Appleはよく分からないがやる気が無さそうに見える…?

フィンガープリンティングに使われそうなものは拒否するスタンス

Googleの中の人とかがやっていたPWAに関するbugの集積所

最近は更新は停止している模様

利用することと標準化

利用されないAPIはなかなか前に進まない

使っていくことで初期にフィードバックすることで仕様が前に進む

仕様の抜け漏れなどがあることもよくある

未定義な振る舞いなど

まとめ

Gyazoでは積極的にWeb APIを利用しています

PWAか否かというよりはWebブラウザの上で我々のアプリケーションが如何に便利に使ってもらえるかという挑戦だと思っています