-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generates a lot of (unnecessary) parse code for non-trivial queries (slowing down bsb) #27
Comments
Yep! This is exactly what I was seeing too and that PR starts to fix this issue. There's a bunch more optimization that can be done as well but just that one gave us a big perf boost. |
@jfrolich @johnhaley81 Should be improved in |
Thanks. But this doesn't really solve the issue for me. The generated code is not that much shorter (maybe 10% shorter). Can't we rely on the GraphQL server to give us the correct data structure (according to the spec). This is how all GraphQL clients work and I think it's acceptable to have a runtime error if the returned data is not correct. In this case the parse function can be omitted (identity). Also in terms of bundle size it's not great to have hundreds/thousands lines of generated (unnecessary) code added for each query. |
Ok, while there are places where we can improve, a lot of code generated is due to how BuckleScript works. Using thinks like Js.Option.getExn helps but I’m not sure in how many places we can replace it. I’ll try to look more into it. |
Yeah I thought so. But isn't there a way to short circuit parse json bucklescript code by an external bucklescript call that yields the known graphql return type shape. |
Resolved in #58 and released as |
@baransu I just updated to 0.6.0 and putting |
@johnhaley81 I merged branch but wasn't targeting master 😂 Sorry for that. Will fix in |
@johnhaley81 Available in |
@baransu it works great!! |
The parse function has a lot of checks on the data, and it looks like it's expanding into hundreds or even thousands of lines of code for non-trivial queries making bsb very slow. In principle the parse function could (almost) be compiled to identity because we always should get back the data in the same way (even if our resolvers change).
I think this is related to mhallin/graphql_ppx#85, but not sure.
Example it generates this code for the following query.
Code:
The text was updated successfully, but these errors were encountered: