こちらは株式会社ココナラ Advent Calendar 2025 19日目の記事です。 こんにちは。ココナラ法律相談で開発を担当している高崎です。 以前、こちらの記事でRailsのモノリスから管理画面をReactへ段階的に移行する取り組みについて書きました。 結論から言うと、現在のチームフェーズと事業優先度を鑑み、この「フロントエンド分割(リプレイス)」という方針を中断し、Rails(ERB)主体の開発体制に戻す決断をしました。 今回は、なぜ一度始めたリプレイスを中断するに至ったのか。その背景にある「事業優先の力学」と「合意形成の難しさ」について、自戒を込めて振り返りたいと思います。 理想的なスタートと、現実の壁 当初の計画は、いわゆる 「ストラングラー・フィグパターン」 のようなアプローチでした。 巨大なレガシーシステム(モノリス)を一度に作り直すのではなく、「新しいシステムを少しずつ
はじめに Kaigi on Rails 2025で発表し、何人かの人といろいろ話しているうちに、モダンフロントエンドが面倒臭いのはJSON APIのせいではないかと考えるようになりました。そしてJSON APIそのものが悪いというよりは、JSON APIを必要以上に使う原因となっているSPAが問題ではないかと思っています。まだ考えは固まっていないのですが、まずは部分的に紹介したいと思います。 モダンフロントエンドはJSON基礎工事が大変 SPAのReactフロントエンドを作る場合、Hotwireなら不要だった多大な工数が新しく発生します。 APIエンドポイントのルータおよびコントローラから、JSON APIシリアライザ、クライアントサイドのルータ、JSON APIをfetchしてフォーマット変換する作業、さらにAPIの契約を文書化したOpen APIを作成します。ここには記載していませんが
下記の記事の内容をRuby Gemにしました! react_router_rails_spa gem. 以下のコマンドを実行するだけで、Modern SPAをRuby on Railsに載せることができます。 # Railsのインストール rails new test_app cd test_app # gemのインストール bundle add react_router_rails_spa bundle install bin/rails generate react_router_rails_spa:install # サーバ立ち上げ bin/rails s bin/rails react_router:dev はじめに こんにちは!Ruby on Railsフロントエンドエンジニアを目指し、Hotwireを中心に活動しつつ、Next.jsもReactも勉強している加々美です! 202
フィードバックがないページの例 # 下記のビデオは2024年8月に記録したNewsPicks社のウェブサイトです。Next.jsのSSRとGraphQLを使って作成されているようです。しかしUX上の大きな問題があります。 下記ビデオをご覧になっていただくとわかりますが、ボタンをクリックしても全くフィードバックがなく、1秒後ぐらいにやっと画面が切り替わります。ユーザは自分がちゃんとクリックしたかどうかに自信が持てず、不安になります。またサイト全体がモッサリしている感覚があります。 これは決してNewsPicks社だけが悪いわけではなく、AJAX/fetchによる非同期通信を使ってウェブページを更新するすべてのサイトに共通する課題です。強いていうと、Next.jsが解決策を提供していなかったのが原因と言えると思います。 同じことはTurbo FramesやTurbo Streamsを使っている
GMOアドマーケティングの吉岡です。 今回の記事ではRails 7で追加されたHotwireという技術について、何が良いのか?どんなことができるのか?を話したいと思います。 Hotwireとは? 大量のJavaScriptを使わずに、モダンなWebアプリケーションを作るためのアプローチ JSONではなくHTMLベース サーバーサイドでHTMLを生成し、WebSocketでWebブラウザへ送信 構成する主な要素 Turbo Stimulus Hotwireを使うと何が良いのか? Rails6以前の環境 最新バージョンのjs(ES6)を使いたい →主要なブラウザが対応していないため、ブラウザで動作するES5にトランスパイルする必要がある そのために必要なパッケージとその役割 node.js ES6のjsをサーバー側で解釈するために必要 ES6のjsをES5にトランスパイルするため、node.j
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The popover drama 原文公開日: 2024/06/02 原著者: Jorge Manrubia 日本語タイトルは内容に即したものにしました。 インターネット接続が遅い環境でHEYカレンダーのポップオーバーの読み込みが遅くなる様子が以下でツイートされたことがきっかけで、ポップオーバーのドラマが幕を開けました。その後、無慈悲で辛辣な書き込みやプロの荒らしの出現など、最もSNSらしい形で議論がヒートアップしました。 If you want to know why an app *needs* JavaScript on the client and can’t just do it all on the server, just look at Hey or any other Hotwrite app pic.twit
私は昨年3月以降、Rails7でHotwireを活用して複数のアプリケーションを開発してきました。Hotwireは、SPAのような動きをRailsだけで実現できる良い道具だと思っています。開発体制やコードをコンパクトに保てる利点があります。 ただ、SPAではなくHotwireでやろうと決めるためには、Hotwireでどこまでできるのか? Hotwireでできないことはあるのか? が気になってくる点でしょう。この点について、今では私は以下のように感じています。 やりたいことは大体なんでも Hotwire で実現できる 最終的に実現できる機能の差よりも、どういう考え方で作るかにSPAとHotwireの大きな違いがある SPAとHotwireでは、アプリを構成するための物の考え方が大きく異なります。Hotwireを縦横無尽に使い倒すためには、Hotwire的な考え方で作る必要があるのです。この、
Railsの現在地DHHらは、ビジネスモデルが確定していないレベルの初期のスタートアップにおいて、複雑なSPAでのページレンダリングを採用したWebシステムを構築することはオーバーエンジニアリングでは? というところに、強い課題意識を持っているように見える。フロントエンド、サーバサイド問わず複雑なアーキテクチャにしすぎると生産性悪くない?というわけだ。あのTwitter社ですら儲かるか儲からないかわからないレベルの黎明期にはその思想に賛同してかRailsを採用していた。 近年DHHらは、RailsベースのGmailっぽいプロダクトをリリースしていて、新進気鋭のフレームワークであるHotwire(Turbo)を積んだRails 7でGmailの「あの操作性」を実現できるレベルに進化させた。ReactやVue.jsなどのライブラリを使わずとも実現できることを示した。 Turboの概観Turbo
経緯 world.hey.com DHHが「オタクくん見てる〜? 今からうちのレポジトリからTypeScriptを剥しま〜す」と宣言したことにより、Web開発者界隈でTypeScriptの是非自体の話になり騒ぎになった*1*2。 github.com その後、野次馬がたくさん集ってきてrevertプルリクエストを立てる人やTypeScript公式リポジトリから全ソースコードを消すプルリクエストを出す*3ようなキッズムーブをする人も出てきた world.hey.com 実際の変更 8617行のTypeScriptがJavaScript化された。(Sloc 便利) ❯ scc src/ ─────────────────────────────────────────────────────────────────────────────── Language Files Lines Blan
今年もPHPカンファレンスにてトークさせていただくことになりまして、以下のようなお話をいたします。 日時:9月25日(日) 14:40〜15:40 場所:大田区産業プラザPiO および YouTube 費用:無料 講演タイトル:SPAセキュリティ超入門 申し込み: connpass アジェンダ: SPA(Single Page Application)の普及が一層進んでおり、従来型のMPAを知らないウェブ開発者も生まれつつあるようです。SPA対応のフレームワークでは基本的な脆弱性については対策機能が用意されていますが、それにも関わらず、脆弱性診断等で基本的な脆弱性が指摘されるケースはむしろ増えつつあります。 本セッションでは、LaravelとReactで開発したアプリケーションをモデルとして、SQLインジェクション、クロスサイトスクリプティング、認可制御不備等の脆弱性の実例を紹介しながら
Hotwire https://hotwire.dev/ Turboを中心としたウェブアプリケーションのアーキテクチャの要素技術やコンセプトをPRするための名称 Hotwireというライブラリがあるわけではない 役割としてはMicro FrontendsとかReactのlearn once, write anywhereなどに似ている アプリケーション実装言語非依存だけど現状Railsアプリケーションしか実用できる基盤がない Hotwireの思想 アプリケーション開発者の生産性を上げることを目的にしていること サーバーサイド言語でフロントエンドを実装したいアレではなかった プログレッシブ(段階的に利用可能)であること 必要な技術だけを使い無駄なことをしないことで効率化する Hotwireが列挙する技術は1つづつ有効にできる クライアントサイドでViewを差分更新する現在の主流のシングルペー
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: ViewComponent in the Wild I: building modern Rails frontends—Martian Chronicles, Evil Martians’ team blog 原文公開日: 2022/10/12 原著者: Alexander Baygeldin(バックエンドエンジニア)、Travis Turner(テック編集者) サイト: Evil Martians -- ニューヨークなどに拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 日本語ブログ: 合同会社イービルマーシャンズ - Qiita 日本語タイトルは内容に即したものにしました。図はすべて元記事からの引用です。 また、"Algebraic effects"や
どうもみなさんこんばんは ちょっと前に「個人開発者やスタートアップの初期からSPAで開発するのはコスト高いっすよね」みたいな事を書いたらフロントエンドエンジニアの皆様からバチバチに叩かれた僕です 彼らには彼らの考えがあるのでそれはどうでもいいのですが、どういう理由があってその発言をしたのか~と言う部分が気になっている方もいたようなので説明しておこうと思います ちなみに今でも全く意見は変わっておらず、この発言に同意できるかできないかは単純に視点の違い、規模の違い、スキルの違いだと思ってます 追記: もちろんSPAじゃないと実現できないようなサービスを作りたい場合はSPA一択ですし(インタラクティブにHPつくるサービスとか。でも世の中の95%くらいのサービスはそうじゃないと思います)、サイトの利用はログインした人にだけ提供するような業務系ツールなどはまた話が別です 前提の話 こういう記事ではコ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く