Babe get in here, a new kentonv library just dropped!

I'm surprised how little code is actually involved here, just looking at the linked GitHub repo. Is that really all there is to it? In theory, it shouldn't be too hard to port the server side to another language, right? I'm interested in using it in an Elixir server for a JS/TS frontend.

For that matter, the language porting seems like a pretty good LLM task. Did you use much LLM-generated code for this repo? I seem to recall kentonv doing an entirely AI-generated (though human-reviewed, of course) proof of concept a few months ago.

Some of the tests are LLM-generated, but none of the library itself is.

I don't think LLMs would be capable of writing this library (at least at present). The pieces fit together like a very intricate puzzle. I spent a lot more time thinking about how to do it right, than actually coding.

Very different from my workers-oauth-provider library, where it was just implementing a well-known spec with a novel (yet straightforward) API.

The code might port nicely to another dynamic language, like Python, but I think you'd have a hard time porting it to a statically-typed language. There's a whole lot of iterating over arbitrary objects without knowing their types.

I think crossing a language barrier here would be hard: you'd need a codegen step to compile the RPC spec to Typescript for the client-side DX and that would need take into account the full range of differences in serializability across the languages.

For cross-language RPC, I think we're still better sticking to a well defined system where the spec is data (OpenAPI, GraphQL, etc.) instead of the spec being code that only one side understands.