geek/graphi

hapi graphql plugin

graphi's Issues

Support hapi routes as resolvers

Update to graphql 1.0

Server route payload configuration

Support plan

• is this issue currently blocking your project? yes/no): yes
• is this issue affecting a production system? (yes/no): yes

Context

• node version: v17.2.0
• module version: ^9.0.0
• environment (e.g. node, browser, native): node
• used with (e.g. hapi application, another framework, standalone, ...): Hapi application
• any other relevant information: related to Hapi route config.payload.maxBytes property

How can we help?

Hi, currently Im facing an issue with image uploads, and receiving "Request entity too large". I've managed to track this down to the config.payload.maxBytes option included in the server.route configuration, by manually editing my local node_modules/graphi to contain the property. I was wondering if there was anyway I could either:

• Externally configure this property / all config (through some parameter or config Im missing).
• Mutate the Hapi route after registration occurs in the library.

Line in question

Thanks in advance for the help!

Add makeExecutableSchema()

Closed by 99bcb8a

Support hapi authStrategies

@geek what do you think about adding support for hapi authStrategies?

My PR #6 adds the feature.

Details:

• authStrategy defaults to false when not set in options.
• authStrategy applies a hapi auth strategy to the
  graphql query route. ./graphql is the default graphi query route.
• If authStrategy is configured, all queries to the ./graphql route fail
  without a valid token in the header of the request.
• 100% test coverage.
  All tests are performed using 'hapi-auth-bearer-token'.
• New dev dependency 'hapi-auth-bearer-token'.
• New feature does not effect previous operations.

how to apply authentication only on resolvers that require authentication and not to all resolvers

Hello Sir, when applying an authentication strategy (for example jwt) to the option: authStrategy this means that no graphql request can be made if there is no authentication token sent. Since some graphql resolvers will require authentication and not others, my question is how to apply authentication only on resolvers that require authentication and not to all resolvers. thanks

Support callback style resolvers

Passing context to resolvers

I'm working on migrating from hapi-graphql-2 and one of the things I'm stuck on is its context object. I used it to easily pass in the ORM models, current user, and a reference to a REST API.

There isn't anything like it in your library, is there? I looked around but couldn't find it.

(Obviously, I can just put these various references in the code but I liked the "cleanliness" of defining it at plugin registration and relying on its presence.)

not handling nested queries

it('will handle nested queries', (done) => {
  const schema = `
    type Person {
      firstname: String!
      lastname: String!
      friends(firstname: String): [Person]!
    }

    type Query {
      person(firstname: String!): Person!
    }
  `;

  const getPerson = function (args, request) {
    expect(args.firstname).to.equal('billy');
    expect(request.path).to.equal('/graphql');
    expect(args.friends).to.equal({ firstname: 'jose' });

    return new Promise((resolve) => {
      resolve({ firstname: 'billy', lastname: 'jean', friends: [] });
    });
  };

  const resolvers = {
    person: getPerson
  };

  const server = new Hapi.Server();
  server.connection();
  server.register({ register: Graphi, options: { schema, resolvers } }, (err) => {
    expect(err).to.not.exist();
    const payload = { query: '{ person(firstname: "billy") { friends(firstname: "jose") { lastname } } }' };

    server.inject({ method: 'POST', url: '/graphql', payload }, (res) => {
      expect(res.statusCode).to.equal(200);
      const result = JSON.parse(res.result);
      expect(result.data.person.lastname).to.equal('jean');
      done();
    });
  });
});

Unable to add custom resolver for a custom scalar

Support plan

• is this issue currently blocking your project? (yes/no): no
• is this issue affecting a production system? (yes/no): no

Context

• node version: v14.16.0
• module version with issue: 9.0.0
• last module version without issue: N/A
• environment (e.g. node, browser, native): node
• used with (e.g. hapi application, another framework, standalone, ...): hapi application
• any other relevant information:

What are you trying to achieve or the steps to reproduce?

const ISODateString = new GraphQLScalarType({
  name: 'ISODateString',
  description: 'An ISO 8601 formatted date string',
  parseValue(value) {
    return new Date(value);
  },
  serializeValue(value) {
    return value.toISOString();
  },
  parseLiteral(ast) {
    switch (ast.kind) {
      case Kind.STRING:
        return new Date(ast.value);
      default:
        return null;
    }
  }
});

const schema = server.makeExecutableSchema({
  schema: mergeTypeDefs(typesArray, {
    commentDescriptions: true
  }),
  resolvers: { ISODateString }
});

What was the result you got?

AssertionError [ERR_ASSERTION]: ISODateString.name resolver must be a function
    at internals.Server.exports.makeExecutableSchema (/code/node_modules/graphi/lib/utils.js:26:7)
    at Object.register (/code/node_modules/graphi-aws/lib/index.js:34:25)
    at internals.Server.register (/code/node_modules/@hapi/hapi/lib/server.js:500:35)
    at async main (/code/server.js:115:5) {
  generatedMessage: false,
  code: 'ERR_ASSERTION',
  actual: false,
  expected: true,
  operator: '=='
}

What result did you expect?

I expected the ISODateString resolver to successfully override the ISODateString type in the schema.

3.0.0 Release Notes

Summary

3.0.0 drops reliance on the apollo core server module. Instead, compatibility is maintained by depending directly on graphql. Additionally, there is now better validation of the incoming query against the schema.

Other than removing an unnecessary dependency, this release achieves 100% code coverage.

Breaking Changes

Return a 400 when the request query includes features that the graphql schema can't support. For example, if you are making a request with graphql directives and the schema can't process them, they will no longer fail silently, instead you get a 400 response.

Support resolver routes configured with a prefix