I really like the idea of it. My dream has always been to work with "types" first and foremost across any and all languages (yep it is a dream). And little tools like these are really nice to see push that boundary.
One feedback - if you are truly comparing with "other" tools - you should be looking at grpc and protoc plugins. I have used to great effect for things like:
1. Generating wasm bindings for grpc services
2. Generating "data access layer" types so you can choose how a api proto is transformed to a data domain type and vice versa
3. MCP bindings for APIs
4. GraphQL/BFF bindings with multiple services
5. All of the above "across" langauges.
The tooling is fantastic and extensible - if you are ok to start with a proto view of your world - it sounds wierd and like an N+1 problem but once you are used to it it is surprisingly fun (ok we may have different ideas of fun)
Totally - The other really nice thing about Golang "type-system" ecosystem is their native ast in the stdlib. You can do so many amazing things from there. Infact if you pledge your life to Go (which I think I have atleast for now) starting from Go and generating everything outwards is not necessarily a bad strategy.
On this “types first across languages”, I’ve been hacking on something in that vein called Kumi (typed calculation schemas compiled to Ruby/JS). Tiny demo here https://kumi-play-web.fly.dev
I am still thinking about some blog post about all the journey but I have never wrote one of those, but see here some write-up I did on a reddit post https://www.reddit.com/r/Compilers/s/osaVyUgvUf
Eh, a lot of those problems have solutions, and some are more theoretical.
Yes, if you design your graph to allow something like `tags -> relatedTags -> relatedTags` ad infinitum you can let your clients build a performance problem. So why not have just a top-level `getRelatedTags(tagName)` query? Or a `getRelatedArticles(articleId)` query? Just because you can have things nested doesn't mean you need to have all the things nested.
The bulk of our REST API is backed by some Rails gem, which allows for a `fields` param. Those `fields` can be deep. As in you could write `getComments?id=1234fields=user.orders`, but do you know what we do? Don't expose `orders` as a field on `User`.
Type-first is cool. But I think I'll always aim to avoid gRPC, at least in part because grpc-web was so completely broken. I also have an instinctive aversion to binary formats. YMMV, just my PoV.
I’ve had a lot of success with grpc web. Had to patch a couple of things along the way. My biggest misgiving is thinking having bigints would be a good idea (it is not a good idea). Aside from that though, I’ve been happy with it. What felt broken to you?
+1 Couple of things I really hate about proto - No generics/templates. No composition of services or mixins (you do have composition in messages but that feels very limited). Also the clunkiness around having to declare more things (try a repeated map field or a map of repeated fields).
My comment about protos was just the spec (and was seperating the binary formats as a different concern). But your concerns are pretty valid.
One feedback - if you are truly comparing with "other" tools - you should be looking at grpc and protoc plugins. I have used to great effect for things like:
1. Generating wasm bindings for grpc services
2. Generating "data access layer" types so you can choose how a api proto is transformed to a data domain type and vice versa
3. MCP bindings for APIs
4. GraphQL/BFF bindings with multiple services
5. All of the above "across" langauges.
The tooling is fantastic and extensible - if you are ok to start with a proto view of your world - it sounds wierd and like an N+1 problem but once you are used to it it is surprisingly fun (ok we may have different ideas of fun)