Topics:

SQLX via @BlaineBublitz

Repo: https://github.com/phated/twentyfive-stars

Diesel doesn't have async support and Blaine was fighting with its query builder pattern. Sqlx is a multidatabase driver that doesnt try to be like query builder. Sqlx give you a query method and you give it SQL query strings. It then does preparation of the statement, you bind your parameters, and it returns a stream for you to work with. Sqlx also gives you more powerful features because the schema can be type checked. The default behavior with query does not do type checking, it passes the value you bind in the place of the query. However if you use query_as and tell it the type that it is emulating, the returned vector of structs is type checked.

More excitingly, sqlx also give you macros for both query and query_as which give you static type checking against your queries while you're working on them. The macro is taking the schema, knowing the data types, and type checking against your query to match the data type you are trying to put into. Diesel kind of gives you this because their migration system dumps out a schema definition to the filesystem and you write your typed queries against it. However, this prevents rapid prototyping (e.g. having an altered database in development before you create the migration and build your code against and see if it works). With sqlx, you can have the live feedback loop and it is still type-checked. Also, diesel do not support views where you could get that type information back from Postgres.

Another cool feature being worked in sqlx is offline support. If you are offline and a schema file exists, the macros will serialize the schema out to JSON and will type check against the schema on the filesystem. This is similar to diesel but you don't always have to match the schema while developing, just when you building in production or don't have access to a database. Using cargo sqlx prepare, you can prepare the schema if you have a database connection. It will run a build against your project, gather up all the queries you are using, and generate a JSON file that maps to those queries.

Using Rust-built WebAssembly in a Create React App via @DanielPBank

Repo: https://danielbank.github.io/rust-wasm-react

I made a simple web app that performs the DBSCAN clustering algorithm on a collection of points. I used a Rust library called dbscan and followed along Richard Reedy's Using WebAssembly with React tutorial to implement it.

Below were a few issues that I had to work through while building the app:

The WASM Package used by the React App is not updating when I change my code

I experienced this issue where my WASM code was not updating when I built it and installed it in the React App. Even though I was deleting the node_modules folder, the package-lock.json was hanging onto the old package. I solved it by deleting both the node_modules and the package-lock.json.

the trait wasm_bindgen::convert::traits::FromWasmAbi is not implemented for std::boxed::Box<[some type here...]>

The dbscan crate I am using wants to receive the points as a Vec<Vec<f32>> but when I tried to use this type for the input to the wasm function, I received an error about the FromWasmAbi trait not being implemented. It turns out that you are pretty limited in the types that you can use in a #[wasm_bindgen] function. Fortunately, you can get around it by passing your data in and out as a &JsValue and serialize / deserialize it with Serde. See Serializing and Deserializing Arbitrary Data Into and From JsValue with Serde.

Crates You Should Know

  • color-eyre: A custom context for the eyre crate for colorful error reports, suggestions, and tracing-error support
  • dbscan: DBSCAN Clustering Algorithm
  • regress: REGex in Rust with EcmaScript Syntax
  • sqlx: Async SQL featuring compile-time checked queries without a DSL
  • wgpu: idiomatic Rust wrapper over wgpu-core