50009b66ce
This completely overhauls the error system used in async-graphql. - `Error` has been renamed to `ServerError` and `FieldError` has been renamed to just `Error`. This is because `FieldError` is by far the most common error that users will have to use so it makes sense to use the most obvious error name. Also, the current name didn't make sense as it was used for things other than field errors, such as the data callback for websockets. - `ServerError` has been made completely opaque. Before it was an enum of all the possible errors, but now it just contains an error message, the locations, the path and extensions. It is a shame that we lose information, it makes more sense as _conceptually_ GraphQL does not provide that information. It also frees us to change the internals of async-graphql a lot more. - The path of errors is no longer an opaque JSON value but a regular type, `Vec<PathSegment>`. The type duplication of `PathSegment` and `QueryPathSegment` is unfortunate, I plan to work on this in the future. - Now that `ServerError` is opaque, `RuleError` has been removed from the public API, making it simpler. - Additionally `QueryError` has been completely removed. Instead the error messages are constructed ad-hoc; I took care to never repeat an error message. - Instead of constructing field-not-found errors inside the implementations of field resolvers they now return `Option`s, where a `None` value is representative of the field not being found. - As an unfortunate consequence of the last change, self-referential types based on the output of a subscription resolver can no longer be created. This does not mean anything for users, but causes lifetime issues in the implementation of merged objects. I fixed it with a bit of a hack, but this'll have to be looked into further. - `InputValueError` now has a generic parameter - it's kind of weird but it's necessary for ergonomics. It also improves error messages. - The `ErrorExtensions` trait has been removed. I didn't think the `extend` method was necessary since `From` impls exist. But the ergonomics are still there with a new trait `ExtendError`, which is implemented for both errors and results. - `Response` now supports serializing multiple errors. This allows for nice things like having multiple validation errors not be awkwardly shoved into a single error. - When an error occurs in execution, data is sent as `null`. This is slightly more compliant with the spec but the algorithm described in <https://spec.graphql.org/June2018/#sec-Errors-and-Non-Nullability> has yet to be implemented. |
||
---|---|---|
.. | ||
actix-web | ||
rocket | ||
tide | ||
warp | ||
README.md |
Integrations for async-graphql
This directory provides various integrations for async-graphql
to various crates in the ecosystem.
Requirements for an HTTP integration
This is a list of criteria for HTTP integrations with async-graphql
in order to make sure all
integrations are implemented consistently. Currently not all integrations follow this criteria, but
we are working on it.
Integrations may provide additional functionality to better integrate with the specific library, but they must all internally use the below functions.
- Conversion from HTTP library's request to
async_graphql::BatchRequest
:- If the request is a
GET
request:- Return the request's query parameters deserialized as an
async_graphql::Request
.
- Return the request's query parameters deserialized as an
- Otherwise:
- Get the request's
Content-Type
header. - Call
async_graphql::http::receive_batch_body
on the request's body. - Convert
ParseRequestError::PayloadTooLarge
to a 413 Payload Too Large response. - Convert all other errors to a 400 Bad Request response.
- Get the request's
- If the request is a
- Conversion from HTTP library's request to
async_graphql::Request
:- Call the above function to convert the request to an
async_graphql::BatchRequest
. - Call
BatchRequest::into_single
on the result. - Convert all errors to a 400 Bad Request response.
- Call the above function to convert the request to an
- Conversion from
async_graphql::BatchResponse
to HTTP library's response:- Create a 200 OK response.
- If the GraphQL response is ok, set the response's
Cache-Control
header to the response's cache control value. - Set the response's body to the GraphQL response serialized as JSON, also setting the
Content-Type
header toapplication/json
.
- GraphQL over websocket support:
- Create an
async_graphql::http:WebSocket
usingasync_graphql::http::WebSocket::with_data
. - Support the basics of the websocket protocol:
- Respond to ping messages with pong messages.
- Treat continuation messages identically to data messages.
- Stream all websocket messages that send data (bytes/text/continuations) to the
async_graphql::http::WebSocket
. - Convert all responses to websocket text responses.
- Create an