🍇

仮想オンライン作業スペースを作った [オンライン作業部屋]

2021/07/27に公開

Firebase

こんにちは、そららいどです。

今回はじめて、個人的に開発したWebサービス「オンライン作業部屋」をリリースしましたので紹介したいと思います。

リンク

オンライン作業部屋とは？

オンライン上の仮想的な作業部屋というコンセプトです。

仕組みはシンプルで、好きな科目と座席を選び、ボタンを押して入室・退室するだけです。

部屋を選ぶ画面

座席を選ぶ画面

部屋にいる間は、同じ部屋にいる他のユーザーの名前が見られます。

Googleアカウントを持っている方は誰でもログインできるため、新しく登録する手間はかかりません。

なぜ作ったか

在宅で仕事や勉強をする必要が出てきた
家じゃ集中できねぇ
図書館や自習室に行きたいけど閉まってる、、、

という背景から、オンラインで他の人と一緒にもくもくと作業に集中したりして交流できるようなサービスを作りたいと考えました。

特徴

YouTubeで24時間ライブ配信

このサービスの唯一の大きな特徴として、オンライン作業部屋の入室状況が常にYouTubeでライブ配信されています。
配信のチャットで入退室するユーザーのログを見ることができます。

使用したサービス・ツール・言語など

バックエンド


言語	Go
データ管理	Cloud Firestore
処理	Cloud Functions, AWS Lambda
APIエンドポイント	AWS API Gateway (HTTP API)
ユーザー認証・管理	Firebase Auth

バックエンドのAPIのメイン処理は基本的にAWS Lambdaで行っていますが、Firestoreのデータ変更やFirebase Authのユーザー登録などのトリガーで処理を実行する必要があるプログラムのみ、Cloud Functionsで実装しています。

フロントエンド


言語	JavaScript, HTML, CSS
Webサイトの種類	SPA (Single Page Application)
JavaScriptフレームワーク	Nuxt.js (2.x系)
UIフレームワーク	Vuetify + Material Design Icon

モバイルアプリ


言語	Dart
フレームワーク	Flutter

iOS・Android向けアプリをFlutterにて開発中です。

その他


ソース管理	Github
サービスロゴ・アイコン作成	Adobe Illustlator
APIテスト	Postman

開発環境

	Mac	Windows
OS	Mac OS Catalina	Windows 10
メモリ	16GB	16GB
ストレージ	SSD 256GB	SSD 512GB
IDE	WebStorm, GoLand	WebStorm, GoLand

開発中のあれこれ

Cloud Functionsのデプロイがおせえ...

はじめのうちは、純粋なGoogle Cloudのプロジェクトとして開発を進めるつもりだったのですが、Cloud Functionsのデプロイが死ぬほど遅く（１つの関数ごとに２分）、しかも関数をまとめてデプロイできない仕様だったため、「デバッグしづれぇ」ということで、さらにプロジェクトが凍結されたということもあり（後述）、Cloud Functionsの処理の大部分をAWS Lambdaに移植しなおしました。

Google Cloudのプロジェクトが凍結された

開発中もGithubのリポジトリを公開していたのですが、なんとGoogle CloudのプロジェクトのCredential情報が書かれたjsonファイルも紛れており（ダウンロードするときに取り扱いに気をつけるよう注意されるやつ）、案の定暗号通貨マイニングに悪用されて、知らないうちに新しいVMインスタンスが作られて動いてました。。。
実は、こうなる直前にGoogleから警告メールが来ていたのですが、私が行ったのはその時のリポジトリからファイルを削除するだけの不十分な処置で、Githubのblobのブランチでは引き続き公開されていたのです😱

最初は凍結解除された

プロジェクトが凍結されると、コンソールにログインしても「Request an appeal」の画面しか見られません。
一度目は、早急に該当のceredential keyを削除することを約束するという内容のappealが受理され、無事にプロジェクトが復活することができました。

二度目はなかった

が、IAM関連の設定が混沌としており（私が仕組みをよく理解していなかっただけ）、該当keyの情報を削除するのを忘れていたせいか（真実を確認するにも今は凍結中のため確認できず）、またもや凍結。
今度は「設定項目やデータベースのバックアップを取ったらすぐにプロジェクト消します」という内容でappealしましたが残念ながら通りませんでした😭

そもそもなぜAWSではなくFirebase(Google Cloud)を選んだのか

私は特にこれらのサービスに詳しいというわけではないですが、ざっと調べたり、これまでちょこっとそれぞれのサービスを触った経験から、次のような理由でGoogle Cloudを使うことにしました。

ドキュメントが読みやすい

Firebaseに限らず、Googleの開発系ドキュメントは読みやすいフォーマットに統一されていています。
AWSもフォーマットは統一されていますが、やたら詳しすぎる感じで、しかも_文章にでてくる語句が初心者の私には特に難しく_、何度読んでも理解すらできず、結局ぐぐって第三者の記事を読むほうがわかりやすいということがよくありました。

コンソールや機能群がシンプル

Google CloudとAWSはどちらも豊富なサービスを提供していますが、AWSのほうがより多くのサービスが乱立していて複雑な印象が強かったです。
特にIAMのユーザー・ロール管理がちんぷんかんぷんで嫌でした（後にGoogle CloudのIAMで苦しむことになる..）。
あとは、単純にGoogle Cloudのコンソール画面のUIが好きでした。

FirestoreからDynamoDBに乗り換え？

Cloud FunctionsからAWS Lambdaにバックエンド処理を移行するにあたり、せっかくLambdaを使うのだし、AWSの経験もできるだけ積もうということでDynamoDB（Firestoreと同じNo SQL）でデータを管理しようと思ったのですが、この時点でそこそこ手間をかけてFirestoreの手続きのGoコードを書いてたので、それを書き直す気にはなれませんでした。
それよりも、ここでDynamoDBの学習にリソースを持ってかれてプロジェクトの進捗が遅くなり、モチベーションの低下にも悪影響を及ぼす恐れがあったため、DynamoDBの採用は諦めました。

ということで、Lambdaに移植するために必要最低限のコードの記述の変更とAPI Gateway関連の設定のみを行い、引き続きデータはFirestoreを利用することになりました。Google Cloudのプロジェクトは新しく作り直しました。

なんでNuxt.js (Vue.js)？

学習コストが低いということで、React.jsやその他のフレームワーク・ライブラリではなくVue.jsを学びました。最初は素のVue.jsのCDN版を使ったりしていましたが、今回はNuxt.jsで開発を行い、その使いやすさを実感しています。

しかし、時代はNext.jsということで、これから余裕があったらReactのNext.jsもやりたいと考えてはいます。

開発を振り返って

とりあえずそれっぽいシステムを作ることができたのでうれしいです。
Go言語好き。
WEB開発に関する基本的なプログラミングスキルが全体的に向上しました！（体感）
ポートフォリオにのせるためGitHubでリポジトリを公開する必要があるのですが、公開してはいけないファイル・情報の取り扱いを学べました。

GitHubで編集を提案