[yeneek]

I had some issues with typegraphql years ago. I tried to split resolvers between modules and it behaved weirdly during unit tests. We also already used graphql-compose at job, so I wrote my own typescript decorator based solution on top of graphql-compose (https://github.com/captain-refactor/graphql-compose-typescri...) My module worked as expected, and I tried it on my personal projects. Then I realized, how my projects code became confusing and result api was really bad. I abandoned development of the module, because it had flawed design from the start. The code-first approach doesn't really work well and result graphql schema is ugly, which makes it a bad solution. Generating typescript from schema gives better results. When you think about it, it makes sense, because your graphql schema is your applications api blueprint and it should be designed in advance, not generated from the result product. Also when I wrote idiomatic typescript code, it generated bad graphql schema structure. It's hard to create consistent api when it's scattered over many files filled with implementation details.