はてなブックマーク

私は昨年3月以降、Rails7でHotwireを活用して複数のアプリケーションを開発してきました。Hotwireは、SPAのような動きをRailsだけで実現できる良い道具だと思っています。開発体制やコードをコンパクトに保てる利点があります。 ただ、SPAではなくHotwireでやろうと決めるためには、Hotwireでどこまでできるのか？ Hotwireでできないことはあるのか？ が気になってくる点でしょう。この点について、今では私は以下のように感じています。 やりたいことは大体なんでも Hotwire で実現できる 最終的に実現できる機能の差よりも、どういう考え方で作るかにSPAとHotwireの大きな違いがある SPAとHotwireでは、アプリを構成するための物の考え方が大きく異なります。Hotwireを縦横無尽に使い倒すためには、Hotwire的な考え方で作る必要があるのです。この、

私たちのサービス(note)のバックエンドは、Model 数が 800 以上と比較的大規模なモノリシックRailsアプリケーションで構成されています。 また関わるエンジニアの人数も40名程度のため、開発効率の低下、バグの増加といった課題が顕在化してきました。 このような課題に対しマイクロサービスアーキテクチャを検討しましたが、アーキテクチャ検討の前にまずはドメイン分割を進める必要があると考えました。 そこで Packwerk という Shopify が開発した gem を導入することにしました。 Packwerk は、モジュラーモノリス化を支援してくれる gem です。 設定したディレクトリをモジュールとみなし、モジュール間の依存関係を静的解析で検出してくれます。 モジュール化は基本的にはファイル移動だけなので、ドメイン分割を段階的に進めることができ、やり直しも容易にできます。 これらの特

Kaigi on Rails 2021は終了しました。 当日のライブ配信は YouTube にて視聴可能です。 動画アーカイブ Kaigi on Railsのコアコンセプトは 「初学者から上級者までが楽しめるWeb系の技術カンファレンス」 です。 Kaigi on Railsは技術カンファレンスへの参加の敷居を下げることを意図して企画されています。また、名前の通りRailsを話題の中心に据えるカンファレンスではありますが、広くWebに関すること全般（例えばフロントエンドやプロトコルなど）についてもカバーすることで参加者の知見を深め、また明日からの仕事に役立てていただければと考えています

RailsではActiveRecordや各種のgemを活用することで、低レイヤーの挙動を意識することなくわかりやすいコードを書くことが可能です。 一方で、こうしたコードは実際の内部的な挙動が把握しづらく、パフォーマンス上の問題を意図せず抱え込む可能性も秘めています。これはユーザの体験を損なうのみならず、場合によっては大規模な障害を引き起こす原因にもなりえます。 このセッションでは、パフォーマンス上の問題を把握するための計測手法や、見つかった問題を解決するためのアプローチについて、実例を交えてご紹介します。