banterfm / graphql-crunch Goto Github PK

I encountered that Apollo would error on { crunched: Object, version:number } response due to its parseAndCheckHttpResponse method looking for data and errors keys and finding those above. To make things worse we have to make it friendly with batchedHttpLink, it crunches responses across all responses in the batch array. What do you use crunch v2 with?

Actual response

{
  "data": {
    "notifications": [
      {
        "id": "16",
        "createdAt": "2019-05-04T17:10:40.509Z"
      },
  }
}

crunched response:

{
  "data": [
    "16",
    {},
    {
      "id": 0,
      "createdAt": 1
    },
    [
      2
    ]
  ]
}

somehow the createdAt converted into empty object

version: 1

Trying to implement this wi react native and Apollo Client, but dynamically calling require does not work.

Since the codebase has been rewritten to Typescript, it would be great to have a new version published to npm and a github release created.

Hey!
I have most of my (GraphQL) servers written in Rust and wanted to port the algorithm used here to make it compatible with the JS world.

However, I do not really understand the need of the encode function when it comes down to numbers. Why are they multiplied by 2 (and sometimes incremented by 1)?
Additionally, wouldn't multiplying the value by 2 decrease the available number space to half its normal size? Meaning that servers can't use the whole number range?

I want to access the request URL inside formatResponse handler.

const server = new ApolloServer({
  // schema, context, etc...
  formatResponse: (response, options) => {
    const parsed = url.parse(options.context.request.url);
    const query = querystring.parse(parsed.query);

    if(query.crunch && response.data) {
      const version = parseInt(query.crunch) || 1;
      response.data = crunch(response.data, version);
    }

    return response;
  },
});

but the request field is undefined inside const parsed = url.parse(options.context.request.url);

even typescript complains about it.

I know it's related to apollo-server. but it's an example provided in graphql-crunch I think there may be something wrong with this example or maybe with apollo-server

Is it or would it be possible to use with Apollo-Server-Express? I have it setup as follows

Server:

const server = new ApolloServer({
  typeDefs,
  resolvers,
  context: ({ req, res }) => ({
    models,
    user: req.user,
    req,
    res
  }),
  introspection: process.env.NODE_ENV === 'production' ? false : true,
  onHealthCheck: async () => {
    try {
      const result = await onHealthCheck(req, res)
      res.json({ status: 'pass', ...(result || {}) })
    } catch (err) {
      res.status(503).json({ status: 'fail' });
    }
  },
  formatResponse: (response) => {
    if (response.data) {
      response.data = crunch(response.data);
      return response;
    }
  }
});

Client:

const middlewareLink = new ApolloLink((operation, forward) => {
  operation.setContext({
    headers: {
      accessToken: localStorage.getItem('x-access-token') || null,
      refreshToken: localStorage.getItem('x-refresh-token') || null
    }
  });
  // return forward(operation);
  return forward(operation).map((response) => {return uncrunch(response.data)});
});

But am getting the following error message when I attempt to query data
{"errors":[{"message":"crunch is not defined","extensions":{"code":"INTERNAL_SERVER_ERROR","exception":{"stacktrace":["ReferenceError: crunch is not defined"," at Object.formatResponse (D:\\Repos\\DBI\\graphql-apollo\\src\\server.js:71:7)"," at Object.<anonymous> (D:\\Repos\\DBI\\graphql-apollo\\node_modules\\apollo-server-core\\dist\\requestPipeline.js:193:50)"," at Generator.next (<anonymous>)"," at fulfilled (D:\\Repos\\DBI\\graphql-apollo\\node_modules\\apollo-server-core\\dist\\requestPipeline.js:5:58)"," at processTicksAndRejections (internal/process/task_queues.js:97:5)"]}}}]}

To aid in adoption within graphql-yoga and beyond.

See here: dotansimha/graphql-yoga#303 (comment)

I really like graphql-crunch; great work! Out of curiosity, have you considered extending the "crunching" to go all the way into the resolver runtime itself?

I.e. if I've already called authorResolver.name(a1), just don't call that name for a1 again during the rest of this request.

Granted, this would need to rely on __typename+id semantics for identity, and also an understanding from resolvers that they won't change their output based on "where in the graph the object was fetched", i.e. anything in the 4th/info param of the resolver.

But, assuming that was the case, it seems like this could slice off a whole slew of work that apollo/graphql tools puts into making a giant JSON-with-repeated-info tree that graphql-crunch is going to immediately throw away ~70% of.

Thanks!

graphql-crunch doesn't follow the convention of publishing compiled libraries as es5. This can lead to a site appearing to funcion normally while bombing outright on Microsoft Edge. :-(

Please follow this convention. It prevents accidents.

Hi, I tried graphql-crunch on our largest json response: a newsfeed with posts. Common repeating elements are the posting user and associated groups.

Version 1 crunch

• Seems to extract the common elements properly
• The response file size seems actually larger than without crunching

Version 2 crunch

• It extracts common elements at a lower level when extracting at a higher level would be valid and more efficient.
• E.g. a postUser contains a user and an optional impersonated group. Instead of referencing the post user as a whole, it only references the user and impersonated group, repeating the post user structure everywhere.

I do like the fact that v2 is much more readable.

I've attached example files.

posts+crunch.zip

i am getting the following error:

Error: no value resolved
at Object.complete (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/dist/devtools.js:1:695191)
at complete (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/dist/devtools.js:1:376930)
at t.s (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/dist/devtools.js:1:673115)
at t.n.emit (chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/dist/devtools.js:1:307830)
at chrome-extension://jdkknkkbebbapilgoeccciglkfbmbnfm/dist/devtools.js:1:381756

please suggest.

Thanks & Regards
gmchaturvedi

Hey there!

I noticed that the values are given numerical values, but not keys. There seems to be a lot of space savings on that front too.

What was the reason for not applying the same optimizations to keys? GraphQL properties can only be alphabetical characters, so we know that the keys can never be numbers.

Thanks for open sourcing this!

this is more of a suggestion but it would be really nice to be able to have a preview of the API response when using this with Apollo graphql. it would make debugging way easier

This package seems to mimic the behaviour graphql-deduplicator, which has been available for a long-time before graphql-crunch. What is your motivation for maintaining your own implementation and would you not rather contribute to the former library?