MichalLytek
InputType vs ArgsType + Architectural Discussion
I'm looking for a reference architecture in order to have all entities described consistently and came up with following. Something like this could be also helpful in the docs but yeah, first I wanted to discuss if this makes sense.
Example blog post entity:
-
interface IPost=> what's is needed to interact with aPostinstance (this could be anything such as all CRUD operations) -
class PostInput implements IPost=> what's is needed to mutate aPostinstance -
class Post implements IPost=> what's needed to persist aPostinstance
The GraphQL surface is always <= than above (so it's equal or a subset).
1 und 2 are more flexible than 3, means e.g. 1. and 2. can consist of optional properties only: When I create a new blog post, there's no need for any input, the idcan come from the DB and initially the post content is empty. For 3, we need to have at least the id as primary key.
Now, I am wondering where @ArgsType() would fit in, I've two options:
(A) Like in the current docs: A dedicated class PostInput and dedicated classes [specific use case]PostArgs, e.g. class GetTodaysPostsArgs, one for every resolver:
@InputType()
class PostInput implements IPost
@ArgsType()
class GetTodaysPostsArgs implements IPost
...
(B) Or just one class PostInput both decorated @InputType() and @ArgsType(); since class PostInput is flexible, every use case should fit, it's DRY and should still give us some type safety, use always class validations (not so if I'd use @Arg from time to time), so something like...
@InputType()
@ArgsType()
class PostMutate implements IPost
Does this make sense?
I would go with something different: https://github.com/MichalLytek/type-graphql/tree/master/examples/mixin-classes
- Create base mixin for simple payload-like properties (user name, email, etc.)
- Then build a dedicated entity/object type class from that mixin with id property and advanced field resolvers
- Then build from the mixin a decicated input type
- You can also construct easier from mixin a dedicated args type for filtering, etc.
Ok, sounds cools, fwiw I charted your example to get a better feeling:
- You used a different mixin style than in the TS handbook https://www.typescriptlang.org/docs/handbook/mixins.html they use some fancy interface declaration merging what's better and why did you choose your style?
- So, actually I should break down everything into atomic classes (as atomic as required) and orchestrate them per use case which can be anything (interacting, mutation, persistence)?!
- Then, it shouldn't be too much effort to have dedicated Input- and ArgTypes since I just put them together like Legos and have hence granular type safety per resolver?!
Does this reflect your thoughts?
You used a different mixin style than in the TS handbook typescriptlang.org/docs/handbook/mixins.html they use some fancy interface declaration merging what's better and why did you choose your style?
TypeScript mixins docs was created before ES2015 which introduced class mixins to JS. The TypeScript mixins doesn't work well, so it's recommended to use class mixins: https://basarat.gitbook.io/typescript/type-system/mixins
Does this reflect your thoughts?
Yes, you should compose the dedicated types from the legos.
In the future (vNext) it will be more powerful with no @XYZType inheritance limitation and partial/required type operators.
Ok, gonna rebuild my stuff as below. Feedback or anything which makes the code maintainable/future-proof/fun is welcome:
One thing is bothering me though: Let's take the mixin class Id: I want that id is optional on class NewPostInput but mandatory on class Post and class GetPost.
How would I model this DRY? Or do I need to two mixins such as class Id and class IdOptional which I mixin depending on the respective classes?
How would I model this DRY? Or do I need to two mixins such as class Id and class IdOptional which I mixin depending on the respective classes?
In the future (vNext) it will be more powerful with (...) partial/required type operators.
So, I found another thing with the current architecture: I use constructors b/c I need to pass express' req object in them since my app is hostname-specific. When I now mixin classes with type-graphql decorators type-graphql/dist/schema/schema-generator.js gets executed without an actual request leading to an error because of the lacking request object.
Otherwise it feels quite slick but I have to solve somehow this constructor args passing...
You should put request/caller related data into GraphQL context and then retrive it in resolvers via @Ctx() decorator.
Then you treat the value in you business logic just like a normal value from file or from database, pass it as a parameters to services, etc.
Hey, sorry for my late reply and thanks for the hint! It required me to rebuild my classes but that was the solution: Before I used new Class() to instantiate new ActiveRecord-like objects which can save themselves etc. but this was too much magic and again required the Context object at instantiation.
So, I just implemented your idea and now every data manipulation happens exclusively over static methods in a class and new Class() is only used to create the instance for run-time validations which is then passed to the DB. IDK if this will give me any road-blockers in future but at the moment it's a satisfying architecture considering all the restrictions/complexity.