accounts/graphql-api without gql-modules

[sakulstra]

We're trying to use accounts-js for a few weeks, but are constantly facing problems with the dependency on graphql-modules.

We don't use graphql-modules for anything else, but accounts-js.
gql-modules usage breaks our custom modules workflow with hard to debug issues we shouldn't face in first place.

import { ApolloServer, makeExecutableSchema } from "apollo-server";

export const schema = makeExecutableSchema({
  typeDefs: modules.filter(m => m.typeDefs).map(m => m.typeDefs),
  resolvers: modules.filter(m => m.resolvers).map(m => m.resolvers),
  schemaDirectives: modules
    .filter(m => m.schemaDirectives)
    .reduce((acc, m) => {
      return {
        ...acc,
        ...m.schemaDirectives
      };
    }, {})
});

Somehow the accounts.typeDefs destroys our subscription setup with:

"message": "Schema is not configured for subscriptions.",

errors.

Would it be possible to have a raw export for graphql-api not using graphql-modules or sth similar?

[NickBolles]

@sakulstra what part of this is accountsjs? Could you add a little bit more context?

I've found (with nest-js/graphql) that it's easiest to take any other Graphql Types or schemas and create a new GraphQLModule with that schema that imports the AccountsJSGraphQLModule like this

export const schema = new GraphQLModule({
          extraSchemas: [anotherGraphQLSchema],
          imports: [accountsJSGraphQLModule]
        }).schemaAsync;

Otherwise if you don't have other types you should be able to do
export const schema = accountsJSGraphQLModule.schemaAsync (or .schema if you want it sync)

I am going to be starting work on a Type-Graphql package for accounts - see #781 which is going to be re-worked.

[sakulstra]

@NickBolles, one entry in modules might be the accounts-js module(we have our own graphql-modules like, but sadly not graphql-modules compatible approach of defining and loading modules).

While this probably works, I currently use another workaround which seems to work as well.

  typeDefs: mergeGraphQLSchemas(
    modules.filter(m => m.typeDefs).map(m => m.typeDefs)
  ),
  resolvers: mergeResolvers(
    modules.filter(m => m.resolvers).map(m => m.resolvers)
  ),

Anyhow, that's not really the point.

I was wondering if gql-modules could be more an "opt-in" kind of thing as we're not planning to use it throughout the codebase.
Currently there's not(to my knowledge) any way to "opt-out" which broke our app multiple times in the past (funny enough the new version not yet in accountsjs v0.7.13 again breaks our codebase due to node incompatibilities in toolkit).

That said I like the idea behind grapqhl-modules it's just not the right tool for us and this shouldn't prevent us from using account-js.

[agustif]

I think this could be closed since it references a really old version of the library, and today you could totally use accountsJS without requiring gql-modules into your app or messing with it?