Closed trevorturk closed 3 years ago
Other approaches more than welcome, favorite so far is
rails-async-http-falcon-graphql-batch
Another idea is to return Async::Task
objects from resolvers. Then register that class with the GraphQL::Schema
.
class Schema < GraphQL::Schema
query Query
lazy_resolve Async::Task, :wait
end
Resolver methods can now just return an Async::Task
:
def one
Async {
response = internet.get("https://httpbin.org/delay/1").read
JSON.parse(response)["url"]
}
end
You could probably take things further by injecting something that wraps all resolvers with Async {}
to remove that step.
This approach may mean you can avoid the graphql-batch dependency all together.
Thanks for the note, @josh -- I'll try to work up an example app using this style for reference today and report back.
I'm also trying working up an example suggested by @ioquatix https://github.com/trevorturk/async-examples/pull/3 using async-await
but I ran into some trouble there. I'm sure I'm just misunderstanding how this all works, but perhaps this can be a good strategy to avoid graphql batch loaders, which really shouldn't be necessary in my app's use case. (Still, I think the more examples we can provide people the better.)
@josh see https://github.com/trevorturk/async-examples/pull/4 for my attempt to implement your suggestion. The second commit doesn't work, but I'm not understanding why, but I think this seems like a good approach to avoid the batch loader which isn't really necessary in this use case with the Async::HTTP stuff.
We have discussed this and I think this is appropriate for default inclusion into Async::HTTP::Internet
. See https://github.com/socketry/async-http/issues/68
We also discussed improving this: https://github.com/socketry/async-http/issues/67
Investigate rack-async-http-falcon-graphql-dataloader (should work in Ruby 3.1?)
Investigate how the fiber interface is supposed to be used.
I think we covered everything! I have some notes to follow up with docs re preloading and Heroku falcon.rb config once I sort those things out for myself. Thank you again for all of your help so far!
Issues hit when upgrading my existing Rails app:
Protocol::HTTP1::BadRequest
with old VCR cassettes https://github.com/socketry/protocol-http1/issues/11Need examples and/or documentation for the proof of concept sample apps in this repo:
async-await
but running into trouble: https://github.com/trevorturk/async-examples/pull/3lazy_resolve
but not sure about the semaphore(s) https://github.com/trevorturk/async-examples/pull/4internet.close
(?)rails-async-http-falcon-graphql-batch
-- isSync
the appropriate here? Do we needAsync::Barrier
?Async::Clock.measure
or something manual (?)async/http/internet/instance
https://github.com/socketry/async-http/pull/72group :preload
, don't understandpreload.rb
)rack-async-http-falcon-graphql-batch
and https://github.com/socketry/falcon/issues/121#issuecomment-782382561Feature requests:
wait_all
re: https://github.com/socketry/async/pull/89 if/when acceptable (don't need this, can use barriers)rack-async-http-puma-graphql
(not expected to work currently?)rack-async-http-falcon-graphql-dataloader
(should work in Ruby 3.1? Can we make it work now?)For the examples/documentation issues, I'd like to work in the open and/or contribute back to the relevant projects' documentation wherever possible. I'm finding the async suite of tools to be lovely, but the documentation sparse, and I'm hoping to contribute back in an effort to increase adoption.
For the issues found while upgrading my existing Rails app, I'll need to keep that source code private, but happy to work in the open wherever possible, as illustrated by the VCR cassette issue: https://github.com/socketry/protocol-http1/issues/11 since obviously most of these concerns can be generalized.