Yeah, I probably have been a lazy member of the greater dev community because I learned a lot of these things but never blogged about it myself. Juniper for graphql is a big missing piece from that page -- gql is big enough as an alternative to REST that it ought to be at least considered, while RESTful services typically come baked-in because they rely so much on standard HTTP (so their use with eg actix-web is obvious). What I really found amazing was how we could write one struct, e.g. an Organization, and easily build them from JWT claims, SQL queries, graphql payloads, or POST params. With many other framework libraries, I'd really agonize over graphql vs rest, but because the types are so rigidly defined, it's very easy to write the definitions once and use them everywhere, so RESTful endpoints are simple to setup where there's a client demand for them.

An extremely cool new one is serde_pickle support (python's favourite binary serialization), which we're using to load tiny word-vectorization dictionaries in WASM. This lets lawyers collaborate concurrently on the same contract, and farms out the laptops/phones they're working on's GPU cycles to auto-draft the contract (e.g. type 8 words, and can see "85% chance this a non-disparagement clause -- here's some example language you can use. Here's some case law saying when it's enforceable and when it's not").