Plugins

A curated list of plugins and modules for objection. Only plugins that follow the best practices are accepted on this list. Other modules like plugins for other frameworks and things that cannot be implemented following the best practices are an exception to this rule. If you are a developer of or otherwise know of a good plugin/module for objection, please create a pull request or an issue to get it added to this list.

3rd party plugins

• objection-authorize (opens new window) - integrate access control into Objection queries
• objection-dynamic-finder (opens new window) - dynamic finders for your models
• objection-guid (opens new window) - automatic guid for your models
• objection-password (opens new window) - automatic password hashing for your models
• objection-soft-delete (opens new window) - Soft delete functionality with minimal configuration
• objection-unique (opens new window) - Unique validation for your models
• objection-visibility (opens new window) - whitelist/blacklist your model properties

Other 3rd party modules

• objection-filter (opens new window) - API filtering on data and related models
• objection-graphql (opens new window) - Automatically generates rich graphql schema for objection models
• objectionjs-graphql (opens new window) - Automatically generates GraphQl schema for objection models compatible with Objection 3.x (Graph fetch support)

Plugin development best practices

When possible, objection.js plugins should be implemented as class mixins (opens new window). A mixin is simply a function that takes a class as an argument and returns a subclass. Plugins should not modify objection.Model, objection.QueryBuilder or any other global variables directly. See the example plugin (opens new window) for more info. There is also another example (opens new window) that should be followed if your plugin takes options or configuration parameters.

Mixin is just a function that takes a class and returns an extended subclass.

function SomeMixin(Model) {
  // The returned class should have no name. That way
  // the superclass's name gets inherited.
  return class extends Model {
    // Your modifications.
  };
}

Mixins can be then applied like this:

class Person extends SomeMixin(Model) {}

This doesn't work since mixins never modify the input:

// This does absolutely nothing.
SomeMixin(Model);
class Person extends Model {}

Multiple mixins:

class Person extends SomeMixin(SomeOtherMixin(Model)) {}

There are a couple of helpers in objection main module for applying multiple mixins.

const { mixin, Model } = require('objection');

class Person extends mixin(Model, [
  SomeMixin,
  SomeOtherMixin,
  EvenMoreMixins,
  LolSoManyMixins,
  ImAMixinWithOptions({ foo: 'bar' })
]) {}

const { compose, Model } = require('objection');

const mixins = compose(
  SomeMixin,
  SomeOtherMixin,
  EvenMoreMixins,
  LolSoManyMixins,
  ImAMixinWithOptions({ foo: 'bar' })
);

class Person extends mixins(Model) {}

Mixins can also be used as decorators:

@SomeMixin
@MixinWithOptions({ foo: 'bar' })
class Person extends Model {}