Research
Security News
Quasar RAT Disguised as an npm Package for Detecting Vulnerabilities in Ethereum Smart Contracts
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
graphql-query-rewriter
Advanced tools
[![CircleCI](https://circleci.com/gh/graphql-query-rewriter/core/tree/master.svg?style=shield)](https://circleci.com/gh/ef-eng/graphql-query-rewriter/tree/master) [![Coverage Status](https://coveralls.io/repos/github/chanind/graphql-query-rewriter/badge.s
Seamlessly turn breaking GraphQL schema changes into non-breaking changes by rewriting queries in middleware.
Full API docs are available at https://ef-eng.github.io/graphql-query-rewriter
GraphQL is great at enforcing a strict schema for APIs, but its lack of versioning makes it extremely difficult to make changes to GraphQL schemas without breaking existing clients. For example, take the following query:
query getUserById($id: String!) {
userById(id: $id) {
...
}
}
Oh no! We should have used ID!
as the type for userById(id)
instead of String!
, but it's already in production! Now if we change our schema to use ID!
instead of String!
then our old clients will start getting the error Variable "$id" of type "String!" used in position expecting type "ID!"
. Currently your only options are to continue using the incorrect String!
type forever (eeew), or make a new query with a new name, like userByIdNew(id: ID!)
(gross)!
Wouldn't it be great if you could change the schema to use ID!
, but just silently replace String!
in old queries with ID!
in your middleware so the old queries will continue to work just like they had been?
GraphQL Query Rewriter provides a way to rewrite deprecated queries in middleware so they'll conform to your new schema without needing to sully your API with awkwardly renamed and deprecated fields like doTheThingNew
or doTheThingV3
.
In the above example, we can set up a rewrite rule so that userById(id: String!)
will be seamlessly rewritten to userById(id: ID!)
using the following middleware (assuming express-graphql):
import { FieldArgTypeRewriter } from 'graphql-query-rewriter';
import { graphqlRewriterMiddleware } from 'express-graphql-query-rewriter';
const app = express();
// set up graphqlRewriterMiddleware right before graphQL gets processed
// to rewrite deprecated queries so they seamlessly work with your new schema
app.use('/graphql', graphqlRewriterMiddleware({
rewriters: [
new FieldArgTypeRewriter({
fieldName: 'userById',
argName: 'id',
oldType: 'String!',
newType: 'ID!'
}),
]
}));
app.use('/graphql', graphqlHTTP( ... ));
...
Now, when old clients send the following query:
query getUserById($id: String!) {
userById(id: $id) {
...
}
}
It will be rewritten before it gets processed to:
query getUserById($id: ID!) {
userById(id: $id) {
...
}
}
Now your schema is clean and up to date, and deprecated clients keep working! GraphQL Schema Rewriter can rewrite much more complex queries than just changing a single input type as well.
Installation requires the base package graphql-query-rewriter
and a middleware adapter for the web framework you use. Currently works with express-graphql
and apollo-server
.
npm install graphql-query-rewriter express-graphql-query-rewriter
Apollo server works with express-graphql-query-rewriter
via Apollo server middleware.
npm install graphql-query-rewriter express-graphql express-graphql-query-rewriter
First you need to set up an appropriate middleware for your server.
With express-graphql, you can use the express-graphql-query-rewriter
middleware. This middleware goes directy before your graphql
handler in express:
import { graphqlRewriterMiddleware } from 'express-graphql-query-rewriter';
...
// graphqlRewriterMiddleware should go directly before the graphQL handler
app.use('/graphql', graphqlRewriterMiddleware({
rewriters: [ /* place rewriters here */]
})
app.use('/graphql', graphqlHTTP( ... ));
...
Apollo-server can also use the express-graphql-query-rewriter
middleware like below:
const { ApolloServer, gql } = require("apollo-server-express");
const express = require("express");
const { graphqlRewriterMiddleware } = require("express-graphql-query-rewriter");
// configure ApolloServer as usual
const server = new ApolloServer({ typeDefs, resolvers });
const app = express();
const path = "/graphql";
app.use(
path,
graphqlRewriterMiddleware({
rewriters: [ /* place rewriters here */]
})
);
server.applyMiddleware({ app, path, bodyParserConfig: false });
...
Note that you need to specify bodyParserConfig: false
in applyMiddleware()
since express-graphql-query-rewriter
already parses the graphQL body in order to rewrite it.
FieldArgTypeRewriter
rewrites the type of an argument to a graphQL query or mutation. For example, to change from Int
to Int!
in a mutation called doTheThing(arg1: Int)
you could add the following:
import { FieldArgTypeRewriter } from 'graphql-query-rewriter';
// add this to the rewriters array in graphqlRewriterMiddleware(...)
const rewriter = new FieldArgTypeRewriter({
fieldName: 'doTheThing',
argName: 'arg1',
oldType: 'Int',
newType: 'Int!'
});
Sometimes, you'll need to do some preprocessing on the variables submitted to the rewritten argument to make them into the type needed by the new schema. You can do this by passing in a coerceVariable
function which returns a new value of the variable. For example, the following changes the value of arg1
from Int!
to String!
, and also changes the value of arg1
to a string as well:
import { FieldArgTypeRewriter } from 'graphql-query-rewriter';
// add this to the rewriters array in graphqlRewriterMiddleware(...)
const rewriter = new FieldArgTypeRewriter({
fieldName: 'doTheThing',
argName: 'arg1',
oldType: 'Int!',
newType: 'String!'
coerceVariable: (val) => `${val}`,
})
FieldArgNameRewriter
rewrites the name of an argument to a graphQL query or mutation. For example, to change an argument name from userID
to userId
in a mutation called createUser(userID: ID!)
you could add the following:
import { FieldArgNameRewriter } from 'graphql-query-rewriter';
// add this to the rewriters array in graphqlRewriterMiddleware(...)
const rewriter = new FieldArgNameRewriter({
fieldName: 'createUser',
oldArgName: 'userID',
newArgName: 'userId'
});
FieldArgsToInputTypeRewriter
can be used to move mutation parameters into a single input object, by default named input
. It's a best-practice to use a single input type for mutations in GraphQL, and it's required by the Relay GraphQL Spec. For example, to migrate the mutation createUser(username: String!, password: String!)
to a mutation with a proper input type like:
mutation createUser(input: CreateUserInput!) { ... }
type CreateUserInput {
username: String!
password: String!
}
we can make this change with the following rewriter:
import { FieldArgsToInputTypeRewriter } from 'graphql-query-rewriter';
// add this to the rewriters array in graphqlRewriterMiddleware(...)
const rewriter = new FieldArgsToInputTypeRewriter({
fieldName: 'createUser',
argNames: ['username', 'password'],
inputArgName: 'input' // inputArgName can be left out to use 'input' by default
});
For example, This would rewrite the following mutation:
mutation createUser($username: String!, $password: String!) {
createUser(username: $username, password: $password) {
...
}
}
and turn it into:
mutation createUser($username: String!, $password: String!) {
createUser(input: { username: $username, password: $password }) {
...
}
}
ScalarFieldToObjectFieldRewriter
can be used to rewrite a scalar field into an object selecing a single scalar field. For example, imagine there's a User
type with a full_name
field that's of type String!
. But to internationalize, that full_name
field needs to support different names in different languges, something like full_name: { default: 'Jackie Chan', 'cn': '成龙', ... }
. We could use the ScalarFieldToObjectFieldRewriter
to rewriter full_name
to instead select the default
name. Specifically, given we have the schema below:
type User {
id: ID!
full_name: String!
...
}
and we want to change it to
type User {
id: ID!
full_name: {
default: String!
en: String
cn: String
...
}
...
}
we can make this change with the following rewriter:
import { ScalarFieldToObjectFieldRewriter } from 'graphql-query-rewriter';
// add this to the rewriters array in graphqlRewriterMiddleware(...)
const rewriter = new ScalarFieldToObjectFieldRewriter({
fieldName: 'full_name',
objectFieldName: 'default'
});
For example, This would rewrite the following query:
query getUser(id: ID!) {
user {
id
full_name
}
}
and turn it into:
query getUser(id: ID!) {
user {
id
full_name {
default
}
}
}
JsonToTypedObjectRewriter
can be used to rewrite a field that previously is just freeform JSON into a typed graphQL field with proper selections and subseelctions. For example, imagine there's a user
query with type JSON, like user: { type: GraphQLJSON }
. However, we'd like to improve our API by properly typing the fields within user
using a graphQL type named User
with fields id
, name
, isAdmin
, etc.... For example, we have:
query {
user
}
and we want to change it to
query {
user {
id
name
isAdmin
}
}
we can make this change with the following rewriter:
import { JsonToTypedObjectRewriter } from 'graphql-query-rewriter';
// add this to the rewriters array in graphqlRewriterMiddleware(...)
const rewriter = new JsonToTypedObjectRewriter({
fieldName: 'user',
objectFields: [
{ name: 'id' },
{ name: 'name' },
{ name: 'isAdmin' },
]
});
This rewriter also supports rewriting subfields recursively by adding a subfields
array inside of an object field. For example, the rewriter below:
import { JsonToTypedObjectRewriter } from 'graphql-query-rewriter';
// add this to the rewriters array in graphqlRewriterMiddleware(...)
const rewriter = new JsonToTypedObjectRewriter({
fieldName: 'user',
objectFields: [
{ name: 'id' },
{ name: 'name' },
{
name: 'posts'
subfields: [
{ name: 'id' },
{ name: 'title' },
]
},
]
});
would rewrite query { user }
into:
query {
user {
id
name
posts {
id
title
}
}
}
NestFieldOutputsRewriter
can be used to move mutation outputs into a nested payload object. It's a best-practice for each mutation in GraphQL to have its own output type, and it's required by the Relay GraphQL Spec. For example, to migrate the mutation createUser(input: CreateUserInput!): User!
to a mutation with a proper output payload type like:
mutation createUser(input: CreateUserInput!) CreateUserPayload
type User {
id
username
}
type CreateUserPayload {
user: User!
}
we can make this change with the following rewriter:
import { NestFieldOutputsRewriter } from 'graphql-query-rewriter';
// add this to the rewriters array in graphqlRewriterMiddleware(...)
const rewriter = new NestFieldOutputsRewriter({
fieldName: 'createUser',
newOutputName: 'user',
outputsToNest: ['id', 'username']
});
For example, This would rewrite the following mutation:
mutation createUser(input: CreateUserInput!) {
createUser(input: $input) {
id
username
}
}
and turn it into:
mutation createUser(input: CreateUserInput!) {
createUser(input: $input) {
user {
id
username
}
}
}
Sometimes you need more control over which fields get rewritten to avoid accidentally rewriting fields which happen to have the same name in an unrelated query. This can be accomplished by providing a list of matchConditions
to the RewriteHandler
. There are 3 built-in match condition helpers you can use to make this easier, specifically fragmentMatchCondition
, queryMatchCondition
, and mutationMatchCondition
. If any of the conditions passed in to matchConditions
match, then the rewriter will proceed as normal.
For example, to restrict matches to only to the title
field of fragments named thingFragment
, on type Thing
, we could use the following matchConditions
:
import { fragmentMatchCondition, ScalarFieldToObjectFieldRewriter } from 'graphql-query-rewriter';
const rewriter = new ScalarFieldToObjectFieldRewriter({
fieldName: 'title',
objectFieldName: 'text',
matchConditions: [
fragmentMatchCondition({
fragmentNames: ['thingFragment'],
fragmentTypes: ['Thing']
})
]
});
Then, this will rewrite the following query as follows:
query {
articles {
title # <- This will not get rewritten, it doesn't match the matchConditions
things {
...thingFragment
}
}
}
fragment thingFragment on Thing {
id
title # <- This will be rewritten, because it matches the matchConditions
}
You can also pass a pathRegexes
array of regexes to fragmentMatchCondition
if you'd like to restrict the path to the object field within the fragment that you'd like to rewrite. For example:
const rewriter = new ScalarFieldToObjectFieldRewriter({
fieldName: 'title',
objectFieldName: 'text',
matchConditions: [
fragmentMatchCondition({
// rewrite only at exatly path innerThing.title
pathRegexes: [/^innerThing.title$/]
})
]
});
Then, this will rewrite the query below as follows:
query {
things {
...parentThingFragment
}
}
fragment parentThingFragment on Thing {
id
title # <- not rewritten, it's not at the correct path
innerThing {
title # <- This will be rewritten, it's at path innerThing.title
}
}
There are also queryMatchCondition
and mutationMatchCondition
. These work similarly to fragmentMatchCondition
, except they match only fields directly inside of a query or a mutation, respectively.
All of these matches take pathRegexes
to search for matching paths, but queryMatchCondition
can also take queryNames
, to match only named queries, and likewise mutationMatchCondition
can take mutationNames
to match named mutations.
If there are multiple matchConditions
provided, then if any of the conditions match then the rewriter will continue as normal. For example:
const rewriter = new ScalarFieldToObjectFieldRewriter({
fieldName: 'title',
objectFieldName: 'text',
matchConditions: [
fragmentMatchCondition({
fragmentNames: ['thingFragment']
}),
queryMatchCondition({
queryNames: ['getThing', 'getOtherThing']
})
]
});
The above rewriter will only match on fragments named thingFragment
, or queries named getThing
or getOtherThing
.
Currently GraphQL Query Rewriter can only work with a single operation per query, and cannot properly handle aliased fields. These limitations should hopefully be fixed soon. Contributions are welcome!
GraphQL Query Rewriter is released under a MIT License.
Contributions are welcome! These steps will guide you through contributing to this project:
Fork the repo
Clone it and install dependencies
git clone https://github.com/ef-eng/graphql-query-rewriter
yarn install
Make and commit your changes. Make sure the commands yarn run build and yarn run test:prod are working.
Finally send a GitHub Pull Request with a clear list of what you've done. Make sure all of your commits are atomic (one feature per commit). Please add tests for any features that you add or change.
FAQs
[![CircleCI](https://circleci.com/gh/graphql-query-rewriter/core/tree/master.svg?style=shield)](https://circleci.com/gh/ef-eng/graphql-query-rewriter/tree/master) [![Coverage Status](https://coveralls.io/repos/github/chanind/graphql-query-rewriter/badge.s
The npm package graphql-query-rewriter receives a total of 534 weekly downloads. As such, graphql-query-rewriter popularity was classified as not popular.
We found that graphql-query-rewriter demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket researchers uncover a malicious npm package posing as a tool for detecting vulnerabilities in Etherium smart contracts.
Security News
Research
A supply chain attack on Rspack's npm packages injected cryptomining malware, potentially impacting thousands of developers.
Research
Security News
Socket researchers discovered a malware campaign on npm delivering the Skuld infostealer via typosquatted packages, exposing sensitive data.