Run-time type information

[rapropos]

I am trying to use webrpc as a replacement for GraphQL, and have hit a roadblock in that I have some types that are otherwise indistinguishable over the wire, aside from the __typename field. I suppose I could add this sort of discriminator manually to the type definition, and feed it in the service, but this seems rather error-prone.

Would this be something that you might consider adopting upstream, or am I going to be totally on my own maintaining a fork if I go the route of hacking up the generators?

There doesn't seem to be a way to add override directives (or whatever you call the + go.field.type = foo sort of lines in RIDL) to a struct definition itself, but perhaps that is a larger can of worms. I was hoping that it could be enabled on a per-type basis with one of these directives, but I'm not sure if that is feasible.

[pkieltyka]

can you give a pseudo example of what you're thinking in the RIDL and we can think how it fits / if we can support it easily?

[rapropos]

struct OrdinaryThing
    - name: string
    - cost?: uint32

struct Person
    + rtti # defaults to __typename if no field name specified
    - id: string
    - name: string

struct Place
    + rtti = __nonStandardRTTIField
    - id: string
    - name: string

I think the biggest hurdle would be the fact that there is no meta information on structs, just on fields. Having meta information on structs would also help me with another problem I'm running into, which is related to the type alias PR that is currently sitting around. I have a ton of timestamp fields where it is perfectly acceptable to have them as strings over the wire, but on the Golang side of the equation, I would like to be able to specify that all of them should be + go.field.type = pgtype.Timestamptz. Currently, I have to do this for every single field in every single struct.

What I'm currently doing for a workaround on the RTTI is adding it on the Typescript side of the bridge in the method generator, because we have the type information there. The field itself is optional in the interface, so the TS side doesn't need to add it (which also parallels the way GraphQL input types work). The Golang side doesn't have to send it over the wire, so it doesn't add any additional network overhead. It's "all or nothing" now, though, in that there's no way to opt in or out of the RTTI field on a per-type basis - all structs get it.

Let me know if that answers your question. I am certainly willing to throw together a PR for typescript-gen if there is interest, but I'm sure the way that I have implemented it is highly ugly.

While I have you on the line, thanks so much for the library. It is effectively a codegened version of a TypeScript/Golang stack idiom that I have been handrolling versions of for years now, so it is really intuitive for me.

Once I get some free time, perhaps I will have a go at writing a JetBrains IDEA plugin for RIDL, assuming nobody else has tackled that.