then some other unique identifier that's is shorter for URLs

We are doing this right now almost everywhere except on some dashboard elements, but it's kinda a pain 🥲

At one point we also introduced the ability for the user to customize the slug to reach certain resources, it was more confusing than useful, so we switched back to autogeneration.

I like something like discord only one id in and out, no names no personalization no problems, it's ok even if uuid it's a bit longer. I don't see problems in this aproach, am i wrong?

Not having this dict configurable without customizing the class seems problematic to me

Next week i try to implemente this solution and let you know

My understanding is that you have a "Snowflake ID to JSON" conversion problem

There is actually a kind of bug: if you take a BigInt in DB, for example2^64 and represent as int, JavaScript/TypeScript Number can only safely represent integers up to2^53−1. JSON follows the same limitation, so although no error occurs, it is still technically incorrect.

It is possible to find a workaround on client side, but it is not guaranteed to work on all browsers.

There is actually a kind of bug: if you take a BigInt in DB, for example 2^64 and represent as int, JavaScript/TypeScript Number can only safely represent integers up to 2^53−1. JSON follows the same limitation, so although no error occurs, it is still technically incorrect.

Sorry if I missed it but what's the result of this behaviour? Does it fail? Does it produce an incorrect response? If a Django native datatype can't be converted to a proper json by DRF, we may consider to add a warning and update the docs about it.

Sorry for the late reply, in the meantime i've made some research and extensive tests.

JSON does not have a native BigInt type — it only supports double-precision floating-point numbers (IEEE 754), that are safely precise for integers only up to 2⁵³ − 1 (i.e. 9,007,199,254,740,991). Beyond this threshold, numbers lose precision and may be silently truncated or rounded when parsed in JavaScript or other languages.

It depends on the json library implementation, this particular issue doesn’t happen in Python but it’s not consistent across all languages JSON libraries

The twitter example:

Twitter introduced via api id both numeric and id_str as string to avoid this exact problem.

Why DRF test frontend works?

Because it uses FormData, basically it is all string data, and since the server side render is handled by python no bigint errors occour

Resources:

• Conversion problems
• Stackoverflow twitter bigint with js

Since the majority of frontends that will call api are javascript, this is an issue that have to be addressed in my opinion, i know that the bigint problem with ids will happen only at very large scale and probably a lot of people will never encounter this, but if we find a solution it would be wonderfull.

COERCE_DECIMAL_TO_STRING
I suggest doing like this flag also for bigint, that is the exact same problem only for floating point that js also does not support well :')

@ulgens i've opened a issue about this.9733

👏🏻 I think this approach has better focus on the actual issue, and precisely defines what needs to be handled. Thanks for all the details. I'll be following people's reactions under#9733, and I can help with the PR when it's ready.