-
Notifications
You must be signed in to change notification settings - Fork 423
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
Integration with Shio framework. #96
Comments
The iron and rocket integrations were initially part of the library, but were extracted into their own crates, so all other framework integrations also should live in their own crates. These crates are mostly some small glue code, so I think we'd definitely accept a Regarding async, I have a lengthy comment regarding my vision for async which I haven't posted yet, but I'm very interested in async as will, and think it's crucial for scalable production grade GraphQL! |
I've built an integration with the gotham framework. Was very simple to get up and running. No need for this issue anymore. |
@thedodd would you find it sensible to release a We'd be happy to accept it into the repo. |
Otherwise, just a link to some open source example code would probably help users a lot. |
@theduke did you ever post that lengthy comment regarding async IO ? Really curious how this can be dealt with. |
Shio is a promising framework which has cropped up over the last few months. It has some immense throughput potential with async I/O distributed across a threadpool of event loops. It would be awesome to build out an integration with this framework, perhaps as a pre-built integration, or in a separate crate.
Integration with a framework that can achieve async I/O level throughput is critical for production adoption of Juniper in my case.
Currently I'm using a nodejs implementation, and being able to use Rust for this would be a huge win 🙌 . I use a lot of Go as well, but I greatly prefer Rust and use it where I can, and the Go graphql libs are not so awesome, IMHO.
I've looked at the discussion going on in the #2
interop with async
issue. Being able to take a stab at it, to see where the walls are, may be beneficial. I would love to spike this, but I definitely wanted to get some discussion going around this.Any and all feedback is welcome.
Great work on this lib so far. Once the async I/O story is g2g, I can definitely see this as being the most solid, convenient, productive, and powerful GraphQL option across the field of languages to chose from.
The text was updated successfully, but these errors were encountered: