Skip to content
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

Fast(er) serialization #5100

Open
Amnesthesia opened this issue Sep 13, 2024 · 1 comment
Open

Fast(er) serialization #5100

Amnesthesia opened this issue Sep 13, 2024 · 1 comment

Comments

@Amnesthesia
Copy link

Is your feature request related to a problem? Please describe.

We have large reports where we want to return large amounts of data. These reports are generated pretty low level with raw SQL and we use postgres to serialize to JSON, which speeds things up quite a bit.

We've had to sidestep graphql here, and just return the JSON scalar because serializing with GraphQL adds significant overhead.

Describe the solution you'd like

I've looked a bit at #2699 and what graphql-fragment_cache does using RawValue and wondering if there's perhaps a way to get both types, serialization, and speed, for example with a different base object that doesn't resolve values in any other way than pick out hash keys, e.g RawObject or something like that

Describe alternatives you've considered

Just return raw_value and set the return type to JSON scalar, but this leaves us with no typing for that resolver

Additional context

Add any other context or screenshots about the feature request here.

@rmosolgo
Copy link
Owner

Hey, thanks for the detailed writeup. Off the top of my head, I don't know a way to make serialization faster. I would have suggested RawObject, but as you noticed, that skips type-safety.

I have certainly done all the performance improvements I can find. At this point, we either need:

  • Detailed profiles (stackprof, whatever) that show where time is spent for your query in particular. Then we could investigate those codepaths and see what can be improved.
  • Or, a moonshot. For example, GraphQL-Ruby could be faster if it never encountered any kind of batch loading, it could skip a lot of steps. But I don't know a reasonable way to ensure that it never encountered a Promise, etc. (It could be manually configured, but that's so clunky...) Or maybe some kind of query "compiler" which builds plain-Ruby code for known-good queries. Or something else?

So, I don't have an easy fix in mind, but if you're interested in exploring a bit, you definitely have my attention!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants