Upstreaming graphql-jit

[ruiaraujo]

Hey, I am maintaining a high performance execution engine which I have named graphql-jit.

I was wondering whether there would be interest in merging that work with this project and expose both engines to the user.

For the record, this approach is between 10 to 50x faster than graphql-js so I think the community could benefit a lot. Also it is reasonably battle tested having been running in production for 9 month @ Zalando.

[ruiaraujo]

@IvanGoncharov Can you suggest next steps to help with the exploration needed?

[IvanGoncharov]

@ruiaraujo I think it's hard to make "one size fits all" type of execute.
Another example would be https://github.com/mesosphere/reactive-graphql
So I think we should focus on making more parts of graphql-js reusable and allow developers to focus on making 3rd-party modules to solve different needs.
Also a big part of current graphql-js execute inefficiency is that we operate on AST and duplicate a lot of things for every item in response (coercing args, collecting fields, etc.).

So I think a way forward would be to experiment with intermediate stage something like "query plan" in DB engines with all fields collected (based on @include/@exclude and spreads), all arguments validated and coerced, etc.
This will allow for extremely small execute replacement (probably as low as a few hundred lines) that extremely easy to maintain.

I was wondering whether there would be interest in merging that work with this project and expose both engines to the user.

One of the problems is that graphql-js is reference implementation and it means source code should be easily portable to new platforms/languages. So we can't have a dependency on "JSON Schema" package or use eval since not every language supports it.

Plus if we merge you engine we need to implement support for all dynamic features that we have e.g. global fieldResolver/typeResorver:

graphql-js/src/execution/execute.js

Lines 128 to 129 in 8aef229

	fieldResolver?: ?GraphQLFieldResolver<any, any>,
	typeResolver?: ?GraphQLTypeResolver<any, any>,

and this can significantly complicate generated code and make it slower.

[ruiaraujo]

The last point is the critical one.

Would graphql-jit have to implement every feature from the start?
Because I think it will be possible to add support for more dynamic features without significantly harming performance but it will take time because it requires the engine to mature.

The other crutial question is about the reference implementation. It is true that the code today makes it easy to learn the spec and one can jump from the implementation to the spec and vice-versa. This is an important educational role.
However, that means that its performance will probably be never optimal.

About the middle ground solution where AST checks and coercion is done once, we went with this path initially and while the improvements were nice (I remember something 1.2x to 2x) they were not on the magnitude we were looking for.

Also the JSON schema dependency is for a small feature that is being extracted out. eval is indeed a critical feature hence the suggestion to have this as an option for performance sensitive users.