Fastapi: [FEATURE] remove ujson dependency (it is dead)

[hnykda]

FastAPI is using ujson which has not been actively developed for about 3 years by now. Here is a relevant issue. It's starting to be problematic to actually compile ujson on newer platforms.

Possible alternative maybe orjson.

[dmontagu]

I would be in favor of recommending orjson instead of ujson.

I recall the creator of orjson reaching about this many months ago and there was some confusion due to slow responses, and also some issues on the pydantic side, but I think many/most of the barriers to usage have since been removed. If orjson seems to be taking over as the go-to high-performance json library, I think it would make sense to use that for development and recommend it.

To the extent that there is any difference in json encoding/decoding between json and orjson (or ujson and orjson), it would probably be best to document it.

I'd be willing to review a PR making this change (including updates to the docs). (I'd leave the ultimate decision about merging to @tiangolo though.)

[tiangolo]

Yeah, I've been intending to do it for quite some time now... :sweat_smile:

In fact, you can sort of do it right now (and since several versions ago).

---

Here's my plan:

I want to export everything from Starlette, to avoid confusions of the type "do I import this from FastAPI or from Starlette?", I've seen reports of that and even I've struggled with that. For example, FastAPI has its own HTTPException.

With that, I want to have a response ORJSONResponse exported from fastapi.responses, among Starlette's responses.

In fact, I added tests for creating custom responses (as part of a PR), testing specifically creating orjson responses: https://github.com/tiangolo/fastapi/blob/f803c77515662cd2382674d9fc8df1e6641b3ba7/tests/test_default_response_class.py#L9-L13
And you can replicate creating that response class and using it. It's just 3 lines (you would remove the custom media_type), but still, it should be provided by FastAPI (among all the other responses from Starlette).

app = FastAPI(default_response_class=ORJSONResponse)

---

Also, as a side note, UJSON is not really used by default anywhere. It's optional, and you would have to use the UJSONResponse class for it to be used, the same way you would use the (new/custom/future) ORJSONResponse.

[hnykda]

Well, that's elegant sir :bowing_man: :clap: .

Also, as a side note, UJSON is not really used by default anywhere. It's optional, and you would have to use the UJSONResponse class for it to be used, the same way you would use the (new/custom/future) ORJSONResponse.

Then I don't understand why it's in requirements. It's written that it's an optional dependency for Pydantic, but it seems that Pydantic has already moved away from ujson here. Seems that their requirements nor setup.py don't have it anymore.

[dmontagu]

@hnykda the “all” set of requirements there includes everything necessary to make use of all documented features, including those that are optional. It is intended more for development/reference purposes than for use by consumers.

[hnykda]

Ah, got it! Thanks. I believe this can be closed then.

Personally, I would not reference any obsolete dependencies in my project even if they are optional (especially "future-looking" like Python 3.6+, latest libs, ...) . Reasons for that: helping the community to get rid dangerous/old/unmaintained libs and to avoid possibly repealing people who do not like to install stuff which are referencing such unmaintained projects.

[dagnelies]

Apparently, ujson found a new maintainer and is now alive and kicking again. Well, dunno about the kicking part, but releases are pretty fresh:

https://pypi.org/project/ujson/

and repo seems active again. Just mentioning this. Dunno which one is the better lib.

[dagnelies]

Nevermind, apparently orjson is a fine choice too. Apparently one of the fastest.

[ahmadazizi]

Just to mention, installing fastapi on windows platform (python 3.9) fails, since orjson neither provide the compatible wheel nor could be compiled.

[jacopofar]

On Debian stable installing orjson currently fails because it targets manylinux2014 which is supported by pip since version 19.3, but Debian stable install pip 18.1 (if installed through Debian repos python3-pip).

In this case running python3 -m pip install --upgrade pip works, but the error can be tricky to detect

[ahtik]

@ahmadazizi, orjson wheels are now available also for Windows Python 3.9.