Closed pospi closed 5 years ago
So, current implementation means there is no clean DRY binding between the GraphQL schema layer and the type system, which is limiting- you basically have to define the object shape twice. The ideal seems possible, but at this stage would appear to mean defining our types in a nonstandard format and having a preprocessor step to build them.
Other than this, I think the last few commits are as good as we're going to get it. Although, if we have strongly typed client-side API helper functions then it's possible (though unlikely) we can pass those type signatures back through the resolve
callbacks when implemented.
Does anyone (esp. @sqykly) have any better ideas on bridging this gap than typed-graphqlify or gql2ts?
Parking this, as the route it's probably going is towards #14- wherein we keep things as they are (no direct linkage between the TypeScript interfaces and the GraphQL schemas); but we try to pull in the types from the DHT so that we don't have to write any new duplicate types for the GraphQL resolver return values.
If this ends up not being easily possible, will revisit this.
Further reading:
This is not intended to be a "production" solution (like #5), just something workable. Some duplication is tolerable; the backend will likely be in a different language in future so consider most code to be eventually targeting the frontend.