Webサービス開発でのmonorepo環境(Turborepo, nx)
Webサービス開発の文脈で、モノレポ環境を作る方法について整理しました。 ※バックエンドもフロントエンドも全てTypeScriptで開発している前提 この記事を書いた背景 世間で言われる「モノレポ」がどのように達成されているのか知らなかった 参考記事を読んでると実現方法が異なっていたり、運用のイメージが見えなかったり、ベストプラクティスが分かりづらかった Turborepoのようなモノレポツールを導入すれば解決しそうだが、このツールが何をしてくれるのか理解できなかった モノレポ何も分からない………になった この記事ではモノレポに関連する仕組みを1つ1つ丁寧に把握し、最終的に理想的なモノレポ環境を実現することを目指します。 モノレポとは？ まずは用語の整理から。 モノレポを素直に訳せば「1つのリポジトリ」という意味でしかなく、1つのリポジトリで開発していればそれは「モノレポ」と呼べそうです。
TypeScriptでWebサービス開発（Apollo Server/Prisma/Next.js etc...)
最近開発しているBtoB SaaSサービスの技術スタックを、RailsからNode.jsに移行した。 これにより、フロントエンドもバックエンドも全てをTypeScriptで統一することができた。 特にNode.jsのWebバックエンドの構成について、まだまだ世の中に知見が少ない気がしているので記事にしておく。 Webバックエンド - Node.js(TypeScript) Nexus/Apollo Server (Webサーバー) GraphQLサーバーとして、Apollo ServerのコードファーストなアプローチでのラッパーであるNexusを使っている。 Railsからの移行を決断できたのも、Apollo ServerとPrismaにより、外部との通信が型付きで、かつ開発体験よく書けるようになたから、というのが大きくある。 数年前の段階だと、素のexpressを使ってWebサーバーを立
TypeScriptのProject Referencesを使ってソースコードを分割し、レイヤー間の依存関係を強制する
TypeScriptのProject Referencesを使ってソースコードを分割し、レイヤー間の依存関係を強制する サマリ Project Referencesを使うと、1つの巨大なtypescriptプロジェクトを、複数のプロジェクトに分割し、プロジェクト間の依存関係を整理することができる。これにより、例えば以下のようなことができる test/ ディレクトリで export しているテスト用の関数を、 src/ ディレクトリの本番用コードでは参照できなくする レイヤードアーキテクチャで設計しているとき、プレゼンテーション層で定義している関数を ドメイン層から参照できなくし、レイヤー間の依存関係を強制する また、プロジェクトの分割によりビルド時のパフォーマンスが大幅に改善する。 …と公式で書いているが、ビルド時の挙動を正確に把握しないとむしろ悪化するので、注意が必要 適切なプロジェクト
Blitz.jsをRuby on Railsエンジニアが触ってみた感想
感想です。 何をしたか 現状でBlitz.jsで本番サービスを運用できるかの調査。 Railsで運用している本番サービスの一部機能を、3日間ほどかけて移行を試してみた。 結論 (Railsの主戦場でもある)新規事業開発の文脈でのクイックな立ち上げを想定するなら、本番運用するにはまだ厳しい。 特に、RailsユーザーとしてはActiveRecordがないのが厳しい。 開発効率そのものはRailsと比べて多少落としても、Railsよりもスケーラブルで型安全に開発したいなら、割と良い選択肢に思う。 もろもろ可能性は感じるので、引き続き応援していきたい。 良かった点（＝Blitz.jsに興味を持っている理由） 型安全な開発 サーバーもフロントも全てが型に守られた開発、そしてIDEの恩恵を受けられるのは、いうまでもなく心地がいい。 型は補助輪のようなものなので、ユーザースキルが高ければ必須ではないく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
型のあるRails開発を試してみる(2021/01/07)