らぼるてっく。

てっくてっく歩いてっく。

Nuxtで受付システムを内製化しAWS Amplifyにデプロイしました!

はじめに

ラボルのフロントエンドエンジニアの寺岡です。

最近、ラボルで受付システムを自社開発しました。
オフィスの受付でよく見る、来訪者がタブレットで社員を呼ぶやつですね。

このアプリケーションをNuxt × Amplifyの技術を使い、ほぼフロントエンドのみの技術で、実装からリリースまで行ったので、今回はその経緯の共有記事となります。

主に、以下の方に向けた記事となっております!

  • フロントエンド完結で、アプリケーションをデプロイする方法を知りたい方
  • ラボルの開発者は、何を考えて解決策を講じているかを知りたい方
  • 開発者にとって、ラボルはどのような環境かを知りたい方

目次

内製化に至った経緯

ラボルは9月中旬にオフィス移転を行い、その際に新しく受付システムの導入が必要となりました。
既製品だと、導入のコストが高い・要件に対してオーバースペックというデメリットがありました。

そこで、要件的には低開発工数で実装可能なので、自社開発で進めることになりました。

要件

  • ラボル社員の検索
  • 来訪者情報の入力
  • Slack通知
  • 来訪ログ記録

課題

  • セキュリティ(IPアクセス制限)
  • ホスティング
  • ランニングコスト

解決方法

全部フロントエンドで解決できるじゃん!

上記の要件・課題は、全てフロントだけで解決できると判断しました!

  • 社員の検索・来訪者の入力機能 → Nuxt(SSR)
  • Slack通知 → Slack API
  • 来訪ログ記録 → AWS CloudWatch Logs
  • セキュリティ(IPアクセス制限) → Nuxtで制限
  • ホスティング → AWS Amplify

ラボルでは、各種プロダクトにNuxtを採用しており知見もあったため、今回の受付システムでもNuxtが採用候補に挙がりました。

SSRとSPA

ラボルの各種プロダクトのNuxtは基本的にSPAを採用しています。
今回の受付システムでは、セキュリティなどの課題を解決するために、SSRを採用しました。

※社員データはDBに保持しても良いですが、頻繁に社員が変わるわけでもないので、バックエンドコードに保持させる形を取ってます。

ランニングコスト

ランニングコストに関しても、以下の通りです。
定期的にコードのcommitがあり、Amplifyでビルド&デプロイすることを考えると、約1000円/月の想定(利用例参照)ですが、
実際は、今のところビルド&デプロイがほぼないので、現状$1以下です。

  • 某 既製品の場合: 約30,000円/月
  • 自社開発の場合: 約1,000円/月

Amplify 利用例

実装とリリース

Amplify設定

Amplifyの設定としては、以下の手順です。

  1. GitHubやGitLabなどのサービスを選択します。

  1. リポジトリを選択し、次に対象ブランチ(mainやmaster)を選択します。

  1. アプリケーションの名前を決め、ビルド方法の設定をします。
    フレームワークがNuxtであることを検知してくれて、ビルドコマンドはnpm run buildが自動設定されました。

  1. 内容を確認し、デプロイを実行します。

リリース方法

対象ブランチにmergeすると、自動デプロイしてくれます。

フロントエンドの技術検証

また、今回はフロント完結のプロジェクトということで、ラボルのフロントエンドチームで課題となっていた設計(コンポーネントやCSSなど)の検証を行うことになりました。

試してみたい設計手法で実装し、コードレビューで議論する、という検証フローも実施できました。

▼プルリクエストでの議論の様子

成果と学び

内製化

内製化したメリットとして、やはり上記のようにランニングコストが大幅に抑えられた点です。
開発工数以降は、ビルドやデプロイがほとんどないので、実質$1以下で済んでます。

  • 某 既製品の場合: 約30,000円/月
  • 自社開発の場合: 約1,000円/月

また、内製化なので当然ですが、コードやUIの改修を自由に行えることもメリットです。
今後は、運用中に発生した問題や改修案を、フロント完結ですぐに対応可能です。

運用

来客があった際、以下画像のように、Slackのチャンネルにメンション付きで通知が来ます。
対応済みの来客通知にはリアクションを付けることで、対応状況を他の社員がわかる運用にしました。

フロントエンドの設計

本プロジェクトで設計手法を試した結果、ラボルサービスの方でも、以下のディレクトリ構成でリファクタリングしようという話になりました。

  • 機能について関心がない、どこでも使用可能なcomponent(例: Headerなど) → /components
  • 機能について関心がある、限定的なcomponent(例: 社員検索formなど) → /features

に分け、さらにfeatures配下はページごとの機能で分かれる、といった構成です。

これにより開発者が探したいファイルがどのディレクトリに置かれているかが一目瞭然というメリットがあります。
例えば「社員検索ページに表示するリストUI component」が/features/search-member/components/...に置かれていることがわかります。

本プロジェクト程度の機能数であれば、正直オーバースペックな構成なのですが、ラボルサービスは機能数がとても多く、上記のメリットを存分に感じられると想定しました。

.
├ /components // 関心がない共通component(headerなど)
├ /features // 関心がある機能(ページごとで使う機能)
│ ├ /common // 関心があるが、どこでも使える機能
│ ├ /search-member // 社員検索機能
│ └ /visitor-input // 来訪者情報入力機能
├ /pages // ルーティング
│ ├ /search-member // 社員検索ページ
│ ├ /visitor-input // 来訪者情報入力ページ
│ └ index.vue // トップページ
└ server // APIハンドラなど
  └ /api

他にもCSS設計なども話したいのですが、本記事の内容から脱線してしまうのでここまでにしておきます。

おわりに

今回は、フロントエンド完結で、アプリケーションをデプロイできるNuxt × Amplifyの紹介をしました。

  • フロントエンド完結で、アプリケーションをデプロイする方法を知りたい方

デプロイ方法は、Amplifyでリポジトリ・ブランチ・ビルドコマンドを指定するだけで、簡単に実現できることがわかりました。

  • ラボルの開発者は、何を考えて解決策を講じているかを知りたい方

ラボルの開発者は、今回の解決策の考え方のように、すぐに思いつくような解決策に飛び付かず、チーム全体で目的と現状を考えて最適解を目指しています。

  • 開発者にとって、ラボルはどのような環境かを知りたい方

今回の対応でフロントエンドでも、バックエンドやリリースに十分関わることができる技術に触れることが出来ました。
ラボルでは、必要な技術を必要な時に試せる・挑戦できる環境があります。

技術的な視点にもビジネス的な視点(目的は何か、コストはどうか)にも熱量持って働きたい方は、是非選考に応募してみてください!

ラボルでは、現在フロントエンドも2024年下期、絶賛募集中です!
※2024年10月8日 更新
labol.co.jp