Extensible code generation / support for alternative pg interfaces and template based code generation

[magick93]

Hello

The db-first approach is wonderful, and opens up many possibilities.

I'm interested to hear if the following ideas would be possible, and if if so, what issues, if any, you see.

• Support for wasm. Wasm does not allow socket connections. So, there are alternative approaches, such as what Spin are doing - see https://github.com/fermyon/spin/tree/main/examples/rust-outbound-pg
• Supabase has various client interfaces. There primary one is Javascript/Typescript. But there is also https://github.com/supabase-community/postgrest-rs.
• Having a template based generator (eg, takes an input of the template(s) and output file extension) it could be possible to generate many other artifacts, from user interfaces, documentation, tests, code in other languages etc.

[extraymond]

it would be nice to use cornucopia within cloudflare worker.

cloudflare worker is a wasm-based edge computing platform. It currently provides a way to connect to tokio-postgres with their custom socket-connect function.
https://github.com/cloudflare/workers-rs/blob/main/examples/tokio-postgres/src/lib.rs

currently sqlx is blocked there because not all of the dependencies are able to be compiled under wasm32.

If I understand correctly, since the query generated by cornucopia are not tightly coupled with the underlying driver, I suppose one might be able to use the connection build within cloudflare-worker to substitute the generated one?

[LouisGariepy]

• WASM is supported in TPC-enabled environments (e.g. Cloudflare Workers, see the basic async wasm example). Currently there is no plan to support Spin, but if you have ideas please share them.
• Same as above, there is currently no plan to support alternative client interfaces, but if you have ideas feel free to share them.
• Having some sort of templating ability is almost inevitable at this point to support query variants, multi-inserts etc, but there's not a clear proposal yet. But regarding supporting different languages, I'm not opposed per se, but that dramatically changes the scope of the project beyond what our contributor bandwidth is. A more fruitful approach might be to modularize the codegen layer such that third-party crates can implement codegen for third-party targets.

I'm gonna go ahead and convert this issue into a discussion since it's not directly actionable for now.