目次

第1章 本書の概要

1.1 対象読者
1.2 注意事項
1.3 使ってるライブラリーなどのバージョン
1.4 情報共有や連絡先
1.5 サンプルコード
1.6 コードフォーマット
1.7 免責事項
1.8 表記関係について
1.9 底本について

第2章 PWAの概要やツールの紹介

2.1 PWAの概要
2.2 PWAを作るためのブラウザーのAPI
2.3 PWAを作るための補助ツール
2.4 まとめ

第3章 PWAの実装方法解説

3.1 PWAとするサイトの雛形作り
3.2 Firebase Hostingを使ってサイトを公開
3.3 Add To Homescreenができる最低限のPWA作り
3.4 Workboxを使ったオフライン対応のPWA作り
3.5 まとめ

第4章 Web Pushの実装解説

4.1 クライアントとサーバーのやりとりを円滑にするための準備
4.2 プッシュ通知を行うための下準備
4.3 プッシュ通知サーバーの実装解説
4.4 クライアントの実装解説
4.5 まとめ

第5章 Service Worker

5.1 Service Worker概説
5.2 Service Workerのインストールについて
5.3 Service Workerの注意点
5.4 その他のイベント
5.5 まとめ

第6章 おわりに



第1章 本書の概要

 本書を手にとっていただきありがとうございます。本書はProgressive Web Apps(以降、PWA)に関する情報や実装方法についての解説書です。

 まず2章で、PWAに関する概要から関連技術、ツールについて紹介します。3章では簡単なPWAを実装し、4章ではWeb Pushをサーバーも含めて実装する方法を解説します。そして、最終的にはサーバーレスプッシュ通知サーバーとして、AWS Lambdaへのデプロイの仕方も紹介します。5章にはService Workerの概要やどのように扱うのか、注意点などをまとめています。

1.1 対象読者

 次のような方々を対象としています。

 ・PWAの作り方を知りたい

 ・Web Pushを体験したい

 ・サーバーにちょっと触れてみたいフロントエンドエンジニア

 ・サーバーレスとはどんなものかというのを知りたい

 ・yarnやnpmを扱える

1.2 注意事項

 本書はとても広い範囲を取り扱っています。Webのフロントエンドから始まり、プッシュ通知を送るためにFirebaseを使い、AWS Lambdaで通知を送るためのサーバーレスのPIサーバーを構築します。そのため、個別のサービスなどにいての記述は省略しています。たとえば、AWSのアカウント登録などについては紹介していません。

 どうしてこんなに広くなったか?それは筆者自身がWebでプッシュ通知をやってみたかったからです。完全に趣味といってもいいでしょう。本書では、その過程で出てきたtipsやノウハウをまとめています。

 またライブラリーやフレームワーク、サービスは次のものを使っています。Vue.jsは使い慣れてるので使いましたが、他のフレームワークないし生のJavaScriptでも使えることを意識しています。

 ・Vue.js

 ・Workbox

 ・Firebase

 ・AWS

 ・Serverless Framework

 そして使用するブラウザーはGoogle Chromeを想定しています。

1.3 使ってるライブラリーなどのバージョン

 ・Vue.js - v2.6.6

 ・Vue CLI - v3.4.1

 ・Workbox - v4.0.0

 ・Firebase - v5.8.5

 ・Serverless Framework - 1.38.0

1.4 情報共有や連絡先

 本書のTwitterのハッシュタグは「#try_pwa_np」です。感想や疑問などありましたら、ハッシュタグ付きでツイートしていただけるとキャッチアップします。感想をいただけると次の執筆のモチベーションにつながるので、もしよければツイートしてくれると嬉しいです!

 また内容の誤植などありましたら、お手数ですが次のリポジトリーにissueを作っていただけますと助かります。もちろんハッシュタグ付きでツイートしていただいてもかまいません。

 https://github.com/mya-ake/try-pwa-apis/issues

更新情報

 サンプルコードの修正した内容はこちらに記載しています。

 https://github.com/mya-ake/try-pwa-apis/blob/master/UPDATE.md

1.5 サンプルコード

 本書のサンプルコードは次のリポジトリーで管理されています。

 https://github.com/mya-ake/try-pwa-apis

1.6 コードフォーマット

 書籍中に出てくるコードは基本的にESLintで整形されています。ESLintは基本prettier + 次のシングルクォーテーション、末尾カンマの設定です。ただし、Vue CLIで作成して、そのまま解説に移っている箇所では次の設定はしていないので、ダブルクォーテーションのままコードが記載されています。フォーマットの関係上そうなっているので、表記ゆれではありません。

  'prettier/prettier': [
      'error',
      {
        singleQuote: true,
        trailingComma: 'all',
      },
    ],

1.7 免責事項

 本書に記載された内容は、情報の提供のみを目的としています。したがって、本書を用いた開発、製作、運用は、必ずご自身の責任と判断によって行ってください。これらの情報による開発、製作、運用の結果について、著者はいかなる責任も負いません。

1.8 表記関係について

 本書に記載されている会社名、製品名などは、一般に各社の登録商標または商標、商品名です。会社名、製品名については、本文中では©、®、™マークなどは表示していません。

1.9 底本について

 本書籍は、技術系同人誌即売会「技術書典5」で頒布されたものを底本としています。

第2章 PWAの概要やツールの紹介

2.1 PWAの概要

 まずはPWAとはどういうものかを解説します。PWAとは「Progressive Web Apps」の略称です。PWAはGoogleが提唱した、Webアプリケーションのひとつの姿です。

ネイティブアプリとWeb、そしてPWA

 PWAとはなにかをざっくりと説明すると、「ネイティブアプリとWebのいいとこ取りをしたもの」です。次の図は「Progressive Web Apps - PWA Roadshow」という動画のスクリーンショットです。これはYouTubeで公開されています。

  

 出典:Progressive Web Apps - PWA Roadshow(https://youtu.be/z2JgN6Ae-Bo?t=166)

図2.1:

 オレンジ色(左上)がネイティブアプリで青色(右下)がWebです。また縦軸のCapabilityはできること、Reachはどれだけの人に届くかという指標です。見ていただければわかるのですが、ネイティブはできることが多く、リーチ力が弱い。Webはリーチ力が強く、できることが少ない。PWAはこのふたつの指標をどちらも満たす可能性があります。

FIREとは

 PWAはWebにおけるUXの目指す姿でもあります。

 すでにご存知の方もいらっしゃるかもしれませんが、FIREという指標が存在します。これは、「Fast、Integrated、Reliable、Engaging」の頭文字を取ったものです。今ではFIREはWebについての指標という扱いになっていますが、以前はPWAの指標でした(PWAのときはIntegratedを除く3つ)。筆者はこの扱いの変化から、GoogleはPWAで目指していたことをWebの当たり前にしたいのではないのかと考えます。

 ではFIREについて軽く解説します。まずFIREを構成する4単語を筆者は次のように訳しています。

 ・Fast:速さ

 ・Integrated:デバイスへの統合

 ・Reliable:動作の信頼性

 ・Engaging:魅力的であること

 それぞれ少し紹介します。

 Fastは文字通り速さです。これは読み込みのスピードやスムーズに操作できるという速さを表しています。

 IntegratedはWebアプリケーションの体験をデバイスに合わせることです。たとえば、PWAの特徴とも言えるホーム画面からの起動です。ホーム画面にWebアプリケーションを追加することで、ユーザーはブラウザーを起動しなくてもホーム画面にいるアイコンをタップし、Webアプリケーションを利用できます。ホーム画面に配置されていることでネイティブアプリケーション同様の起動体験を提供できます。

 Reliableは動作の信頼性です。これは主にネットワーク接続についての信頼性を示しています。ネットワークに接続していないと起動できないアプリケーションをユーザーはどう思うでしょうか?せっかくホーム画面に追加しているのに起動できないアプリケーションを、アプリケーションと認めてもらえるでしょうか?少し言い過ぎかもしれませんが、Reliableはこのように「アプリケーションが常に開ける」という信頼性に関する指標になります。

 Engagingはアプリケーションの体験が魅力的であることです。どのようなアプリケーションが魅力的であると言えるでしょうか?サイトにアクセスた時、いきなりプッシュ通知を許可しますか?と聞いてくるサイトは魅力的でしょうか?答えはもちろん違います。これはユーザーが意図していない動作です。このような意図していない動作・機能ではなく、ユーザーの意図通りに動かせる快適なアプリケーションを作ろうという指標になります。

 この4つを突き詰めるとWebアプリケーションとしてのUXが高まります。FIREを意識して開発することはユーザーへの思いやりとも言えるかもしれません。

どういうものがPWA?

 PWAのチェックリストをGoogleが公開しています。

 https://developers.google.com/web/progressive-web-apps/checklist

 このチェックリストはベースラインとその他の気にすべき項目が列挙されています。またテスト方法とその項目を満たすための方法も書かれています。このベースラインを満たすことがPWAとしての第一歩となります。ベースラインを翻訳すると次の内容になっています。

 ・HTTPSで配信されている

 ・レスポンシブ対応

 ・すべてのURLがオフラインで読み込み可能

 ・ホーム画面に追加するためのメタデータ(Web App Manifest)が用意されている

 ・3G環境だったとしても最初のアクセスは高速に読み込まれる

 ・クロスブラウザーで動作する

 ・ネットワークに依存しないページ遷移

 ・すべてのページに一意のURLが存在する

 これらの一部のテストはLighthouse(https://github.com/GoogleChrome/lighthouse)というツールで機械的にテストすることができます。このLighthouseは、Chrome Developer Toolsに組み込まれています。次の画像はChrome Developer Toolsのスクリーンショットです。Lighthouseは右上のAuditsパネルから使うことができます。

図2.2:

 真ん中のProgressive Web Appにチェックを付けて下部の「Run audits」というボタンを押すとテストが実行されます。このテストを実行すると次の画像のように100点満点で点数をつけてくれます。

  

 本書のサンプルコードのサイトの結果(https://try-pwa.mya-ake.org/)

図2.3:

 画像の「Passed audits」がLighthouseが機械的にテストする項目です。ベースラインのチェックリストの項目に加えて、HTTPからHTTPSへのリダイレクトテストなども行います。その上の「Additional items to manually check」はベースラインのチェックリストに存在してますが、Lighthouseで機械的にテストできない項目です。「クロスブラウザーで動作する」「ネットワークに依存しないページ遷移」「すべてのページにURLが存在する」の3つがテストできていません。これらのテストは別のツールを使うか、手動でテストを行う必要があります。

 筆者の場合は次のようにテストしています。

 ・クロスブラウザーでの動作は手動でテスト

  ─Brwosersyncを使い、開発しながら同時にチェック(レイアウト崩れもチェック)

 ・ネットワークに依存しないページ遷移も手動でテスト

  ─オフライン周りの処理を作成した時にチェック

 ・すべてのページにURLが存在するかは手動でテスト

  ─そもそもURLがいないサイト設計にしないことが重要

 つまりほぼ手動ですね。この辺りも自動化したいところですが、よい方法があれば情報をいただければ嬉しいです。

 このように、ベースラインについてはLighthouseを使い手軽にチェックできます。LighthouseのPWAの項目で緑(75〜100点)になっていればPWAと言えるでしょう。

  

 ベースラインのより細かなチェック項目は大きく分けて次の6つです。

 ・Googleインデックスされやすいか

 ・UX

 ・パフォーマンス

 ・キャッシュ

 ・プッシュ通知

 ・その他

  ─Credential Management API

  ─Payment Request API

 これらについては、PWAをより極めたいときに参照してみると、よりよい体験をユーザーに提供できるかもしれません。

まとめ

 Google DevelopersのPWAのサイト(https://developers.google.com/web/progressive

-web-apps/)には、PWAは「Web上で驚くべきユーザーUXを提供する新しい方法」と書かれています。またFIREやPWAのチェックリストなどは、いずれもUXに行き着くものです。つまり、PWAはWebにおけるUXを向上するための取り組みのひとつです。

 また、PWAはスマートフォンに限った話ではなくなりつつあります。Chromeのバージョン73からPCでもPWAとしてWebアプリケーションをインストールできます。筆者自身もTwitter LiteをmacOSにインストールして利用しています。今後業務アプリケーションなどデスクトップ向けのアプリケーションをPWAとして提供する事例が出てくるかもしれません。

 本章の冒頭で、PWAはネイティブアプリとWebのいいとこ取りをしたものと表現しました。これだけを見ると、ネイティブアプリがいらないように見えるかもしれませんが、そんなことはありません。PWAはあくまでもブラウザーにできる以上のことはできません。最近はブラウザーでできることも増えてきましたが、それでもできることは限られています。

 たとえば、デバイスに近い機能はブラウザーで提供されている範囲でしか使えません。デスクトップPWAの場合は、ファイルアクセス(書き込み)ができません。ファイルアクセスをするにはElectronなどのデスクトップアプリケーションを作るためのフレームワークなどを利用するのがよいでしょう。

 ※Google ChromeではFileSystem APIの実装が進んでおり、Google Chromeでは将来的にファイルシステムが扱えるようになります。

 このように、PWAがあれば既存のアプリケーションを代替できるわけではありません。あくまでアプリケーションを作る上での選択肢のひとつと捉えてください。

  

 ページ数の都合上、PWAの活用の仕方やメリット・デメリットといったテーマは割愛します。ただ活用の仕方などについては、筆者が以前登壇した際の資料に記載しています。次のURLで公開されているのでご興味のある方はそちらをご覧ください。

 https://mya-ake.com/slides/pwa-will-provide-future-web

試し読みはここまでです。
この続きは、製品版でお楽しみください。