🚀 Features
Add support for returning different HTTP status codes in Rhai (Issue #2023)
It is now possible to return different HTTP status codes when raising an exception in Rhai. You do this by providing an object map with two keys: status and message, rather than merely a string as was the case previously.
throw #{
status: 403,
message: "I have raised a 403"
};This example will short-circuit request/response processing and return with an HTTP status code of 403 to the client and also set the error message accordingly.
It is still possible to return errors using the current pattern, which will continue to return HTTP status code 500 as previously:
throw "I have raised an error";It is not currently possible to return a 200 status code using this pattern. If you try, it will be implicitly converted into a 500 error.
Add support for urlencode() / decode() in Rhai (Issue #2052)
Two new functions, urlencode() and urldecode() may now be used to URL-encode or URL-decode strings, respectively.
Experimental 🥼 External cache storage in Redis (PR #2024)
We are experimenting with introducing external storage for caches in the Router, which will provide a foundation for caching things like automated persisted queries (APQ) amongst other future-looking ideas. Our initial implementation supports a multi-level cache hierarchy, first attempting an in-memory LRU-cache, proceeded by a Redis Cluster backend.
As this is still experimental, it is only available as an opt-in through a Cargo feature-flag.
By @garypen and @Geal in #2024
Expose query_plan to ExecutionRequest in Rhai (PR #2081)
You can now read the query-plan from an execution request by accessing request.query_plan. Additionally, request.context also now supports the Rhai in keyword.
🐛 Fixes
Move error messages about nullifying into extensions (Issue #2071)
The Router was previously creating and returning error messages in errors when nullability rules had been triggered (e.g., when a non-nullable field was null, it nullifies the parent object). These are now emitted into a valueCompletion portion of the extensions response.
Adding those messages in the list of errors was potentially redundant and resulted in failures by clients (such as the Apollo Client error policy, by default) which would otherwise have expected nullified fields as part of normal operation execution. Additionally, the subgraph could already add such an error message indicating why a field was null which would cause the error to be doubled.
Fix Float input-type coercion for default values with values larger than 32-bit (Issue #2087)
A regression has been fixed which caused the Router to reject integers larger than 32-bits used as the default values on Float fields in input types.
In other words, the following will once again work as expected:
input MyInputType {
a_float_input: Float = 9876543210
}By @o0Ignition0o in #2090
Assume Accept: application/json when no Accept header is present Issue #1990)
The Accept header means */* when it is absent, and despite efforts to fix this previously, we still were not always doing the correct thing.
@skip and @include implementation for root-level fragment use (Issue #2072)
The @skip and @include directives are now implemented for both inline fragments and fragment spreads at the top-level of operations.
🛠 Maintenance
Use debian:bullseye-slim as our base Docker image (PR #2085)
A while ago, when we added compression support to the router, we discovered that the Distroless base-images we were using didn't ship with a copy of libz.so.1. We addressed that problem by copying in a version of the library from the Distroless image (Java) which does ship it. While that worked, we found challenges in adding support for both aarch64 and amd64 Docker images that would make it less than ideal to continue using those Distroless images.
Rather than persist with this complexity, we've concluded that it would be better to just use a base image which ships with libz.so.1, hence the change to debian:bullseye-slim. Those images are still quite minimal and the resulting images are similar in size.
Update apollo-parser to v0.3.2 (PR #2103)
This updates our dependency on our apollo-parser package which brings a few improvements, including more defensive parsing of some operations. See its CHANGELOG in the apollo-rs repository for more details.
📚 Documentation
Fix example helm show values command (PR #2088)
The helm show vaues command needs to use the correct Helm chart reference oci://ghcr.io/apollographql/helm-charts/router.