Skip to content

service.class.md

Latest commit

 

History

History
135 lines (93 loc) · 3.96 KB

service.class.md

File metadata and controls

135 lines (93 loc) · 3.96 KB

Service classes

The service.class file exports the service class or object.

Database services

When using a database, the service class will be extended from the Feathers database adapter service. Like any class, existing methods can be overriden or you can add your own methods (which can also be made available externally as custom methods when registering the service).

Service customization

The generic types for a database service are always AdapterService<ResultType, DataType, ParamsType>.

An SQL Knex service can be customized like this:

export interface MessageParams extends KnexAdapterParams<MessageQuery> {}

// By default calls the standard Knex adapter service methods but can be customized with your own functionality.
export class MessageService<ServiceParams extends Params = MessageParams> extends KnexService<
  Message,
  MessageData,
  ServiceParams
> {
  find(params: ServiceParams) {
    return super.find(params)
  }

  async myMethod(name: string) {
    return {
      message: `Hello ${name}`
    }
  }
}

An MongoDB service can be customized like this:

export interface MessageParams extends MongoDBAdapterParams<MessageQuery> {}

// By default calls the standard MongoDB adapter service methods but can be customized with your own functionality.
export class MessageService<ServiceParams extends Params = MessageParams> extends MongoDBService<
  Message,
  MessageData,
  ServiceParams
> {
  find(params: ServiceParams) {
    return super.find(params)
  }

  async myMethod(name: string) {
    return {
      message: `Hello ${name}`
    }
  }
}

Note the MessageService<ServiceParams extends Params = MessageParams> generic. This is used to change the parameter type when using this service interface as a client side service.

Custom services

As shown in the Quick start, Feathers can work with any database, third party API or custom functionality by implementing your own services. When generating a custom service, a basic skeleton service will be created. You can remove the methods you don't need and add your own.

While service methods still have to follow the standard or custom method signatures, the parameter and return types can be whatever works best for the service you are implementing. If a service method is only for internal use (and not for clients to call) there are no method signature or return value restrictions.

import type { Id, NullableId, Params } from '@feathersjs/feathers'

interface MyParams extends Params {}

class MyService {
  async find(params: MyParams) {
    return {
      message: 'This type is inferred'
    }
  }

  async get(id: Id) {
    return [
      {
        id
      }
    ]
  }

  async create(data: Message, params: MyParams) {
    return data
  }

  // Custom method made available to clients needs to have `data` and `params`
  async customMethod(data: CustomMethodData, params: MyParams) {}

  // A method that is only available internally can do anything
  async anyOtherMethod() {
    const [entry] = await this.get('david')

    return entry.id
  }
}

When removing methods, the methods list in the service and client files also needs to be updated accordingly.

getOptions

The getOptions function is a function that returns the options based on the application that will be passed to the service class constructor.