I must admit, I am not familiar with orjson, but the project does look promising.

However, it is still a young project (not that ujson or sanic for that matter are that old either), and I am not sure if it is battle tested out in the wild or not.

I think a better approach is just allowing the developer to pass in their own dumps method. Indeed, the developer already has that option:

import my_favorite_json
from sanic.response import json

async def handler(request):
    return json(..., dumps=my_favorite_json.dumps)

The developer is free to use an alternative. And, indeed, perhaps we can add some documentation on this.

At this time I would be more in favor of a PR that fixes the documentation that would explain how to do this rather than universally making the change for the entire project (especially since there would be a breaking change as pointed out).

Yeah, i agree with @ahopkins . Also looks like orjson only has manylinux wheel published https://pypi.org/simple/orjson/. there is no source dist, and no wheel for macos currently.

Can I take this one? :)

@szepnapot Please do. 🍻

(So I know we are on the same page, you are talking about the documentation part, right?)

Ok. I think it would be more appropriate to change the default to rapidjson or worse to change it to json and make the user choose another library for performance reasons. ujson has been unmaintained for years, that'll only get worse, and neither rapidjson nor json have its issues. rapidjson is close in performance for strings and dicts type web app payloads.

I think a documentation change on using a different JSON library isn't likely to have much effect though in that people also don't really change defaults and it doesn't help the library's goal of being fast out of the box.

orjson can distribute macOS, Windows, and source distributions, but it hasn't been done.

@ahopkins Yes :)
Can you give me some ideas what other examples can we show on the doc?
Or it's enough to show how to use a handler via this json example?

@szepnapot Since you are working on it, maybe also mention how to pass a loads when access JSON data from request:

import my_favorite_json
from sanic.response import json

async def handler(request):
    json_data = request.load_json(loads=my_favorite_json.loads)
    ...
    return json(..., dumps=my_favorite_json.dumps)

@yunstanford orjson now publishes Linux, macOS, and Windows wheels. Can we either go forward with this or split the documentation to another ticket so I can close?

@ijl i've tried once, but looks like some unit tests are failing. but didn't dig deep.

Any progress on this?

hmm for small JSONs ujson faster.

ultrajson 2.0.0 is released, supports Python 3.8 https://github.com/ultrajson/ultrajson/releases/tag/2.0.0

New release of the ujson contains breaking change: they do not serialize iterables anymore. So, for example, set can't be serialized anymore. Probably you should switch from the ujson finally

I'll reopen for anyone that wants to add discussion. Now that it is being supported again, I am less inclined to switch but only en to convincing arguments. Thanks for sharing @VMAtm , I'll take a read thru the release notes.

Looks like new ultrajson now degradate feature set to orjson.

What do you mean?

@ahopkins

Remove serialization of date/datetime objects (50181f0) @Jahaja
Remove double_precision encoding option and precise_float decoding option (eb7d894) @Jahaja
Remove generic serialization of objects/iterables (53f85b1) @Jahaja
Remove support for __json__ method on str (5f98f01) @Jahaja
Remove blist tests (3a6ba52) @Jahaja

for me, the most important feature was datetime conversion. Now ultrajson have the same feature set as orjson but slower.

Personally on a couple of performance-critical applications in my organisation I have replaced ujson with orjson, specifically for the built-in iso-format on datetime objects (and orjson is super fast).

@ashleysommer I see, for me, was the most important deserialization what not supported by orjson.

Yeah. That was one of the biggest reasons I was hesitant to make the switch because of the changes that would cause for Sanic users.

If it is a problem we will have to endure either way, I am back to the beginning on this one.

Anyone willing to put together another round of performance testing?

I been in the json lib hellhole for a while now, and im a vivid Sanic user and what I would love to get access to instead of choosing one in particular is to do something like this:

https://github.com/mattgiles/mujson

Have a "proxy" so you can load the compatible ones and it deside which to use based on dev prefs and so on. This would make Sanic a bit more "configurable" to the specific issue you are having :)

I need to speed up my json handling since I am running our entire backend microservice installation on Sanic with quite a bit of throughput, being able to use whats strong for the usecase is a strong feat and gives a very flexible solution to the json serialization and deserialization for Sanic. (In my eyes there are no unicorn in the json lib family)