Use multi_json for rendering

[jhollinger]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe

Config option overload.

Describe the feature you'd like to see implemented

multi_json is a popular gem (that we'd need to depend on) for automatically choosing the fastest JSON renderer your application or library has available:

MultiJson.dump({:abc => 'def'})

I've used other serializers, like grape-entity, that support it, as well as many applications. This would simplify configuration by moving it up a layer outside of our library. We could still offer an override for rare cases if we want, maybe via an extension hook.

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ritikesh]

IMO, the library shouldn't have a favourite. Extensions should be the way to go ahead for people wanting that extra performance. For majority of the users, the native JSON lib should suffice.

[jhollinger]

This is now implemented in #479 with the option to override via an extension hook.

Edit:

If we dislike the idea of adding a dependency, we could change the above so that the multi_json behavior is available as a built-in, optional V2 extension. That way the application is responsible for handling that dependency.

class ApplicationBlueprint < Blueprinter::V2::Base
  extensions << Blueprinter::Extensions::MultiJson.new
end

[sandstrom]

Minor thing, but I think the Ruby JSON gem is pretty fast these days. It used to be slow, but byroot has spent a lot of time optimizing it.

In short, there isn't much value from MultiJson these days. That said, it obviously also doesn't hurt a lot since it's just one extra dependency and for most people it'll still be std lib json under the hood.

== Parsing twitter.json (567916 bytes)
ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +YJIT +PRISM [arm64-darwin23]
Warming up --------------------------------------
                json    93.000 i/100ms
                  oj    66.000 i/100ms
          Oj::Parser    80.000 i/100ms
           rapidjson    58.000 i/100ms
Calculating -------------------------------------
                json    928.472 (± 0.3%) i/s    (1.08 ms/i) -      4.650k in   5.008282s
                  oj    666.198 (± 0.8%) i/s    (1.50 ms/i) -      3.366k in   5.052899s
          Oj::Parser    803.031 (± 0.2%) i/s    (1.25 ms/i) -      4.080k in   5.080788s
           rapidjson    584.869 (± 0.2%) i/s    (1.71 ms/i) -      2.958k in   5.057565s

Comparison:
                json:      928.5 i/s
          Oj::Parser:      803.0 i/s - 1.16x  slower
                  oj:      666.2 i/s - 1.39x  slower
           rapidjson:      584.9 i/s - 1.59x  slower

See:

• https://oldmoe.blog/2025/04/21/ruby-data-serialization-options-in-2025/
• https://byroot.github.io/ruby/json/2024/12/15/optimizing-ruby-json-part-1.html
• https://byroot.github.io/ruby/json/2024/12/18/optimizing-ruby-json-part-2.html
• https://byroot.github.io/ruby/json/2024/12/27/optimizing-ruby-json-part-3.html
• https://byroot.github.io/ruby/json/2024/12/29/optimizing-ruby-json-part-4.html
• https://byroot.github.io/ruby/json/2025/01/04/optimizing-ruby-json-part-5.html
• https://byroot.github.io/ruby/json/2025/01/12/optimizing-ruby-json-part-6.html
• https://byroot.github.io/ruby/json/2025/01/14/optimizing-ruby-json-part-7.html