ウェブサービス運営者同士でワイワイするサービス「Admin Guild」を作りました！

どうもDiver Down LLC.のen30です。

web1weekで楽しそうにしている人たちを見ていたら気持ちが盛り上がってしまい だーすー と Admin Guildというサービスを作りました。

https://admin-guild.com

どんなサービス？

ウェブサービス運営者同士でGoogle Analyticsのデータを見てワイワイできる（予定）のサービスです！
お気に入りした(Like)サービスをウォッチしたりもできます。

いまのところ運営者ギルドのSlackメンバー限定で登録出来るようになっています。

まだ機能としては
- Slackログイン
- Google Analytics連携でサービス登録
- バックグラウンドでリアルタイムユーザ数を取得してランキング

程度しかなく、なんとかインターネット上にURLを公開するところまでやって終了時間まで滑り込んだ、という感じですがこれから諸々実装していきます。

どんなものを使ったか

僕は普段は主にRailsで開発しています。web1weekでは短期間で小さなサービスを作ることになるので、技術検証も兼ねて個人的にはかなり攻め気味の技術を選んでみました。（その結果まるで間に合いませんでしたが！）
なぜ選んだのかは書いていたら長くなってしまったので記事最後のおまけに回しました。

• TypeScript
• Next.js
• React Native for Web（Expo）
• Firebase
  • Authentication
  • Functions
  • Firestore
• Google App Engine

ハマったところ

@expo/next-adapter だとサーバサイドでも環境変数が使えない

Next.jsとExpoの連携には
Using Next.js with Expo for Web - Expo Documentation
を参考に @expo/next-adapter を利用しました。

@expo/next-adapter を使うと process.env が書き換えられてしまい、 getServersideProps 内などサーバサイドでも環境変数を自由に使うことができません。

Expoは基本クライアントのためのビルドをするものだと思うので、わからないでもないですがNext.jsと組み合わせて使う上ではちょっとつらいです。

とりあえずIssueをたてておきました
- With @expo/next-adapter, process.env is not available even on server side. · Issue #2156 · expo/expo-cli

いまのところ、サーバサイドで外部から何かを渡したいなら環境変数ではない方法で渡す必要があります。
今回はApp Engineに置いてGCPのSecret Managerを利用しました。

Firebase Authenticationではrefresh_tokenがとれない

サービスの性質上、ユーザがサービス上にいなくても定期的にGoogle Analytics APIで情報を取得したいです。ですがFirebase Authenticationだと refresh_token が取ません。

なので
- Google Sign-In for Websites で refresh_token も取得
- Firebaes Authentication の firebase.auth().linkWithCredential()

と組み合わせることで対応しました。

参考

• Firebase Google Auth offline access_type in order to get a token refresh - Stack Overflow
• How to get refresh token for google api using Firebase authentication - Stack Overflow

感想

最近あまり新しいサービスを出せていなかったし、締め切りありの短期間でウォー！！！！と開発するのが楽しかったです。

楽しい企画をありがとうございました。

おまけ

技術検証の意図

Railsは少人数で最速でウェブサービスを立ち上げるには本当に良いフレームワークだと思っています。マシュマロではTurbolinks + StimulusというRails wayど真ん中の選定をしました。開発速度という意味ではいい選択だっと思っています。

とはいえ、触れる情報、環境の変化で
『Railsは次に作るサービスでも良い選択肢だろうか』
というのに少し迷いがでてきました。

マネージドサービスを組み合わせて作るサービス

いままで主にVPSを使ってましたが、最近はGCPにも結構触っています。
少人数（いまのところ一人）で開発していく上では、運用に時間的コストを払っていると全然回らないなという課題があります。
マネージドサービスの

• 自分での運用が必要な部分を減らしていける
• スケーラビリティのことをあまり気にしなくて良い
• セキュリティ周りのアップデートもサービス側がやってくれる部分が結構ある

というのは大きな魅力です。

Railsを使っているからスケールしないというようなことは、とんでもない規模になってもなかなか無いと思います。ただ、今Sidekiqを使っている場面でCloud Tasks, PubSub + Cloud Functionsを選んだり、サービスをうまく組み合わせて作ることで、もっと運用で考えることを減らせるのでは？という選択肢が見えてきました。

もちろんRailsとそういうサービスを組み合わせていくことも出来るわけですが、どう組み合わせていくかを考えていく必要があります。もしそちらの方向に舵を切っていくならRailsである意味があまり無くなってしまうかもれしれないと感じてきました。

React周辺の進歩へのキャッチアップ

Railsの中心にはHTMLがあります。一方JavaScript中心の世界もあり、進歩が目覚ましいです。目覚ましすぎてどうにも隣の芝が青く見えてきました。

以前アプリ☆メーカーを書き換えるのにReactを使いました。それなりに早い段階での採用だったので自分で考えなければいけない部分があまりにも多くなってしまいました。webpackのconfigは？ルーティングは？状態管理どうする？SSRは？等。その結果、一人で開発するのでは全然開発速度がでない、品質も低い、変化も早くメンテナンスコストも高い、という失敗をしてしまいました。その失敗から、インタラクティブであることに高い価値があるサービスだったり、開発チームが大きいのでなければ全然コスパが良くないなという印象でした。

なので、しばらくは距離を起きつつ横目にちらちらと進歩を見ていたのですが、最近の動きを見ていて、ここらでもう一度手を動かして触ってみたいなと思ってきました。

ネイティブアプリへの展開

これから作るサービスで、ネイティブアプリ展開もあるかもしれないなと考えているものがあります。

RailsをAPIサーバにして、WebのフロントにReactやVueを使うという選択肢はありますが僕はそういう使い方はHTML中心であるRailsの良さの半分を捨てることになるので、微妙かなと考えています。それならNext.jsの方がきれいに見えます。

Web寄りの自分を含む少人数で、Webもネイティブアプリもカバーしたいと考えたとき、React Nativeが魅力的に見えます。React Nativは軽く触った印象、style周りも標準のコンポーネントも結構いい感じだなと思っているので、React Native for WebでのWeb開発はどんな感じなのか、というのを試してみたいと思ってきました。

使ってみての雑感

まだ開発が進んでいなさすぎてなんとも言い難いですが、それぞれの印象。

• TypeScript
  • Stimulusと組み合わせても普段から一応使っているので、特に新たに受けた印象はありませんが、静的型付け言語は楽だなと思う場面は多いです。今回使ったものはどれも型定義が簡単に使えるようになっていたので、メリットは大きかったと思います。
• Next.js
  • きれいにデザインされていて好きです
    • ビルド, SSG, SSR等の設定を自分でしないで使える
      • get*Props でうまいことやってくれるのも
    • ファイルの構造 = ルーティングの構造というのもReact Routerみたいなものより好き
  • Slackのcallback等、サーバサイドの処理をどこに書くべきか迷う部分がありました。 /api か getServersideProps か、今回はCloud Functionsもあり。
  • Next.js アプリ自体をどこに置くかも少し迷いました。Cloud Functions自体に入れてしまうという選択肢もあったり。とりあえず考える時間もなかったのでGAEに置きました。
• React Native for Web（Expo）
  • 大体React Native通りに使えるのだなというのがわかり好印象です
  • 今回使えたのはWebのみだったので、クロスプラットフォームで使おうと思ったときに出てくるつらみがあるのかどうかが気になります
  • 普通のWeb開発に比べると、UI用のライブラリの選択肢が少なく楽をしづらい部分はあると思います
    • 今回はUI Kittenというライブラリを使いました。見た目はきれいだしコンポーネントも豊富、ドキュメントも結構整備されてます。ただ、ReactっぽくないAPIで微妙に人には勧めづらい印象でした。
• Firebase
  • 元々たまに触ったりしていて好きですが、より便利になっていっていますね。Local Emulator便利。

どれも使ってみて結構良いものだなと思いましたが、やはりRailsと比べると重要でない決断をかなり多くの場面でしないといけないようには感じます。学びながらなので比較しづらいですが、WebだけであればRailsの方が結構開発速度がでそうかなという印象です。

これから

ネイティブアプリへの展開までRails（Basecamp） wayに乗っかるのなら、HTMLを中心に起きつつもネイティブアプリもつくる
turbolinks/turbolinks-iosみたいな方向もあります。こちらでどの程度のものが作れるのかが気になってきました。

特に開発中のHeyは最初からネイティブアプリありでスタートするとのことなので、その方向でDHH, Basecampが何か新しい道を示してくれたりするのだろうかと少し期待しています。

また、Railsを使っていると最高に便利なのはActiveRecordで、他の選択肢でも同じような生産性が出せるのかというのは結構大きな懸念点です。Prismaや、Hasuraあたりも試してみたいところでしたが開発時間的に全然そこまでいけませんでした。

ひとまずは好印象なのでもう少し開発を進めつつ、RDB周りはどうかというのも探っていきたいと思います。