この度、音楽セッションをもっと盛り上げるWebサービス

SessionGO

を立ち上げました。

  今の所の機能としては

• 全国のセッション情報を特徴別、地域別に検索・投稿が可能
• チャットで情報交換できる

ぐらいのしょぼいもんですが、まずは必要最低限でスタートができたのでこっからどんどん拡張していきたい所存。 メインターゲットはアイリッシュセッションですが、ブルースセッションとか混じってても全然良いんじゃないですかね。  

Firebaseがすごすぎる

  さて、ここからは技術のお話。 今回はフロントエンドにVue.jsとNuxt.js、バックエンドにFirebaseを使ってみました。  

ほとんどFirebaseじゃねえか

  Googleに買収されたFirebaseをふんだんに採用しております。 サーバー用意したりデータベース用意したりといったバックエンド部分をクラウドサービスとして担ってくれるものです。 BaaS(Backend as a Service)ともいいますが、特にFirebaseはモバイル用途に強いのでmBaaS(mobile Backend as a Service)と呼ばれてるようです。

• Hosting（実際にユーザーが見るファイルを置く場所 　htmlとか）
• Storage（画像置き場。Hostingだと容量超過でお金取られるため）
• Firestore（データベース。ここでセッションとかチャットとかユーザーデータ以外一元管理）
• Authentication（認証ベース。メールアドレスはここでしか取り扱わない。GoogleとかFBでもログインできる）
• Cloud Functions（サーバーでやりたいあの機能をなんでも実現してくれるすごいやつ。自動サムネイル作成とか）

すごいやFirebase。 何より公式Docで日本語＋サンプルコード付で解説されてるのでとても実装しやすい。 個人でつかうなら、慣れない内はなんかごちゃっとしてしまうGCPより、コンパクトに要りそうな機能だけ詰まったFirebaseがオススメできるかもしれません。  

フロントエンドはナウい Vue.js + Nuxt.js

  最近のWeb系エンジニアはわがままなのでなんでもJavascriptでやっちゃおうとします。PHPグッバイ。Perl（笑） Vue.jsってだけでも凄いのに、Nuxt.jsでより簡単にフルスクラッチ開発ができるようになりました。（これフルスクラッチって言うの？） 今回はSPAな静的ファイルのみの構成。 コマンドで言うなら nuxt run generate ですね。 セッション情報ページ以外はすべてのディレクトリにindex.htmlがあり、情報が流動的なセッション情報ページはajaxでFirestoreに情報を読みに行ってjsでページを構築しています。  

SEO、OGP的な話

  SPAやらajaxやらでよく聞くのは「SEOやOGP的にどうなの？」という声。 普通のSPAだと一つのindex.html上でjsをあーだこーだして、更新が必要な部分だけ切り替えていくスタイルです。 SEO対策しようとしたらjsでmetaタグをぐるんぐるん変えていくしか無いですが、検索Botはjs読めません。（Googleは読めるっぽい） ところがNuxtによるgenerateだと各ページにindex.htmlが生成されるので、静的にmetaタグを作成できます。 開発時にmetaタグ内に変数とかを使っていても、generateコマンド走らせたときに全部平文にしてくれるので安心ですね。  

セッション情報ページのSEOとSNS用のOGPが苦労した

    セッション情報ページはindex.htmlがなく、Firestoreと通信して取ってきた情報をもとにjsでmetaタグを生成してます。 つまりjsを読めないTwitter、FBなんかのクローラーは死んでしまいます。 このご時世にSNS対応（リンク書くとOGP読んでサムネイルやタイトル表示されるやつ）できないのではお話になりません。すごーく悩みましたが、最終的にこういう解決法が見つかりました Dynamic OG-Tags in your statically Firebase hosted (Polymer) web app 先程Firebaseすげぇ！で出てきたCloud Functions for FirebaseとHostingのトリガー機能を使います。

1. Hostingでは、特定のURLに来たアクセスをトリガーとして関数名を指定してCloud Functions for Firebaseを動かせます。 つまり今回はセッション情報ページにアクセスきたらってことですね。
2. Cloud Functions for Firebaseに →もしクローラーなら：OGPしか書いてないHTMLを作って返す。 →もしそれ以外のユーザーなら：スルーしてURL通りのページを見せる。という関数を書いておき、先程のHostingのトリガーにこの関数を指定すればめでたしめでたし。

ただし、2の「普通のユーザーにはURL通りのページを見せる」が厄介でした。 Hostingで「このURLに来たら」というルールを書いてるので、単純にリダイレクトでそのURLに送ったのでは無限ループしてしまいます。 そこでnode-fetchをつかうんですね。 こいつでルートのindex.html（今回で言うhttps://sessiongo.com/index.html）を取ってきて、その内容をユーザーに返すというものですね。 SPAの仕様というと語弊があるかもしれませんが、「ルートのhtmlを見ていても、パスに対応したjsが読まれていればちゃんとそのページに変身する」という、まぁ魔法みたいなアレですね。よく分かってません。 とにかくこれでHostingのルールをうまいことかわせます。   上辺だけなめた感じの投稿ですが、これからは運用という史上最強のあいつが待ってます。 が、Firebaseのおかげでフロント部分だけに注力できるのでもう怖いものなしですね。 Firebase万歳！Google万歳！ワンワン！