元教員がWebアプリを毎日1つずつ作ってみた（6〜10日目）

こんにちは。

私は昨年度まで教員をやっておりましたが、２０１９年の１月３日から毎日Webアプリを１つ開発するWebアプリ開発マラソンを行なっております。

とても簡単なアプリから作成しておりますので、前回のノートをまだ見られていない方は、ぜひそちらから読んでみてください。

▪️前回のお話のまとめ

前回はNuxt.js（Vue.js）の基礎的な機能を利用した簡単なアプリの開発した事になります。以下のような特徴のものです。

　・ １ファイルで完結するもの
　・ データの保存や他のサーバなどとの通信を行わないもの
　・ UIフレームワークを利用したもの（５日目のみ）
　・ インターネット経由でアクセス可能なもの

▪️今回のお話

今回はより本格的なWeb開発を行なっていきたいと思います。もう少し具体的にしていくと以下のようなものになります。

　・ 複数ファイルに跨って作る必要のあるもの
　・ データの保存を行うもの
　・ ユーザ認証を行うもの
　・本格的にUIフレームワークを利用したもの

それでは、６日目から１０日目の５日間にどのような開発を行なってきたかについてまとめていきます。

▪️（ちょっとだけ技術的なお話）データの保存って？

最初の頃から何度もデータの保存と言っているのですが、結局それはどういう意味なのか、簡単に説明だけさせてください。（理解してるよーという方や結果がだけ見たい人はガンガン読み飛ばしてください。）

これまで作ってきたものはどれも、ブラウザがホスティングされたファイルをインターネット経由で読み込んで実行するだけものでした（下の図を参照）。

この図でも分かる通り、毎回事前にアップロードされたファイルを実行しているだけなので、結果を保存できないわけですね。

今回は、データを保存できる場所（データベース）を用意して、そこに書き込んだり、読み込んだりすることでデータを保存できるようにしたいわけです（下の図を参照）。

このようにデータベースというデータ置き場にデータを置いておくことで、データが変われば結果が変わるようにできるわけですね。今回やりたいことはこういう事です。

▪️データベースサービスについての補足

少し話が逸れますが、従来のWebサービスだと、こんな風にブラウザから直接データベースと繋げるようなことはせずに、一旦仲介役のサービスに渡して、仲介のサービスがデータベースの読み書きをします。

データベースは大切な情報（ユーザの情報とか）がたくさん入っているので、ブラウザから直接読み書きできるというのは、原理的にどんな処理をしているのかユーザが知ることができるためセキュリティ上の問題を引き起こす可能性を否定できないからです。（ただし、読み書きのルール設計をしっかり行う事で、セキュリティ上のリスクは軽減できるのでこういったサービスを使っている＝危険というわけではないです）

一方で、大した情報を保存しない場合やプロトタイプ的なものの場合は、あえて直接データベースを読み書きできるようにする事で、開発効率が格段に上がります。「仲介のサービスを作って、データベースへの読み書きのためのプログラムを書いて、デプロイして...」といった作業をしなくて済むからですね。

こんな感じでどんどん広まっているFirebase（Firestoreを含む）ですが、どんどんルール作りに関する知見もたまってきて、今後より安全でかつ高い開発速度を実現できるようになると思います。

また前置きが長くなりましたが、６日目から結果を見ていきましょう。

▪️６日目

６日目は、データの保存まで考えてアプリを開発できるのでかなりアプリの幅が広がりました。そこで、あえてじゃんけんゲームを作りました。

皆さんは「インターネット経由で離れた人とじゃんけんしたい」と思ったことはありませんか？

はい、ないですよね。私も同じです。

Githubレポジトリ：nuxt-janken

見た目のことはとりあえず何も言わないでください。

機能としては、じゃんけん部屋の作成・保存とじゃんけんで出した手のデータの保存、じゃんけんの勝敗判定です。

FirebaseのRealtime Databaseを利用してじゃんけん部屋とじゃんけんの手を保存します。これをお互いが読み書きする事で、相手の手と勝負することができるわけです。

FirebaseのRealtime Databseの設定はとても簡単にできて、すぐに繋がってアクセスできます。めちゃくちゃ便利です。何よりも基本無料です。

ただ、最初にルール（読み書きアクセス制御）をサービス側に適用（デプロイ）することを知らずに小一時間ハマりました。ただ、きちんと解説通りに進めていけば困る事はほとんどないはずです。

一方、サービスのインターネット公開について問題がありました。前回からホスティングサービスとしてnow.shを利用していますが、これまでのやり方だと、今回のように動的にリンクが増えるようなケース（部屋を作ってリンクを発行する）だとうまくいきません。

これは事前にファイルを出力してnow.shにアップロードするやり方を取っているためです。now.shで同じやり方（静的ファイルを作ってアップロードするやり方）をされている方は注意が必要かと思います。

７日目

７日目は前日の反省を生かして、もっと一般的なものを作ろうと思い、チャットアプリを作りました。

Githubレポジトリ：nuxt-chat

機能としては、メッセージの送信と受信です。

送信側はメッセージの送信でFirebase Realtime Databaseに書き込んで、受信側は、新しい書き込みがあるとそれを取得して表示するというシンプルなものです。

Firebase Realtime Databaseを利用していると、データが新しく保存されたタイミングで自動でデータを読み込むようにすることが簡単にできます。ユーザ側はページの更新などをしなくてもいいから楽ですね。

８日目

８日目は前回のチャットアプリを修正して、ユーザ認証機能つきのチャットアプリを作りました。また、あまりにもイマイチな見た目を少し改良しています。

デモサイト：Easy Chat
Githubレポジトリ：nuxt-chat

ユーザ認証には、Firebase Authenticationを利用しました。これを使うことで、Googleやtwitter、Facebookなどのサービスと連携して、ユーザ認証を行うことができます。

今回はGoogleによる認証を導入したのですが、基本的には画面でポチポチやってると設定できるのでとっても簡単です。何より基本無料です。

9日目

９日目は、今まで導入してきたもの（UIフレームワーク、データ保存、ユーザ認証）の知見をフル活用して、多少なり実サービスに近いものを作ってみます。

デモサイト： not note
Githubレポジトリ：nuxt-sim-note

noteです。サービス名はnot noteにしました。

機能は全然足りませんが、ユーザ認証、ノート記述、ノート閲覧、いいねです。（公開後の編集・削除はありません）

ユーザ認証、ノート閲覧、いいねについては、これまで通りFirebase AuthenticationとFirebase Realtime Databaseを利用しています。

ノートの記述には、多分本家のnoteと同じmedium-editorを利用しました。Noteのようにページ上での直感的な編集を行うためです。ただ、私のデモサイトのものだとできることが限られているので、noteさんはこれにさらに拡張を加えているかと思います。

また、書き心地もかなり違っているので、かなり拘って作られているんだろうなと想像します（本質的な部分での競争力はこういう部分なんでしょうね。中のエンジニアさんの努力が素晴らしい）

見た目は今まで以上に頑張りました。Bootstrapを使っている本家さんとは違いVuetifyを使ったのですが、Vuetifyも綺麗なデザインのコンポーネント（部品）がたくさん作られているのと、本家がカードデザイン主体なので殆ど困ることなく実装できました。

余談ですが、よく開発のスキルを身につけたければ既存サービスを真似ろと言われる理由が良くわかりました。色使いや文字間の調整といったデザインの細かいポイントや、ユーザ体験を損なわないようにするための配慮など勉強になる部分が多いです。not noteはUIだけ似せてるだけで本質的な部分をおさえられてないのが申し訳ないと感じます（ですがそこは割り切ります）。

せっかくなのでnot noteに何か投稿してみてください。（投稿したら消せません。どうしても消し欲しい人は連絡ください）

１０日目

１０日目は、今までに作ったタイピングアプリを修正・拡張することにしました。機能拡張をすると同時に多少正攻法を取り入れていくイメージです。

デモサイト：CODE TYPE (PC用)
Githubレポジトリ：nuxt-fire-type

ここでは二つのことをしています。一つはコンポーネント化、もう一つはランキング機能の追加です。

コンポーネント化とは、Web開発をする上での主流な方法で、ページを構成する部品（ツールバー、ダイアログボックスなど）をそれぞれコンポーネントという単位に分けて管理するものです。（下図を参照。Vue.js公式ガイドより引用）

このようにする事で、部品の再利用性が高まったり、１ファイル内に書くコード量が減り見通しが良くなるというメリットがあります。

今回は範囲外ですが、大きなプロジェクトでは、コンポーネントを最も細かい単位（ラベル、ボタンなど）まで分割し、それらの組み合わせを階層的に持つことでコンポーネントを管理するAtomic Designという手法が使われることが増えてきているようです。

今回はキーボード部分をコンポーネントとして別ファイル（components/Keyboard.vue）に切り出し、元のページ（pages/index.js）から呼び出す形に修正しています。このようにする事で、キーボード周りのデザインや処理などを元々のページでは考えなくてよくなります。

ランキング機能の追加については、今までのやり方と同様にfirebase Realtime Database内にスコアを保存して、スコア順にデータを取得するようにしています。

ただ、Realtime Databaseには降順ソートが存在しないのでそこだけ注意が必要です。取得した後にソートするか、スコアを負の値にして保存するなどして対応が必要です。

タイピングに自信のある人はランキング１位を目指して、あるいはタイピングの練習をしたい人はぜひCODE TYPEを使ってみてください。

▪️まとめ

今回は５日目までの知見に合わせてさらに以下のものを作っていきました。

　・ 複数ファイルに跨って作る必要のあるもの
　・ データの保存を行うもの
　・ ユーザ認証を行うもの
　・ 本格的にUIフレームワークを利用したもの

全体として、Nuxt.jsとFirebaseを使った開発はかなりスムーズに進む印象を持っています。一方で、本番稼働で使うにはまだまだ知見不足（特にデータベースのルール周り）だと感じます。

また、Realtime Databaseがドキュメント志向のDBなので、SQL脳として生きてきた人は拒絶反応を示してしまうかもしれません。そもそも非正規化をするのがプラクティスって何よって気持ちになるかもしれません。

次回は、他のサービスとの連携なども進めていこうと思います。

最後に、もし気に入ったアプリがあればGithubのレポジトリにスターをつけて頂けるととても喜びます。スターが多ければ別途コードの解説などもできればと思ってます。

▪️余談

今日会社へ行く途中に、傾いた道路標識に体当たりを何度もしている人を目にしました。よく見たら少し大きめで丸っこいおじさんでした。

憶測ですが、自転車か何かで思いっきり道路標識の棒にぶつかってしまったんでしょう。それで道路標識が傾いてしまったので、それをまっすぐに直そうとしているようです。

ただ、何度おじさんがぶつかっても道路標識はメトロノームばりに動いてまた傾いた状態に戻ってしまいます。おじさんもさすがに観念したのか（あるいは私がじっと見ていたからか）流れるような動作で自転車に乗り、走り去ってしまいました。

一度曲がってしまったものってこんなにも元に戻らないものなのかと、考えさせられる出来事でした。

それではまた。