フロントエンドとバックエンドの両面TypeScriptを採用して感じたメリット・デメリット
概要
こんにちは。バックエンドエンジニアのfuです。
みなさんはどの言語が好きでしょうか？
私はバックエンドエンジニアなんですが、フロントエンドの開発に入ることが多いことと型による開発効率向上を強く感じていることもあってTypeScriptが一番好きです。
そこで、実際に業務でフロントエンドとバックエンドの両面TypeScriptを採用して2年弱プロダクトを運用してみて感じたメリット・デメリットを記述しておこうと思います。
両面TypeScriptを採用しようか悩んでる方の参考になれば幸いです🙇
ただ、技術選定は単純にメリット・デメリットだけではなくプロダクトの特性やメンバーの技術スタック、他のプロダクトの採用言語も加味した上で行うべきだと考えていますのでTypeScriptをゴリ押しするつもりはありません🙋♂️
メリット
まずはメリットからあげていきます。
TypeScriptが好きなので若干色眼鏡はあるかもしれませんがご容赦ください。
フロントもバックも開発する場合に言語による頭の切り替えが必要ない
フロントはTypeScriptでバックはRubyで書かれているようなプロダクトでバックもフロントも開発する場合、以下のようなことがしばしば起こります。
- Arrayを扱うときにフロントではfind使えたけどバックは同じことするときどう書いたらいいか分からなくなる。
- 変数宣言の仕方や作法がごっちゃになる。
- 型がないことで無性に不安になる。
どちらかの専任ならあまり関係ないですが、やはり言語が切り替わると仕組みや作法が変わるため余計な負荷がかかってしまうなと感じます。
言語が統一されているとそういったことを全く意識しなくてよくなるのでその分コーディングに専念できると考えています。
フロントエンドエンジニアの豊富な知見を吸収できる
こちらは特に私がメリットと感じているところです。
フロントエンドエンジニアの多くの方はJavaScriptを長年使ってきており、知見も豊富で様々なノウハウを持っています。
バックエンドをTypeScriptで書いていて、フロントエンドエンジニアの方にレビューしてもらう機会も多々あるのですが、バックエンドとは少し違った視点や熟練の技を教えて頂けて自身の大きなスキルアップに繋がりました。
より広い視野を持ってコードを見ることができるようになると思います。
フロントエンドエンジニアとバックエンドエンジニアが相互にレビューしやすい
こちらは少人数の組織で特にメリットになると考えています。（フロントとバックの担当を完全に分けていたら特に関係なし）
フロントエンドとバックエンドの言語が異なると、どうしても自分が主担当じゃない側のコードは仕組みや作法が理解しきれていないところが多く、レビューの質も下がってしまいます。
しかし、言語が統一されることによって記述法の観点でお互いに質の高いレビューが行えることはもちろん、それによりコードの意図も理解しやすくなりロジック部分についてもより的確に指摘ができると考えています。
モノレポとの相性がいい
両面TypeScriptにするとモノレポの力を十二分に発揮することができ、例えば以下のようなメリットがあります。
- nxなどのモノレポライブラリを使ってまとめて管理できる
- 型やfunctionを共有することもできる
- package.jsonやeslintも共有でき、ライブラリの管理やフォーマットの設定も共通で行える
私は実際にnxを用いてモノレポで構成しているプロダクトとポリレポで構成しているプロダクトの両方を経験しましたが、モノレポだとライブラリの管理が楽だったのと、型などを検索した際にフロントとバックをまたいで認知負荷なくすぐに見つけられるのは地味に便利でした。
eslintの設定などはモノレポじゃなくても使い回すことによって開発の効率を上げられので助かります😁
JavaScriptを触ったことがある人は多く参入障壁が低い
私自身採用にも関わっているので人材確保の観点ですが、TypeScriptでバックエンドの開発をしたことなくてもJavaScript（もしくはTypeScript）を触ったことある人は多いですよね。
また、FWも近年よく耳にするExpressやNestJSってRailsとかに比べると独自のルールは少なくて参入障壁は低いのではないかと感じています。（私の主観も入っているのでちゃんと使って確認してみることをお勧めします）
昨今は人材確保が難しいので、経験が浅いエンジニアでも習得しやすいというのは嬉しいですね。
デメリット
続いてデメリットです。
忖度がないように率直な意見を述べていきます。
処理速度が速いわけではない
こちらはあくまでRustやGoに比べるとですが、JavaScriptはシングルスレッドで実行され処理速度は速い訳ではありません。
ただ、遅すぎて使い物にならないという訳ではないため処理速度が重要なシステムでなければそこまで問題はないと考えています。
情報量が少ない（かも）
バックエンドのTypeScriptはRubyやphpに比べるとどうしてもエンジニアの母数が少ないため情報量も少ないと感じています。
簡単なアプリケーションを作る分には問題ないですが、テクニカルなことをしようと思うとなかなかたどり着けないことがしばしばありました。
それでもTypeScript自体の知名度は高く、フロントエンドの情報量が豊富でライブラリの使い方などの記事はよく見つかるため、心配するほどではないと思っています🙋
FW・ORM・アーキテクチャなどの選定に悩む
これは個人的な感想でもあるんですが、最初にバックエンドをTypeScriptで書くと決めた時にFWとORMをどうしようか結構悩みました。
RubyだったらRailsとActiveRecord使っとけば間違いなしみたいなものがTypeScriptにはまだないと考えていて、FWだったらExpress・NestJSとか、ORMだったらtypeORM・Prismaとか色々試していた記憶があります。
結局FWにはNestJSを採用しましたが、アーキテクチャも自由度が高くてしっかり考えて決める必要があったにも関わらずアーキテクチャについての情報はそんなになかったので何度も開発途中に再考していました😅
一度決まってしまえばいいんですが、最初の選定は時間を要するかもしれないです。
TypeScriptを用いたバックエンド開発経験があるエンジニアは確保しにくい
こちらはメリットに上げた参入障壁の低さとトレードオフですが、バックエンドエンジニアでTypeScriptに習熟した人ってなかなか市場に出回っていないと感じています。
最近バックエンドもTSを採用している企業さんも増えてきていると思いますが、まだまだ少ないので熟練者を確保するのは難しいのではないかと。。。
ただ、メリットであげてるように参入障壁は低いと考えているため、育成前提であればあまり気にしなくていいと思います。
終わりに
ここまで読んで頂きありがとうございました。
フロントエンドとバックエンドの両面TypeScriptを採用して感じたメリット・デメリットについての記載は以上になります。
どの言語・FWにも言えることですがメリット・デメリットをしっかり判断した上で、作るシステムにあったものを選定するのが大切だと考えています！
技術選定に悩んでいる方の参考になれば嬉しいです。
Discussion