はてなブックマーク

About Kaigi on Rails? Kaigi on Railsのコアコンセプトは 「初学者から上級者までが楽しめるWeb系の技術カンファレンス」 です。 Kaigi on Railsは技術カンファレンスへの参加の敷居を下げることを意図して企画されています。 また、名前の通りRailsを話題の中心に据えるカンファレンスではありますが、広くWebに関すること全般（例えばフロントエンドやプロトコルなど）についても扱います。 これからも参加者の皆さんにとって、日々の開発に役立つようなカンファレンスであるべく活動していきます。

私は昨年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 です。 設定したディレクトリをモジュールとみなし、モジュール間の依存関係を静的解析で検出してくれます。 モジュール化は基本的にはファイル移動だけなので、ドメイン分割を段階的に進めることができ、やり直しも容易にできます。 これらの特

Next.jsはReactをベースとしたWebフロントエンドのためのアプリケーションフレームワークです。Railsとは同じレイヤーのフレームワークなのでRailsに組み込んで使うような関係ではありません。しかし、近年においてはRailsはAPIモードでAPIだけを提供し、フロントエンドは別アプリケーションとして作るという構成も珍しくありません。そういったケースでフロントエンドのフレームワークとして有力な候補となるのがNext.jsです。 Next.jsの特徴として、パスベースのルーティングや自動的なパフォーマンスの最適化、ゼロコンフィグな開発環境、Static Generation や Server-side Rendering を簡単にできる仕組みなどがあります。これらの特徴はRailsと共通するところもあれば全く異なる考え方のものもあります。そういったNext.jsの特徴をRailsの

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