https://flfymoss.com/tags/rails/Recent content in Rails on Fluffy MossHugoja-JPSun, 14 Dec 2025 00:00:00 +0900https://flfymoss.com/posts/2025-12-12-rails-81-with-protobuf/Sun, 14 Dec 2025 00:00:00 +0900https://flfymoss.com/posts/2025-12-12-rails-81-with-protobuf/<div class="notice info"> <div class="notice-title"> <i class="fa-solid fa-exclamation-circle" aria-hidden="true"></i>Info </div> <div class="notice-content">本記事は<a href="https://adventar.org/calendars/12269" class="external-link" target="_blank" rel="noopener">Akatsuki Games Advent Calendar 2025</a>における14日目の記事です。 昨日の13日目は奈茶さんの記事『<a href="https://knasa.hateblo.jp/entry/2025/12/13/000000" class="external-link" target="_blank" rel="noopener">【Unity】良い感じに被写界深度を調整できるカメラを作る</a>』でした。</div> </div> <hr> <nav id="TableOfContents"> <ul> <li><a href="#はじめに">はじめに</a> <ul> <li><a href="#巨大な数値の取り扱いが処理系依存">巨大な数値の取り扱いが処理系依存</a></li> <li><a href="#データ量が大きくなりがち">データ量が大きくなりがち</a></li> <li><a href="#デコードの負荷が高め">デコードの負荷が高め</a></li> </ul> </li> <li><a href="#rails-と-protobuf-の食い合わせの悪さについて">Rails と protobuf の食い合わせの悪さについて</a> <ul> <li><a href="#protobuf-の基本">protobuf の基本</a></li> <li><a href="#railsでの難しさ1--リロード">Railsでの難しさ(1) : リロード</a></li> <li><a href="#railsでの難しさ2--require-による依存解決">Railsでの難しさ(2) : require による依存解決</a></li> <li><a href="#ここまでの対応まとめ">ここまでの対応まとめ</a></li> </ul> </li> <li><a href="#なるべくシンプルに-rails-へ適応させるには">なるべくシンプルに Rails へ適応させるには</a> <ul> <li><a href="#protoc-実行後-pb-ファイルの-require-を書き換える">protoc 実行後、 pb ファイルの require を書き換える</a></li> <li><a href="#zeitwerk-の管理下から除外し-initializer-で一括-require-する">Zeitwerk の管理下から除外し、 initializer で一括 require する</a></li> </ul> </li> <li><a href="#まとめ">まとめ</a></li> <li><a href="#ライセンス">ライセンス</a></li> </ul> </nav> <h2 id="はじめに"> はじめに <a class="heading-link" href="#%e3%81%af%e3%81%98%e3%82%81%e3%81%ab"> <i class="fa-solid fa-link" aria-hidden="true" title="見出しへのリンク"></i> <span class="sr-only">見出しへのリンク</span> </a> </h2> <p>サーバがHTTP経由でAPIを公開しクライアントがそれを呼び出すモデルにおいて、送受信するデータの形式としてJSONが広く利用されています。 JSON は基本的にどんな言語でもサポートされており（特にブラウザとの相性が良い）、可読性が高く、取り回しもしやすいため潰しが効きます。そのため、とりあえず JSON を採用しておけば困るケースはほとんどありません。</p> <p>……と書きましたが、「ほとんど」と書いたように、困るとまではいかなくとも最適でないケースがいくつかあります。例えば、以下のケースです。</p> <h3 id="巨大な数値の取り扱いが処理系依存"> 巨大な数値の取り扱いが処理系依存 <a class="heading-link" href="#%e5%b7%a8%e5%a4%a7%e3%81%aa%e6%95%b0%e5%80%a4%e3%81%ae%e5%8f%96%e3%82%8a%e6%89%b1%e3%81%84%e3%81%8c%e5%87%a6%e7%90%86%e7%b3%bb%e4%be%9d%e5%ad%98"> <i class="fa-solid fa-link" aria-hidden="true" title="見出しへのリンク"></i> <span class="sr-only">見出しへのリンク</span> </a> </h3> <p>JSON において、数値の取り扱いは処理系依存です。 例として、int64 の最大値である <code>9223372036854775807</code> を含む JSON について、手元の Node.js と Ruby でそれぞれ出力した結果が以下になります。</p>