Does anyone use Golang an autogen some
# spicedb
e
Does anyone use Golang an autogen some type safety into their relationships? I'm looking at using spicedb again, and wrote code awhile back to take a schema, and auto gen this: https://github.com/Emyrk/coder/blob/stevenmasley/zanzibar_authzed/coderd/database/spice/policy/generated.go The resulting code looks like this: https://github.com/Emyrk/coder/blob/stevenmasley/zanzibar_authzed/coderd/database/spice/wrapper.go#L15-L23 I liked that design before, and curious if anyone has build a nice wrapper of the GRPc that is generated from a schema
y
not that i know of. i've seen a couple of projects in other languages, and it's been on my list to have some mechanism to generate some kind of intermediate representation of a schema that doesn't require a full parse, but i don't know of something like this for golang.
there is https://github.com/authzed/gochugaru if it'd help to have a slightly nicer handle on the gRPC methods
e
Oo that is a good resource for using a client. The auto gen thing I scrapped together as an idea was mainly to avoid using strings everywhere. And having type safety on which strings have what relations to other strings. Is this auto gen thing something of interest? Or is using constants (strings) just good enough for everyone?
y
the autogen thing is definitely something that we've seen interest in: * https://github.com/SchoolAI/spicedb-zed-schema-parser * https://github.com/yahiaosama/authz-schema-sync-check * https://github.com/oviva-ag/spicegen * https://github.com/Lur1an/spicedb-rust i haven't yet seen one for golang. i'd like to come up with a cross-lang way of generating the types if possible, perhaps by (ab)using existing tools for openAPI client generation? but i haven't dug too far into it yet
e
This is all interesting. I don't feel well equiped with the schema language to build the best thing, but I might take a second attempt at my tool. And generalize it. I made this for golang -> typescript. Admitadly a much simplier problem, but there probably is some overlap
I think the problem with cross language is that the language tooling is rarely built for these kinds of relationships of "enums". In golang, I was using structs and methods to connect concepts. Which is kinda strange, but it worked 🤷‍♂️
Unsure of the utility, but I used my tool to create import files to the playground: https://github.com/Emyrk/coder/blob/stevenmasley/zanzibar_authzed/coderd/database/spice/policy/playground/relationships/playgrounddata.go It can add the tests/asserts/expected. I wanted to populate the "Check Watches", but the playground at the time could not import that. https://play.authzed.com/s/QB3xyvBLz515/assertions When I click
run
on the assertions, it takes a very long time. Idk if that is me or the playground.
y
yeah, that's where it seems like protobuf or openapi might be a good place to start
on a cursory glance your schema and data don't seem like they should be pathological
does it behave that way only on first load, or is it every time you try it? the system takes a little while to get wasm running
e
@yetitwo that schema is from a long time ago. If I remove the "Expected Relations" it all runs fine. I think something is messed up there? But that is not the schema I would use, just messing around.
> yeah, that's where it seems like protobuf or openapi might be a good place to start Idk if protobuf can describe the relationships here. If I come up with something, I'll share it
y
yeah, now that I look at it, i'm not sure that protobuf can express string enums. [OpenAPIv3](https://swagger.io/docs/specification/v3_0/data-models/enums/) can, though it'd be kind of an abuse of what openapi is
jsonschema might do it as well?
though i haven't been enthused about the implementations i've seen
e
jsonschema might be promising, but idk if that would boil down to something easy to use in the target language
I think the best you can do is transpile to language specific for usability. Maybe an intermediate format for easy generation, but the best intermediate format might just be the schema language and parser ya'll already provide haha.
y
yeah i've definitely had that thought as well
but as the solo maintainer of the six official client libs i haven't been keen to write a parser in each 🙃
i guess it'd be fun as an exercise but i wouldn't enjoy maintaining it
e
Yea, I would not envy being in your shoes hahah
I've never identified as a polyglot myself
6 Views