type-graphql
type-graphql copied to clipboard
MichalLytek
Recommendation: Benchmarks
It'd be a good idea to have benchmarks against vanilla graphql-yoga plain resolvers. Perhaps keeping it simple and not including the extras of course. Just @Arg / @Context / @Root / @*Type decorators against vanilla graphql, etc.
Might make it easier to help optimize where needed or show the world that class mapping is actually beneficial (because I tried going back to vanilla graphql + manage my own schema and no object mapping and realized how much I enjoy using classes for defining schema)
Building schema from class metadata has no impact on runtime performance. TypeGraphQL is just a wrapper on top of graphql-js reference implementation, as well as graphql-tools used by graphql-yoga.
Things like @arg / @context / @root also has no overhead, as well as simple (implicit) field resolvers. The only overhead is with additional features - handling middlewares stack, authorization, args validation, etc. The only difference might be with creating class instance of root object or args object (it's simple new with assign so no big custom logic like with class-transformer), you can check is src/resolvers that injecting params into methods is just a few simple helper func calls and if-s.
With simple hello world resolvers and simple args it might show some overhead but in real app when you have a lot of api/db calls, validation, authorization and other business logic, the overhead might be even not noticeable.
If you worry about the performance and CPU/RAM usage, it's better to switch to Golang for building microservices. Node.js simplicity and TypeGraphQL abstraction is for quick&easy development of apps 😉
This one looks promissing: https://github.com/LiUGraphQL/LinGBM
@j If you've found other good performance benchmark for GraphQL server implementations, please share it here 😉
Sorry, @19majkel94 saw that there was an issue relating to simple stuff. I too have the need for simple stuff in many cases. His example is on the ad side so latency is everything obviously and every ms counts. You stated that real life stuff needs to be benchmarked (db / http / etc), but I don't think that's the case. I think it should just be simple graphql queries that do raw things... So Object mapping, middlewares, etc.. Optimizations could def be in place in certain areas. I created a global middleware and it gets called 100s of times / request which IMO is already an optimization in itself. DB benchmarks (ORM/etc) could be in the repository on their own.
There's a basic comparison here: https://github.com/benawad/node-graphql-benchmarks
