フロントエンド分割やめました
こちらは株式会社ココナラ Advent Calendar 2025 19日目の記事です。 こんにちは。ココナラ法律相談で開発を担当している高崎です。 以前、こちらの記事でRailsのモノリスから管理画面をReactへ段階的に移行する取り組みについて書きました。 結論から言うと、現在のチームフェーズと事業優先度を鑑み、この「フロントエンド分割（リプレイス）」という方針を中断し、Rails（ERB）主体の開発体制に戻す決断をしました。 今回は、なぜ一度始めたリプレイスを中断するに至ったのか。その背景にある「事業優先の力学」と「合意形成の難しさ」について、自戒を込めて振り返りたいと思います。 理想的なスタートと、現実の壁 当初の計画は、いわゆる 「ストラングラー・フィグパターン」 のようなアプローチでした。 巨大なレガシーシステム（モノリス）を一度に作り直すのではなく、「新しいシステムを少しずつ
Railsアンチパターン「なんでもConcern」
これは株式会社マネーフォワード福岡開発拠点が主催している Money Forward Fukuoka Advent Calendar 2025 の 19日目の記事です。 こんにちは、マネーフォワード福岡にてクラウド債務支払のバックエンドエンジニアをしているMocchiです。 クラウド債務支払のリポジトリは長年運用されており、機能追加や改修を重ねる中で、いくつかの技術的負債が蓄積されています。 今回はクラウド債務支払プロダクトに実際にあった事例を元に、Concernによってかえってコードの複雑さを増し、メンテナンス性を低下させることになってしまったアンチパターンについてまとめてみました。 私自身もこうした実装をしてしまった経験があります。自戒の意味も込めつつ、同じ轍を踏まないための知見として共有できればと思います。 そもそも Concern とは？ Railsガイドより抜粋しました。詳細は
Rails8.2ではCSRFトークンを使わずにCSRFを防げるようになりそう - おもしろwebサービス開発日記
RailsではCSRF攻撃を防ぐために、フォームからのリクエスト送信時に自動でトークン(Authenticity Token)を付与して検証する仕組みを持っています。この仕組みがデフォルトで有効になっているため深く考えなくてもセキュアな実装になる点は便利です。一方で、ユーザが普通にサービスを利用しているにもかかわらずトークンの検証に失敗する偽陽性も度々起こり面倒に感じている人も多いように思います。 Rails8.2以降は、そんなトークンの仕組みを使わずにCSRFを防げるようになりそうです。次のPRが先日マージされました。 Use a modern approach for cross-site request forgery protection by rosa · Pull Request #56350 · rails/rails 詳細はこのPRにすべて書かれているのでそれを読んでくださ
RailsでCSRFトークンを使うことで防ぐことのできる攻撃について - おもしろwebサービス開発日記
Rails8.2ではCSRFトークンを使わずにCSRFを防げるようになりそう - おもしろwebサービス開発日記の続きです。前回のエントリではRails8.2からトークンを使わずにCSRFを防ぐ仕組みが入るぞ、という話をしました。偽陽性がかなり減ることが予想されるため、個人的には大歓迎です。 ただ、トークンを利用することで防げる攻撃もあるので100%上位互換というわけではないぞ、という話をこれからします。 前提: Railsはフォームごとに別々のトークンを発行する Railsはこれまでトークンを利用してCSRF攻撃を検知していました。Rails5.0からはデフォルトでフォームごと*1に別々のトークンを利用されるようになっています。これはconfig.action_controller.per_form_csrf_tokens = trueとするかconfig.load_defaults 5
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
