search

spacebudz / spacebudz-api

MIT License
3 stars 0 forks source link

initBigintSerialization #1

Closed KtorZ closed 2 years ago

KtorZ commented 2 years ago

I am wondering about the use of: https://github.com/Berry-Pool/spacebudz-api/blob/main/src/utils.ts

Ogmios itself does not return bigint as strings, since JSON supports big integers just fine already (it's JavaScript that does not). If using the TypeScript client, large integers are already parsed into bigint, according to the TypeScript types declared in @cardano-ogmios/schema.

This has been recorded as an ADR here: https://github.com/CardanoSolutions/ogmios/blob/master/architectural-decisions/accepted/013-typescript-client_bigint-parsing.md

Did you face any issue with that or was it more of a "preventive strike" :thinking: ?

alessandrokonrad commented 2 years ago

It's not related to Ogmios, everything works fine with it.

I use the lowdb library to dump the result into a json file. It has two functions db.read() and db.write(), which use JSON.stringify and JSON.parse in the back. This is where I get the problems with the Bigint (de)serialization, so I have to overwrite these functions globally that db.read() and db.write() work correctly.

I'll give json-bigint a look. I didn't know JSON can store bigints without problems. Then it would be more clean also

KtorZ commented 2 years ago

Ah! Thanks for clarifying!

Note that we (Rhys and myself) haven't been really convinced by json-bigint... It has a few bugs, some that we fixed in https://github.com/CardanoSolutions/json-bigint, but the overall library design was quite low quality and had many hacks. And the library seems relatively unmaintained today.

Plus, there's something annoying with TypeScript (so, nothing to blame on the library really..) and it's the lack of type reflection. TypeScript types are entirely erased at runtime (which is arguably a nice feature, yes, I am looking at you typed Plutus); but as a consequence, we have very little semantic information on types at runtime... Thus when parsing, one has to inspect a value and guess whether it's a bigint or an int or a string.

At the time we worked on this, I was thinking of two possible path forward:

  1. Have the JSON parsing be done according to a JSON-schema specification (so, have the parser walks the specifications and the data it decodes, so that it can better assert to what should a particular chunk of data should be deserialized to);
  2. Use JavaScript proxy to overload application types with information useful for type reflection.

but well, time was better invested elsewhere.

Anyway :shrug: ...