fabruic VS serde

For today, I've chosen to use my best guess as to the best type of blocking wrapper for each type of operation, but the long-term goal is utilizing a new async executor that Daxpedda is working on. It's compatible with tokio, but it already has a concept named block_on_blocking, which is an optimized version of blocking designed to more fairly block without needing to adopt a 'static lifetime requirement due to using spawn_blocking. He's about to resume working on the executor, but he was responsible for the QUIC-based networking stack PliantDB is using and is wrapping up a few last requests before moving on.

Note that the pre-compiled binary blob the blog post is referring to has since been removed [0].

[0]: https://github.com/serde-rs/serde/pull/2590

> In other words, there is still a (lossy) translation layer, it just happens to be in the RDBMS rather than in-app.

It's not lossy if your application can guarantee a json <-> datatype roundtrip and the json is validated with jsonschema (generated by your application)

In Rust it's something like this

https://serde.rs/ to do the data type <-> json mapping

https://docs.rs/schemars/latest/schemars/ to generate jsonschema from your types

https://github.com/supabase/pg_jsonschema to validate jsonschema in your database (postgres). with this setup it's interesting (but not required) to also use https://docs.rs/jsonschema/latest/jsonschema/ to validate the schema in your application

To serialize and deserialize data, we'll employ the popular serde crate along with serde_json. This will allow us to easily convert between Rust types and JSON when working with API requests and responses. For async operations we'll use the Rust futures crate.

I'm not sure if it's the same person as the OP, but I suspect it is.

[0]: https://github.com/serde-rs/serde/issues/2593

This provides some additional context for why the pre-built binary was added:

https://github.com/serde-rs/serde/issues/2584#issue-18580752...

Due to the way that the derive feature was causing the dependency chain in Cargo to be longer than necessary, thereby making it impossible for cargo to compile multiple crates in parallel.

https://github.com/serde-rs/serde/pull/2514#issuecomment-164...

> Are you just making stuff up? Not one of those quotes are comments are on the github issue

https://github.com/serde-rs/serde/issues/2538#issuecomment-1...

Are you just making stuff up? Not one of those quotes are comments are on the github issue that was closed and which was being discussed in this thread: https://github.com/serde-rs/serde/issues/2538

I already referenced the worst comment and it falls closer to brutally honest than actually rude.

I dislike some of the framing of the article. In particular:

> Valentini further inquired to the project maintainers, how were these new binaries "actually produced," and if it would be possible for him to recreate the binaries, as opposed to consuming precompiled versions.

> David Tolnay, who is the primary Serde maintainer, responded with potential workarounds at the time.

The article links to the response [1] as well, which is very good. However, the response is super clear:

>> how is the x86_64-unknown-linux-gnu binary actually produced? Would it be possible for us to re-create the binary ourselves so we can actually ship it?

> By https://github.com/serde-rs/serde/blob/v1.0.177/precompiled/.... Yes.

[1] https://github.com/serde-rs/serde/issues/2538#issuecomment-1...