弊社新規プロジェクトではNest.jsとGraphQLを採用しました。大まかにその利点を紹介します。
DIPをベースに宣言的コード記述によってバックエンドのサーバを作れるフレームワークです。サーバサイドでもAngularの仕組みを踏襲してモジュールシステムを構築できる仕組みになっています。
このフレームワークはagnosticismな設計によって非常に多岐に渡る拡張ができるため、多くのサードパーティツールによる拡張ライブラリが存在し、かつTypescriptで記述されることを前提としているため、Node.jsでTypescriptでサーバサイドを記述したい、かつ、拡張性を重視したい場合には選択肢としてよいでしょう。
特にTypescriptのスキーマからGraphQLのスキーマを自動生成できるコードファーストアプローチのサポートが強力です。もちろんGraphQLのSDLを元にresolverを記述していくスキーマファーストアプローチにも対応しています。
また、Application Serverもexpress、fastifyのように選択できて、それらのプラグインも有志によって多く作られています。
機能を拡張するライブラリも充実していますが、たとえそれらライブラリが存在していなかった場合でも、既存のライブラリを利用して自分でmiddlewareを書くこともそれほど大変ではありません。
このように多機能なフレームワークであるため、学習コストは高かったり、関連ライブラリがどんどんアップデートされて頻繁に変更対応を迫られるのがたまにきずですが、GraphQLのサーバを作る上では非常に体験がよかったためお勧めできます。
GraphQLはフロントエンドからバックエンドにレスポンスのスキーマを自由に要求できるため、RESTで書かなければいけない多くのバックエンドのエンドポイントの実装を省略できました。また、@nestjs/graphqlの実装によって、バックエンドの実装と同時に必要なGQLスキーマファイルが生成できて、それらを利用してfrontendのコードも自動生成できるため、バックエンドの変更によってフロントエンドの変更の伝播が容易になりメンテナンス性が上がりました。この辺りの仕組みやどのような実装をしていったかについてはサービス追々ブログにも書いていこうと思っています。また、後述のprismaとの相性がとてもよく、GraphQLでフロントエンドから受け渡したパラメータを型がついたままスムーズにORMに渡して処理することができます。
Rustで書かれた広義のORMです。正確にはModel層を自動生成してほとんど隠蔽しているので、リポジトリ生成機能つきDBクライアントという表現が正しいかもしれません。現在主流のTypeORMではなく、こちらを採用した経緯としてはPrismaもSDLを保持しており、この仕組みがとても秀逸で、公式が対応してくれさえすれば、クライアントの生成はOpen Apiのように（RustによるClient生成コードを除けば）非言語依存なため言語に応じたDBクライアントを生成できるポテンシャルを持っていること。query-engineの実行制御がrustであるため高速に動作すること。そして、SDLから自動生成されるTypesciptのクライアントが非常にNest.jsのGraph QLのコードファーストアプローチとの相性が良いことが挙げられます。
これが現在のMOCHIの新規開発の基本となる技術スタックとして採用されており、今後もこの構成で新規開発を行っていく予定です。
良いところばかり述べましたが、これらの技術に関する情報はあまり、出回っておらず現時点では公式のドキュメント（原文英語）でしか情報がないことも多いのでおそらくフォローアップが大変だと思います。
弊社でも試行錯誤を繰り返しながらベストな形が見えてきたところであり、今弊社ではこれらの技術セットを駆使して多くのアプリケーション開発の効率が上がってノウハウが蓄積されてきているのを実感しているため、これらの技術セットに精通している方なら楽しく働ける環境になってきてるのではないかと思います。
正規・非正規問わず、2021年11月18日現在、従業員も募集しておりますのでご興味があれば、カジュアル面談などでもよいので、ぜひ弊社ブログのフォームからお問い合わせください。ご応募お待ちしております。