Base Query/Mutations

[j]

I was actually working on implementing something similar to this:

https://github.com/j/graphql-party

I just had a complete re-write that I was going to try to push later which has most of the features here, until I saw this library. The code-base is clean and concise and exciting! So good job.

One question that I made sure to implement with my project. Most of my projects have common Query / Mutation functionality. Do you have a query/mutation plugin system or resolver inheritance with the ability to rename fields?

i.e.

// RecipeResolver.ts
@Resolver(objectType => Recipe)
@Use(Deletable, Updatable, Findable)
class RecipeResolver {
  // ...
  @Query(() => Recipe, { array: true })
  favoriteRecipes(): Promise<Array<Recipe>> {
    return this.recipeRepository.findFavorites();
  }
}

// Deletable.ts
function Deletable(name) {
  return class Deletable {
    @Mutation(returnType => Boolean)
    async [`delete${name}`]() {
      // implementation...
    }
  }
]

// Updateable.ts
// ... implementaiton...

// Findable.ts
// ... implementaiton...


// Creates schema:

/*

type Query {
  favoriteRecipes: [Recipe]
  deleteRecipe: Boolean
  Recipe: Recipe
  allRecipes: [Recipe]
}

type Mutation {
  deleteRecipe: Boolean
  updateRecipe: Recipe
}

*/

Thanks!

[MichalLytek]

Taught by experience with routing-controllers, it's better to keep things simple and explicit. We've discussed this topic with @pleerock and I agree with him and this statement:

code you provided does not look good even if it was implementable. In my experience inheritance in controllers never bring somethings really valuable, its only makes things complex and unpredictable. Controllers should be simple as hell and if you have duplication in logic - simply extract this logic into services - thats correct places for such logic. If you have duplication in decorators and routes - thats not an issue, having duplicated route decorators just makes things more explicit. Really really no need to make things complex (and make life harder for everyone except you) with such patterns.

So in your example I would do generic service that handle the logic and just call it 😉

// ResourceService.ts
export class ResourceService<T> {
    private repository: Repository<T>;
    constructor(Entity: ClassType<T>) {
        this.repository = getRepository(Entity);
    }
    find(...args) {
        // implementation
        return this.repository.find(...args);
    }
    update(...args) {
        // implementation
        return this.repository.update(...args);
    }
    delete(...args) {
        // implementation
        return this.repository.delete(...args);
    }
}
``

// RecipeResolver.ts
@Resolver(objectType => Recipe)
class RecipeResolver {
  private recipeService = new ResourceService(Recipe);

  @Query(() => [Recipe])
  recipes() {
    return this.recipeService.find();
  }

  @Mutation(() => Recipe)
  updateRecipe(recipe) {
    return this.recipeService.update(recipe);
  }

  @Mutation(() => Boolean)
  deleteRecipe(id) {
    return this.recipeService.delete(id);
  }

  // the rest is the same
  @Query(() => Recipe, { array: true })
  favoriteRecipes(): Promise<Array<Recipe>> {
    return this.recipeRepository.findFavorites();
  }
}

Of course you can use DI Container instead of private recipeService = new ResourceService(Recipe) as well as extends ResourceService to add some specific methods like favoriteRecipes - just like with good old OOP 😉

Also, TypeGraphQL support inheritance in args/inputs, so you can make your find queries generic.

[j]

Fair enough, fair enough. My implementation wasn't using inheritance. I get that inheritance is overkill. My "plugin" system for Resolvers passed the Resolver instance into the plugin and from there created queries and mutations. So the plugin created a brand new Resolver class that the RecipeResolver really didn't have to know about. I.E, RecipeResolver could extend a BaseResolver which has a constructed service for manipulation (all things crud), and the plugins takes in resolver: BaseResolver and creates new queries and mutations accordingly. The created plugin resolver doesn't get mixed in, inherited by, etc. Just gets put into the final built schema.

I don't know when anyone would ever care about resolver inheritance because that's all internal to this project and a use never should worry about a decorated resolver instance.

And when writing tests, as long as the plugin is tested, all you need to check is that the resolver contains that plugin.

[MichalLytek]

It's not just about inheritance (it was an example from routing-controllers case), but with return class Deletable and @Use(Deletable) you achieve something like class mixins and a sort of composition.

But the real issue in your design is that it makes things complex and unpredictable.

RecipeResolver could extend a BaseResolver which has a constructed service for manipulation (all things crud),

"all things crud" should go to the universal, generic service - then your resolvers can be "simple as hell" 😉

You don't need a weird and complicated plugin system that would save your 5 keystrokes from explicitly writing queries/mutation names and types and which can become pain in the ass while weird bugs appears, forcing you to spend time on debugging this.

[j]

Ok, fine fine. Closing for now. Let's get some more docs up 😉 (I can wink too)