3 ms·

My company Clausehound has completely moved its legal tech contract analysis and version control platform onto rust, and launched a couple months ago. It's been

My company Clausehound has completely moved its legal tech contract analysis and version control platform onto rust, and launched a couple months ago. It's been fantastic. We're a similar setup to a lot of the top links on there (actix-web over juniper for graphql resolving with sqlx). While the speed is incredible, the biggest improvement has been the types system. I've never had such an easy experience being able to pick and choose libraries based on shared traits - eg we could authorize on jwt using jsonwebtoken, load fairly complex migrated relational data into our nice models, and even wrote the crate phpass so we could keep some accounts created back when we were a WordPress blog working. The strict typing in graphql has made dataloaders orders of magnitude faster. The same code that makes our business logic clear makes it easy to figure out if graphql needs to resolve all those nodes with individual sql queries, one against the parent node, build some `IN (?,?,?,?)` prepared statement, or resolve from cache. String manipulation is definitely a bit harder, but otherwise the experience as a web app developer has been amazing.

andrewnc 6y ago
Would you agree that the resources in the linked article are a good starting point to learn about your specific rust stack, or do you have additional resources you would recommend?
- jkoudys 6y ago
  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").

andrewnc 6y ago

Would you agree that the resources in the linked article are a good starting point to learn about your specific rust stack, or do you have additional resources you would recommend?

jkoudys 6y ago
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").