# Service classes
The `service.class` file exports the [service class or object](../../api/services.md).
## Database services
When using a database, the service class will be extended from the [Feathers database adapter service](../../api/databases/common.md). 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.md#registration)).
### Service customization
The generic types for a database service are always `AdapterService`.
An [SQL Knex service](../../api/databases/knex.md) can be customized like this:
```ts
export interface MessageParams extends KnexAdapterParams {}
// By default calls the standard Knex adapter service methods but can be customized with your own functionality.
export class MessageService extends KnexService<
Message,
MessageData,
ServiceParams
> {
find(params: ServiceParams) {
return super.find(params)
}
async myMethod(name: string) {
return {
message: `Hello ${name}`
}
}
}
```
An [MongoDB service](../../api/databases/mongodb.md) can be customized like this:
```ts
export interface MessageParams extends MongoDBAdapterParams {}
// By default calls the standard MongoDB adapter service methods but can be customized with your own functionality.
export class MessageService extends MongoDBService<
Message,
MessageData,
ServiceParams
> {
find(params: ServiceParams) {
return super.find(params)
}
async myMethod(name: string) {
return {
message: `Hello ${name}`
}
}
}
```
Note the `MessageService` generic. This is used to change the parameter type when using this service interface as a [client side service](./client.md).
## Custom services
As shown in the [Quick start](../basics/starting.md), Feathers can work with any database, third party API or custom functionality by implementing your own [services](../../api/services.md). 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](../../api/services.md#service-methods) or [custom](../../api/services.md#custom-methods) 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.
```ts
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](./service.md) and [client](./client.md) files also needs to be updated accordingly.
## getOptions
The `getOptions` function is a function that returns the options based on the [application](./app.md) that will be passed to the service class constructor.