ResilireのWebフロントエンドのコードベースと設計をチラ見せ紹介するよ! | Resilire Tech Blog
サプライチェーンマネジメント SaaS のフロントエンドテックリード採用中です!
サプライチェーンリスク管理クラウドサービスResilireに技術アドバイザーとして参画している @ahomu でございます。見出しのとおり採用のための参考情報を兼ねた記事です。
今回はResilireのWebフロントエンド環境がどのようになっているかを紹介がてら現状をブログにまとめてみました。私が手がけたわけではないので、ここまで基盤を整えてきた方にインタビューをしながらお送りしています 💁
プロダクトの概要
サプライチェーンというとフロントエンド周りだとnpmのサプライチェーン攻撃を思い浮かべる各位もおられると思いますが、Resilireがスコープとしているのは物理的なグローバルサプライチェーン、原料調達、製造、輸送の最前線です。
現在の主要機能はサプライチェーンにおけるサプライヤー情報の一元管理と可視化、リスク情報の自動検知と同報送信による状況把握の円滑化です。
現在のステータス
これまではPoCの延長線上にあるファーストプロダクトによってサプライチェーンマネジメントSaaSが提供すべき価値を検証してきました。
検証の中でシステムとして実現すべき像が明確になり今後の価値提供のために最適な設計、実装が一定見えてきたため、それらを反映すべくゼロベースのシステム刷新が行われたところです。
設計コンセプトと技術スタック
サプライチェーン自体がグローバルなものであることからグローバル展開を前提とした開発が求められ、サプライチェーンのリスクに備えるための機能を提供していることから高品質かつ堅牢なシステムの実現を目指しています。
フロントエンドとデザインの観点では、長大なサプライチェーンやリアルタイムに更新されるリスク情報などさまざまな大規模データを直感的に理解するためのインタラクティブなUIもポイントです。データやユースケースに合わせた使い勝手の良いUIを提供する必要があり、エンタープライズユースをターゲットにしているからこそユーザーに対する緻密な配慮が求められます。
Single Page Application —— Vite + React
Resilireはユーザーがログインして利用するtoB SaaSであり、本体Webアプリケーション自体に公開ページは含まれないのでOGPの配信やWeb Vitalsの最適化を放念できます。
それを踏まえ以下のような観点でViteを利用してビルドする純粋なシングルページアプリケーション構成が選択されています。
- 静的ファイルの配信なのでWebの各種インフラコストが軽くなる
- 静的ファイルをビルドして配置するだけなのでデプロイがシンプルになる
- SSR + SPAが抱えるサーバー・クライアントの境界に依る複雑性を避けられる
- Webアプリケーションサーバー起因の潜在的な障害の可能性を回避できる
Next.jsのような重厚なフレームワークの採用は見送っており、今の時点では自分たちでコントロール可能な要素技術の組み合わせによるコードベースを志向しています。
開発中リポジトリから抜粋したdependenciesをご覧いただくと意思決定の傾向を読み取って頂けると思います。
{
"dependencies": {
"@auth0/auth0-react": " ",
"@generouted/react-router": " ",
"@hookform/resolvers": " ",
"@sentry/react": " ",
"@sentry/vite-plugin": " ",
"@tanstack/react-query": " ",
"i18next": " ",
"query-string": " ",
"react": " ",
"react-dom": " ",
"react-hook-form": " ",
"react-i18next": " ",
"react-router-dom": " ",
"ts-pattern": " ",
"zod": " ",
"zod-i18n-map": " "
},
"devDependencies": {
"@faker-js/faker": " ",
"@storybook/react": " ",
"cypress": " ",
"eslint": " ",
"jsdom": " ",
"msw": " ",
"orval": " ",
"typescript": " ",
"vite": " ",
"vitest": " "
}
}
Monorepo —— turborepo + pnpm
サプライチェーンマネジメント関連のあらゆる機能の展開、価値提供を進めていく中でさまざまなアプリケーションやコンポーネントを水平展開することが予想されています。コードーベースの規模が拡大しても一定の見通しが担保されている状態が望ましいでしょう。
それを実現するためにディレクトリ構造は t3-oss/create-t3-turbo または turbo/examples/basic の流れを汲み turborepo と pnpm workspace を利用したmonorepo構成になっています。
- モジュール毎にpackage化することによって、アプリケーション内をシンプルに保てる
- インターナルパッケージによる依存管理によってアプリケーション間の再利用性の向上を期待できる
- appsとpackages以下を見れば、構成部品の所在がおおよそ推測できるので開発・レビュー効率の向上が期待できる
上に挙げたメリットが早速発揮されている例として、8月の下旬に新しくジョインしたメンバーも短い時間でアプリケーションの構造をキャッチアップして機能開発に取りかかることができています。
.
├── apps
│ ├── storybook # Storybook
│ └── vite # アプリケーション
└── packages
├── auth # 認証関連
├── config # tsconfig / eslint
├── icon # アイコン
├── locales # 多言語化向けの辞書
├── map # マップ機能のUIコンポーネント
├── scm # ツリー機能のUIコンポーネント
├── test-utils # テストユーティリティ
└── ui # 共通UIコンポーネント
今後の展望
個人ブログ記事 でも紹介しましたがResilireのプロダクトはフロントエンド的にもチャレンジポイントが多いので、ぜひ多くの方に知っていただきたいところです。
- 高品質で堅牢なサービス開発が事業価値に直結する
- スケーラブルなシステムを支えるスケーラブルなUIの水平展開が求められる
- 堅牢+モダンな技術基盤でプロダクトの価値提供に集中できる
今回ご紹介したように技術スタックの方向性は一定見えてきたものの、開発すべき機能や提供すべき価値は今まさにこれから始まる0 → 1に近いフェーズです。
まずはResilireに興味をもってくださった方のご参考になれば幸いです!
ということでソフトウェアエンジニア採用を絶賛強化中なので、興味を持った方は下記からぜひどうぞ!
Product & Technologyの紹介資料もどうぞ。
おすすめ記事
Resilireの物づくりをもっと知りたい方はこちらの記事もおすすめです 💁
Discussion