スタートアップで新規開発プロジェクトの技術選定をした話
はじめに
今年の5月にとあるプロダクトの新規開発プロジェクトにバックエンドを担当するエンジニアとして参画し、そこで幸運にも、フロントエンド、バックエンド、インフラの技術選定に携わることができました。僕くらいの年次のエンジニアが商用プロダクトの技術選定に携わることはあまりなく、需要がありそうな話ので記事にしました。
チームの構成
ビジネスサイドが１名、エンジニアはフロントエンド/UIデザイン1名、ブロックチェーンを担当するエンジニアが1名、バックエンド/インフラを担当するエンジニアが1名（自分）という構成です。
プロダクトの概要
Web3の技術を用いたC向けのサービス（Web）です。
参画の経緯
偶然Twitterのタイムラインに現れた
「ブロックチェーン関連の新規プロダクト開発するのでエンジニア募集！」
の投稿。
当時とにかく新規開発したい！と考えていた僕は、即DMで応募しました。
フロントエンドエンジニアの採用は先に決まっていたため、バックエンドを担当するエンジニアとして採用されることになりました。
技術選定
前述の通り、バックエンドを担当するエンジニアとして参画したわけですが、当時やる気に満ち溢れすぎていたために、
フロントもバックエンドもインフラも全部やったる🔥🔥
という意識の高さを発揮し、満を持して（？）、技術選定を担当することになるわけです。
- フロントエンドを担当するエンジニアがほぼフロントエンド未経験だった😇
- メンバーの中では相対的に自分の稼働時間が大きいほうだった⏳
などの理由もあったりはします。まあでもやりたかっただけですねｗ
フロントエンド
僕がジョインした段階で「Vueを使う」というところまでは話が進んでいました。おそらく、
- 他のプロダクトでVueが使われており、リソースを利用できる可能性があったこと
なんかが理由かなと推測しています（今度詳しく聞いてみます）
とはいえ、Vueといっても、
-
Vue.extendを用いる従来型のスタイル
-
デコレータを用いたClassコンポーネントスタイル
-
Composition APIを用いる新しいスタイル
と書き方は三様ですので、どれを採用すべきかが議論になります。
TypeScriptの導入もマストだと考えていた私は、どのような形でVue.js with TypeScriptを実現すべきか模索していました。
①, ②の環境でVuejs with TypeSciprtを経験し、DX（Developer eXperience）の悪さを実感していた私は、③の採用を決めました。
ただ、後々フロントを担当するA君から話を聞く限り、Composition APIについては、
- 情報が少ない
- 従来型のVueと書き味もかなり異なる
- 学習コスト高め
と難点もあるみたいなので、そこの選定は反省ポイントです。
そもそも、Next.js with TypeSciprtのDXの良さを考えると、素直にそっちを採用しておけばよかった、という話もありますｗ
バックエンド
バックエンドはNode.jsを使うというところまでは決まっていました。
- フロントでWeb3を用いるため、都合がよさそう
- 必要なパッケージがnpmで提供されている
などが主な理由でしょうか。
- フロントエンドと型を共有したかった
- 個人的にバックエンドTypeScriptを使ってみたかった
ので自分としても満足でしたね。
フレームワークについては、当初はExpressを使う予定でしたが、Nest.jsの存在を知り、そちらに決めました。
理由としては、Expressを単体で用いるよりも、Nest.jsの提供する規約や機能に乗っかってしまった方が楽で早いと考えたからです。実際、後述するPrismaと合わせて使うことで、かなりRailsなんかと近い体験になります。Nest.jsが認証やバリデーションなどの機能を提供してくれていたおかげで、DX高く開発が進められました。
ORMについては、TypeORMやSequelizeなどいくつか選択肢があるなかで、Prismaを選定しました。
- TypeScriptライクな仕様
- ドキュメントが読みやすい
- Prisma Studioなど開発補助ツールが豊富
など、総合的に考えて、DXが高いと判断しました。
また、今回OpenAPI（Swagger）を用いた型の自動生成なんかにもチャレンジしたのですが、GraphQLなんかを採用してしまったほうが早かったかもしれません。
インフラ
↑まさにこんな感じで「何事も経験だ！」と自ら手を挙げたものの、アーキテクチャの設計はもちろん、商用プロダクトのインフラを触ったことすらほぼありませんでした。AWSのマネジメントコンソール上からポチポチとログを見たりしたことがあるくらいでしょうか。さらに当時の私は、
「時代はInfrastructure as Codeや！！」
とインフラのコード化にも挑戦し、Terraformと迷いましたが、当時AWSモチベの高かった私はCloudFormationを選択しました。
DevelopersIOを読み漁ったり、AWS公式のドキュメントを読んだりと試行錯誤した結果、Cloudflare, ELB, ECS(Fargate), RDSあたりを使った比較的モダンな構成を実現することができました。
ステージングにデプロイできたときは感動しました。。。
ちなみに、CI/CDにはGithub Actionsを採用しています。現状ではAWS CLIで各種コマンドを実行するシェルを書いてそれをワークフロー上で実行する、というスタイルを取っているので、もう少しうまい具合にできないかと模索中です。
おわりに
ベストな選定ができているかというとそんなことは全くないのですが、今後技術選定をする機会があればもっとうまい具合にできるかなという手応えは感じられました。お読みいただきありがとうございました。
Discussion