#I could reintrospect the function to
steep mountain
For Go, we match it up by the name of the arg: https://github.com/sipsma/dagger/blob/d1df79bc2b8edab6835177fb9e38d9112a09cca2/sdk/go/server.go#L345-L345
So when args are provided to server.go, they are in json with the name of the arg mapped to its value.
Then when we invoke the function, we know the name of each arg at each position due to ast parsing. That lets us map them consistently
clever ridge
Oh that's lucky, we do not have this luxury in Typescript, so I might need to reintrospect
Not optimized but that'll do for now
steep mountain
Oh by "reintrospect" you mean running the introspection again when invoking the function? If so, yeah that's actually exactly what Go does too. It's indeed extremely not optimized, but that's okay for now, it's still usable.
In the longer term we can optimize that more by saving some data during the initial introspection while generating the schema, which can be used later to save time when invoking resolvers.
Or in the even longer term if we want to go all the way, we could actually generate code during the schema parsing that sets up optimized invocation of the user's resolvers (somewhat similar to how gqlgen works in go). But that's not worth it at this moment.
clever ridge
I see, what I was thinking about is that the input/dagger.json could simply keep the same order of arguments as the one displayed in the GraphQL schema (which must be the same order as the one defined in the function signature)
This way we have a generic way to send arguments, with only one source of truth (the schema) and that can assure arguments are in the right order.
Because then it become user's responsibility to define the right signature but Dagger will always follow the order
However, I do not know if Go allows custom ordered map, but that could be an easy way to solve the issue for every SDKs
That would be so easy then -> parse input/dagger.json -> get args -> forward them to func
No post treatment require or anything, we simply act as proxy between the gql call and the function (as we actually should haha)
steep mountain
However, I do not know if Go allows custom ordered map, but that could be an eas...
It doesn't, we could change the type of args here though: https://github.com/sipsma/dagger/blob/2cfeb46a2e69b2e65d62a094e193d8d91df5c30a/core/project.go#L342-L350
If we made it an array of k,v pairs like [{"fooArg": "fooVal", "barArg": "barVal"}], then we can easily retain the order both while marshalling and while unmarshalling on the other side in the runtimes.
We'd need to update that project code to get the original order of the args in the schema, but that's do-able too, we have the parsed schema available in the caller of that function: https://github.com/sipsma/dagger/blob/2cfeb46a2e69b2e65d62a094e193d8d91df5c30a/core/project.go#L310
I don't have time to do that atm, but feel free to give it a shot if you have time!