ramnivasl

That is also the approach we took with Exograph (https://exograph.dev). Here is our reasoning (https://exograph.dev/blog/exograph-now-supports-mcp#comparin...). We found that LLMs do a very good job of crafting GraphQL queries for the given schema. While they do make mistakes, returning good descriptive error messages make is easy for them fix queries.

We will eventually offer it as a service.

About the license. Indeed, it is BSL with an additional grant that lifts all restrictions on its users (may run it wherever they like, may even modify and run that version), but it restricts being provided as a service. We believe this strikes a good balance between user freedom and monetization strategy. I would be curious to learn your thoughts.

Part 1 is at https://exograph.dev/blog/wasm-pg-explorations-1

The second part is published: https://exograph.dev/blog/wasm-pg-explorations-2

During our journey towards WebAssembly support for Exograph, we learned a few things to improve the latency of Rust-based programs targeting WebAssembly in Cloudflare Workers connecting to Postgres. This two-part series shares those learnings. In this first post, we will set up a simple Cloudflare Worker connecting to a Postgres database and get baseline latency measurements. In the next post, we will explore various ways to improve it.

Even though we experimented in the context of Exograph, the learnings should apply to anyone using WebAssembly in Cloudflare Workers (or other platforms that support WebAssembly) to connect to Postgres.

Exograph now supports Clerk as an authentication provider! Our integration goes beyond supporting JWKS authentication; it also makes it easy and fun to explore APIs by integrating Clerk's UI in Exograph's playground. This blog will transform a todo app without authentication into a multi-user todo app by adding just four lines and modifying a single line of code!

Indeed, once you end up pulling in most common Scala classes (collections, futures, etc.), adding new functionality to your app increases app size by very little. Our app has ~600KB gzipped js (attributable to Scala.js compiled code) + ~200KB of React and other libraries. The overall size has barely moved beyond +-100KB in last few years despite adding new functionality all the time.

Once Scala.js supports lazy loading of modules (hopefully soon after 1.0), the size issue will have significantly less practical impact.

Also, if you use webpack (directly or through scalajs-bundler), the use of webpack-dev-server makes live loading automatic.