| 28 Nov 2023 |
 Andy | Source | Edit: We can still auto create them if omitted by the user | 19:59:35 |
 Fred | Source | That is just a normal join | 20:00:05 |
 John | Source | I think this is a nice approach given the constraints of the GQL spec, technically you need to redefine the fields on the implements type that inherits from the interface. | 20:00:48 |
| Fred | Source | That's what I don't like about it. | 20:01:43 |
| John | Source | Yes, and we implement it as a type-join, but the problem is that with GQL strong typing, if you want to query something it must be defined, so you need to define both sides of the relationship on the SDL types | 20:01:45 |
| John | Source | I want to highlight technically, cus we can kinda do w.e we want without entirely breaking spec | 20:02:08 |
| Andy | Source | Was about to write/laugh at the italics there 😄 | 20:02:34 |
| John | Source | eg
interface User {
name: String
}
type Friend implements User {}
| 20:02:46 |
| John | Source | if we used exactly that (open for debate, theres pros and cons) then our system can autofill the implements side of the type | 20:03:09 |
| John | Source | or we can just use directives | 20:03:52 |
| Andy | Source | Yeah, I'd be very tempted by that, especially given how we already auto-create a bunch of fields any way (id, relation ids, maybe secondary halves of a relation, etc) | 20:04:08 |
| Andy | Source | * Yeah, I'd be very tempted by that, especially given how we already auto-create a bunch of fields anyway (id, relation ids, maybe secondary halves of a relation, etc) | 20:04:26 |
| Fred | Source | Except if we follow the specs exactly. But like John said, we don't have to be exact. | 20:06:24 |
| John | Source | note, we would have to automatically create the User type anyway here too, for the introspection stuff.
So the interface User {} would get converted to a type User anyway, just in a way that won't create a cooresponding collection | 20:06:26 |
| Andy | Source | I'm coding something very similar to this atm for views anyway, as I need to define read-only GQL types - so far there seems to be very little work involved, although that is without the compilation of dealing with interface vs type | 20:08:43 |
| John | Source | it walks the line of breaking the spec, but only if ppl want to use their written SDL definitions with other GQL tooling, If however, they regenerate the SDL after it gets processed by our system from the introspection endpoint, then the resulting SDL can be 100% spec compliant | 20:09:32 |
| Andy | Source | If however, they regenerate the SDL after it gets processed by our system from the introspection endpoint, then the resulting SDL can be 100% spec compliant
This is a nice thing to highlight 🙂 | 20:10:11 |
| Andy | Source | I think users should also be free to write spec compliant SDLs, and include the auto-generated stuff explicitly if they want | 20:11:29 |
| John | Source | side note, will create a thread talking about Keenans specific question regarding embedding, which although related, can be discussed independantly to this overall design/modeling convo | 20:11:54 |
| Andy | Source | * I think users should also be free to write spec compliant SDLs, and include the auto-generated stuff explicitly if they want, e.g.:
type Friend implements User {
name String
}
| 20:12:02 |
| John | Source | Object Embedding | 20:12:17 |
| Andy | Source | * I think users should also be free to write spec compliant SDLs, and include the auto-generated stuff explicitly if they want, e.g.:
type Friend implements User {
id DocKey
name String
}
| 20:13:12 |
| Fred | Source | What is a users does this?
type Friend implements User {
id: DocKey
name: String
favouriteSoup: String // not part of User
}
| 20:14:44 |
| Andy | Source | We don't have to allow that if we dont want to | 20:15:04 |
| John | Source | we can have our own independant validation | 20:15:09 |
| John | Source | in addition to the spec | 20:15:33 |
| Andy | Source | If we went this route, I would probably prefer @collections("friend", "boss"), but I do prefer the interface route even though it is a bit more verbose | 20:24:46 |
| Andy | Source | * If we went this route, I would probably prefer an array @collections("friend", "boss"), but I do prefer the interface route even though it is a bit more verbose | 20:25:03 |
| Fred | Source | Using interface for what we want to do, to me, feels like Rust (annoyingly over decorated with it's syntax), while the suggestion by John feels like Go (as simple as it can be and no ambiguity) 😂 | 20:25:58 |
| Fred | Source | I'm exaggerating here but I do feel like the interface approach is a little too fancy | 20:27:08 |
