{"id":13683498,"url":"https://github.com/goldcaddy77/warthog","last_synced_at":"2025-04-04T09:06:51.337Z","repository":{"id":44948595,"uuid":"142377608","full_name":"goldcaddy77/warthog","owner":"goldcaddy77","description":"GraphQL API Framework with strong conventions and auto-generated schema","archived":false,"fork":false,"pushed_at":"2022-01-16T20:32:17.000Z","size":4351,"stargazers_count":360,"open_issues_count":42,"forks_count":38,"subscribers_count":12,"default_branch":"main","last_synced_at":"2025-03-28T08:05:09.411Z","etag":null,"topics":["apis","apollo-server","decorators","graphql","type-graphql","typeorm","typescript","warthog"],"latest_commit_sha":null,"homepage":"https://warthog.dev/","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/goldcaddy77.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2018-07-26T02:27:29.000Z","updated_at":"2025-01-17T11:49:37.000Z","dependencies_parsed_at":"2022-08-24T15:04:49.796Z","dependency_job_id":null,"html_url":"https://github.com/goldcaddy77/warthog","commit_stats":null,"previous_names":[],"tags_count":226,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/goldcaddy77%2Fwarthog","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/goldcaddy77%2Fwarthog/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/goldcaddy77%2Fwarthog/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/goldcaddy77%2Fwarthog/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/goldcaddy77","download_url":"https://codeload.github.com/goldcaddy77/warthog/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":246752616,"owners_count":20827987,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["apis","apollo-server","decorators","graphql","type-graphql","typeorm","typescript","warthog"],"created_at":"2024-08-02T13:02:13.332Z","updated_at":"2025-04-04T09:06:51.318Z","avatar_url":"https://github.com/goldcaddy77.png","language":"TypeScript","funding_links":[],"categories":["TypeScript"],"sub_categories":[],"readme":"\u003cp align=\"center\"\u003e\n  \u003ca href=\"http://warthog.dev/\"\u003e\u003cimg src=\"./img/warthog-logo.png\" width=\"400\" alt=\"Warthog Logo\"\u003e\u003c/a\u003e\n\u003c/p\u003e\n\n \u003cp align=\"center\"\u003e\n   Node.js \u003ca href=\"https://graphql.org\" target=\"_blank\"\u003eGraphQL\u003c/a\u003e Framework for building APIs with strong conventions through auto-generated code.  With Warthog, set up your data models and resolvers, and it does the rest.\n\u003c/p\u003e\n\n\u003cp align=\"center\"\u003e\n  \u003ca href=\"https://blacklivesmatter.com/\"\u003e\u003cimg src=\"https://img.shields.io/badge/branch-main-fce21b?labelColor=black\" alt=\"Black Lives Matter\"/\u003e\u003c/a\u003e\n  \u003ca href=\"https://www.npmjs.org/package/warthog\"\u003e\u003cimg src=\"https://img.shields.io/npm/v/warthog.svg\" alt=\"npm version\"\u003e\u003c/a\u003e\n  \u003ca href=\"https://circleci.com/gh/goldcaddy77/warthog/tree/main\"\u003e\u003cimg src=\"https://circleci.com/gh/goldcaddy77/warthog/tree/main.svg?style=shield\" alt=\"CircleCI\"\u003e\u003c/a\u003e\n  \u003ca href=\"https://codecov.io/gh/goldcaddy77/warthog\"\u003e\u003cimg src=\"https://codecov.io/gh/goldcaddy77/warthog/branch/master/graph/badge.svg\" alt=\"styled with prettier\"\u003e\u003c/a\u003e\n  \u003ca href=\"#badge\"\u003e\u003cimg src=\"https://img.shields.io/badge/styled_with-prettier-ff69b4.svg\" alt=\"styled with prettier\"\u003e\u003c/a\u003e\n  \u003ca href=\"https://github.com/semantic-release/semantic-release\"\u003e\u003cimg src=\"https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg\" alt=\"semantic-release\"\u003e\u003c/a\u003e\n  \u003ca href=\"https://gitter.im/warthog-graphql/community?utm_source=badge\u0026amp;utm_medium=badge\u0026amp;utm_campaign=pr-badge\u0026amp;utm_content=badge\"\u003e\u003cimg src=\"https://badges.gitter.im/warthog-graphql/community.svg\" alt=\"Join the chat at https://gitter.im/warthog-graphql/community\"\u003e\u003c/a\u003e\n\u003c/p\u003e\n\n## Summary\n\nWarthog is a [Node.js](http://nodejs.org) GraphQL API framework for quickly building consistent GraphQL APIs that have sorting, filtering and pagination out of the box. It is written in [TypeScript](http://www.typescriptlang.org) and makes heavy use of decorators for concise, declarative code.\n\n## Note: Upgrading from 1.0 to 2.0\n\nWarthog is now on version 2.0! There were a few breaking changes that you should consider while upgrading. Also, we tried to keep all new features development on v1, but did end up adding JSON filtering directly to 2.0 as it was much easier given some foundation refactors.\n\n\u003cdetails\u003e\n\u003csummary\u003eExpand for Breaking change details\u003c/summary\u003e\n\u003cp\u003e\n\n### More specific scalars\n\nA few fields have been updated to use more specific GraphQL scalars:\n\n- ID fields: previously these were represented by type `String`. Dates now use type `ID`\n- Date fields: previously these were represented by type `String`. Dates now use type `DateTime`\n\nSince your GraphQL schema has changed and so have the associated TypeScript types in `classes.ts`, there might be changes in your server code and even perhaps some associated client code if you use these generated classes in your client code.\n\n### `mockDBConnection` has been removed\n\nThe old codegen pipeline used TypeORM's metadata in order to generate the GraphQL schema since Warthog didn't also capture this metadata. Warthog now captures the necessary metadata, so we no longer need to lean on TypeORM and therefore we don't need the `mockDBConnection` we previously used during codegen. Searching your codebase for `mockDBConnection` and `WARTHOG_MOCK_DATABASE`/`MOCK_DATABASE` should do it. If you've been using the Warthog CLI for codegen, you shouldn't have anything to do here.\n\n### Project Dependencies Updated\n\nStaying on the latest versions of libraries is good for security, performance and new features. We've bumped to the latest stable versions of each of Warthog's dependencies. This might require some changes to your package.json.\n\n### Troubleshooting\n\n#### Cannot get connection \"default\" from the connection manager\n\nIf you get an error like:\n\n```txt\nCannot get connection \"default\" from the connection manager. Make sure you have created such connection. Also make sure you have called useContainer(Container) in your application before you established a connection and importing any entity.\n```\n\nIt could be caused by 2 things:\n\n##### Remove explicit `Container` injection\n\nIn V1 of Warthog, the README suggested that you should explicitly create your DI containers and pass them into your `App` instance like so:\n\n```typescript\nimport { Container } from 'typedi'; // REMOVE this\nimport { useContainer } from 'typeorm'; // REMOVE this\n\nimport { App } from 'warthog';\n\nasync function run() {\n  useContainer(Container); // REMOVE this\n\n  const app = new App({ container: Container }); // REMOVE the container option here\n  await app.start();\n}\n```\n\nIn V2, it is recommended that you no longer do this unless you explicitly need access to the Container.\n\n##### Remove references to Warthog's dependencies\n\nIt can sometimes cause problems to explicitly require Warthog's depdendencies (ie `type-graphql`, `typedi`, `typeorm` and `typeorm-typedi-extensions`). In future versions, remove these explicit dependencies from `package.json`:\n\n```txt\n- \"type-graphql\": \"...\",\n- \"typedi\": \"...\",\n- \"typeorm\": \"...\",\n- \"typeorm-typedi-extensions\": \"...\",\n```\n\n\u003c/p\u003e\n\u003c/details\u003e\n\n## Philosophy\n\nThis library is intentionally opinionated and generates as much code as possible. When teams build products quickly, even if they have strong conventions and good linters, the GraphQL can quickly become inconsistent, making it difficult for clients to consume the APIs in a reusable way.\n\nTo do this, Warthog automatically generates the following:\n\n- Database schema - generated by [TypeORM](https://github.com/typeorm/typeorm)\n- Your entire GraphQL Schema including:\n  - types to match your entities - generated by [TypeGraphQL](https://github.com/19majkel94/type-graphql)\n  - GraphQL inputs for consistent creates, updates, filtering, and pagination\n    inspired by [Prisma](https://github.com/prisma/prisma)'s conventions\n- A [graphql-binding](https://github.com/graphql-binding/graphql-binding) for\n  type-safe programmatic access to your APIs.\n- TypeScript classes for the generated GraphQL schema for type-safety while developing.\n\nFurther, it covers the following concerns by hooking into best-in-class open source libraries:\n\n- Validation: Automatic validation before data is saved using any of the decorators available in the [class-validator](https://github.com/typestack/class-validator#validation-decorators) library.\n\n## Prerequisites\n\nWarthog currently only supports PostgreSQL as a DB engine, so you must have Postgres installed before getting Warthog set up.\n\n\u003cdetails\u003e\n\u003csummary\u003eExpand for Postgres installation options\u003c/summary\u003e\n\u003cp\u003e\n\n### Homebrew (OSX)\n\nIf you're on OSX and have [homebrew](http://brew.sh/) and [homebrew-cask](https://github.com/caskroom/homebrew-cask) installed, you can simply run:\n\n```bash\nbrew cask install postgres\n```\n\nOr you can install Homebrew's official version:\n\n```bash\nbrew install postgresql\n`brew --prefix`/opt/postgres/bin/createuser -s postgres\n```\n\n### Postgres.app (OSX)\n\nOtherwise, you can install [Postgres.app](https://postgresapp.com/) manually.\n\n### Docker\n\nSee the [warthog-starter](https://github.com/goldcaddy77/warthog-starter/pull/6/files) project for how to use Docker to run Postgres.\n\n\u003c/p\u003e\n\u003c/details\u003e\n\n## Getting Started\n\nWarthog comes with a CLI that makes it easy to get started.\n\n### Create new project with the CLI\n\nTo install in an existing project, you'll need to create several files in place and then you'll need to call a few Warthog CLI commands that:\n\n- Generate a new resource\n- Create a database\n- Create a DB migration and run it\n- Run the server\n\nThe following code will get you bootstrapped. You should read through this before running:\n\n```bash\n# Add warthog so that we can use the CLI\nyarn add warthog\n\n# Bootstrap a new application using Warthog CLI\nyarn warthog new\n\n# Install dependencies from generated package.json\nyarn\n\n# Generate a resource (model, resolver and service)\nyarn warthog generate user name! nickname age:int! verified:bool!\n\n# Generate typescript classes and GraphQL schema\nyarn warthog codegen\n\n# Create your DB\nyarn warthog db:create\n\n# Generate the DB migration for your newly generated model\nyarn warthog db:migrate:generate --name=create-user-table\n\n# Run the DB migration\nyarn warthog db:migrate\n\n# Start the server\nyarn start:dev\n```\n\nHere's what this looks like in action:\n\n![warthog-quickstart](https://user-images.githubusercontent.com/573625/69854217-8967f380-1256-11ea-8492-dee07334501d.gif)\n\nThis will open up GraphQL Playground, where you can execute queries and mutations against your API.\n\nFirst, add a user by entering the following in the window:\n\n```graphql\nmutation {\n  createUser(data: { name: \"Test User\", age: 25, verified: false }) {\n    id\n    name\n    createdAt\n  }\n}\n```\n\nThen, query for this user:\n\n```graphql\nquery {\n  users {\n    id\n    name\n    createdAt\n  }\n}\n```\n\nSee [introducing-graphql-playground](https://www.prisma.io/blog/introducing-graphql-playground-f1e0a018f05d) for more info about GraphQL Playground.\n\n\u003cdetails\u003e\n\u003csummary\u003eExpand for other options for how to play with Warthog\u003c/summary\u003e\n\u003cp\u003e\n\n### Cloning the `warthog-starter` project\n\nAnother way to start playing with Warthog is to clone the [warthog-starter](https://github.com/goldcaddy77/warthog-starter) repo. To get the starter project up and running, do the following:\n\n```bash\ngit clone git@github.com:goldcaddy77/warthog-starter.git\ncd warthog-starter\nyarn bootstrap\nWARTHOG_AUTO_OPEN_PLAYGROUND=true yarn start:dev\n```\n\n### Running the examples in the Warthog repo\n\nYou can also clone the Warthog repo and run the examples in the [examples](./examples/README.md) folder.\n\n```bash\ngit clone git@github.com:goldcaddy77/warthog.git\ncd warthog/examples/01-simple-model\nyarn bootstrap\nyarn db:seed:dev\nyarn start\n```\n\nThis has a simple example in place to get you started. There are also a bunch of examples in the folder for more advanced use cases.\n\nNote that the examples in the [examples](./examples/README.md) folder use relative import paths to call into Warthog. In your projects, you won't need to set this config value as it's only set to deal with the fact that it's using the Warthog core files without consuming the package from NPM. In your projects, you can omit this as I do in [warthog-starter](https://github.com/goldcaddy77/warthog-starter).\n\n\u003c/p\u003e\n\u003c/details\u003e\n\n### Warthog Constructs Explained\n\n#### Models\n\nA model represents both a GraphQL type and a DB table. Warthog exposes a [BaseModel](https://github.com/goldcaddy77/warthog/blob/master/src/core/BaseModel.ts) class that provides the following columns for free: `id`, `createdAt`, `createdById`, `updatedAt`, `updatedById`, `deletedAt`, `deletedById`, `version`. If you use BaseModel in conjunction with BaseService (see below), all of these columns will be updated as you'd expect. The Warthog server will find all models that match the following glob - `'/**/*.model.ts'`. Ex: `user.model.ts`\n\nCustom [TypeORM](https://github.com/typeorm/typeorm/blob/master/docs/decorator-reference.md#entity) and [TypeGraphQL](https://typegraphql.ml/docs/types-and-fields.html) options may be passed into the `Model` decorator using the following signature.\n\n```javascript\n@Model({ api: { description: 'Custom description' }, db: { name: 'customtablename' } })\n```\n\n#### Resolvers\n\nA Warthog resolver exposes queries (reading data) and mutations (writing data). They interact with the DB through `services` (described below) and typically make use of a bunch of auto-generated TypeScript types in the `generated` folder for things like sorting and filtering. Warthog will find all resolvers that match the following glob - `'/**/*.resolver.ts'`. Ex: `user.resolver.ts`\n\n#### Services\n\nServices are the glue between resolvers and models. Warthog exposes a class called [BaseService](https://github.com/goldcaddy77/warthog/blob/master/src/core/BaseService.ts) that exposes the following methods: `find`, `findOne`, `create`, `update`, `delete`. For the `find` operator, it also maps the auto-generated `WhereInput` attributes to the appropriate TypeORM Query Builders. Warthog's convention is to name services `\u003cmodel-name\u003e.service.ts`. Ex: `user.service.ts`\n\n#### Generated Folder\n\nWhen you start your server, there will be a new `generated` folder that Warthog creates automatically. The folder contains:\n\n- classes.ts: Warthog auto-generates this file from the metadata it collects (from decorators like `Model`, `Query`, `Resolver`, `StringField`, etc...). Resolvers will import items from here instead of having to manually create them.\n- schema.graphql: This is auto-generated from our resolvers, models and `classes.ts` above. Check out [this example's schema.graphql](https://github.com/goldcaddy77/warthog/blob/master/examples/01-simple-model/generated/schema.graphql) to show the additional GraphQL schema Warthog autogenerates.\n- ormconfig.ts: a TypeORM [ormconfig](https://github.com/typeorm/typeorm/blob/master/docs/using-ormconfig.md) file.\n- binding.ts - a [graphql-binding](https://www.prisma.io/docs/1.10/graphql-ecosystem/graphql-binding/graphql-binding-quaidah9ph) for type-safe programmatic access to your API (making real API calls)\n\n## Server API (appOptions)\n\nMost of the config in Warthog is done via environment variables (see `Config - Environment Variables` below). However, more complex/dynamic objects should be passed via the server config.\n\n| attribute                 | description                                                                                               | default                                       |\n| ------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------------------------------- |\n| container                 | TypeDI container. Warthog uses dependency injection under the hood.                                       | empty container                               |\n| authChecker               | An instance of an [AuthChecker](https://typegraphql.ml/docs/authorization.html) to secure your resolvers. |                                               |\n| context                   | Context getter of form `(request: Request) =\u003e Promise\u003cobject\u003e`                                            | empty                                         |\n| logger                    | Logger                                                                                                    | [debug](https://github.com/visionmedia/debug) |\n| middlewares               | [TypeGraphQL](https://typegraphql.ml/docs/middlewares.html) middlewares to add to your server             | none                                          |\n| onBeforeGraphQLMiddleware | Callback executed just before the Graphql server is started. The Express app is passed.                   | none                                          |\n| onAfterGraphQLMiddleware  | Callback executed just after the Graphql server is started. The Express app is passed.                    | none                                          |\n\n## Config - Environment Variables\n\nAlmost all config in Warthog is driven by environment variables. The following items are available:\n\n| variable                      | value                                                    | default                   |\n| ----------------------------- | -------------------------------------------------------- | ------------------------- |\n| WARTHOG_APP_HOST              | App server host                                          | _none_                    |\n| WARTHOG_APP_PORT              | App server port                                          | 4000                      |\n| WARTHOG_APP_PROTOCOL          | App server protocol                                      | DEV: http, PROD: https    |\n| WARTHOG_AUTO_GENERATE_FILES   | Auto-generate files                                      | DEV: true, PROD: false    |\n| WARTHOG_AUTO_OPEN_PLAYGROUND  | Open playground on server start                          | DEV: true, PROD: false    |\n| WARTHOG_CLI_GENERATE_PATH     | Where should CLI generate files                          | ./src                     |\n| WARTHOG_DB_DATABASE           | DB name                                                  | _none_                    |\n| WARTHOG_DB_ENTITIES           | Where should warthog look for models                     | src\\/\\*\\*\\/\\*.model.ts    |\n| WARTHOG_DB_MIGRATIONS         | What DB migrations should TypeORM run                    | db/migrations/\\*\\*\\/\\*.ts |\n| WARTHOG_DB_MIGRATIONS_DIR     | Where should generated migrations be placed              | db/migrations             |\n| WARTHOG_DB_PORT               | DB port                                                  | 5432                      |\n| WARTHOG_DB_USERNAME           | DB username                                              | _none_                    |\n| WARTHOG_DB_LOGGER             | TypeORM logger                                           | advanced-console          |\n| WARTHOG_DB_PASSWORD           | DB password                                              | _none_                    |\n| WARTHOG_DB_SYNCHRONIZE        | DB automatically migrated                                | false                     |\n| WARTHOG_FILTER_BY_DEFAULT     | Should all filters and sorts be generated by default?    | true                      |\n| WARTHOG_GENERATED_FOLDER      | Where should generated code be placed                    | ./generated               |\n| WARTHOG_HEADERS_TIMEOUT_MS    | See [Node server.headersTimeout][1]                      | 60000                     |\n| WARTHOG_INTROSPECTION         | Allow server to be introspected                          | true                      |\n| WARTHOG_KEEP_ALIVE_TIMEOUT_MS | See [Node server.keepAliveTimeout][2]                    | 30000                     |\n| WARTHOG_RESOLVERS_PATH        | Where should Warthog look for resolvers                  | src/\\*\\*\\/\\*.resolver.ts  |\n| WARTHOG_SUBSCRIPTIONS         | Should we enable subscriptions and open a websocket port | false                     |\n| WARTHOG_VALIDATE_RESOLVERS    | TypeGraphQL validation enabled?                          | false                     |\n\n## Field/Column Decorators\n\nAll of the auto-generation magic comes from the decorators added to the attributes on your models. Warthog decorators are convenient wrappers around TypeORM decorators (to create DB schema) and TypeGraphQL (to create GraphQL schema). You can find a list of decorators available in the [src/decorators](./src/decorators) folder. Most of these are also used in the [examples](./examples) folder in this project.\n\n## Transactions\n\nThere are a few ways to handle transactions in the framework, depending if you want to use `BaseService` or use your repositories directly.\n\n### Using BaseService\n\nTo wrap BaseService operations in a transaction, you do 3 things:\n\n1. Create a function decorated with the `@Transaction` method decorator\n2. Inject `@TransactionManager` as a function parameter\n3. Pass the `@TransactionManager` into calls to `BaseService`\n\n#### @Transaction method decorator\n\nThe `@Transaction` decorator opens up a new transaction that is then available via the `@TransactionManager`. It will automatically close the transaction when the function returns, so it is important to `await` your service calls and not return a promise in this function.\n\n```typescript\n  @Transaction()\n  async createTwoItems() {\n    // ...\n  }\n```\n\n#### @TransactionManager decorator\n\nThe `@TransactionManager` is essentially the same as a TypeORM EntityManger, except it wraps everything inside of it's transaction.\n\n```typescript\n  @Transaction()\n  async createTwoItems(\n        @TransactionManager() manager?: EntityManager\n  ) {\n    // ...\n  }\n```\n\n#### Pass manager to BaseService\n\nYou can pass the entity manager into any of the `BaseService` methods to ensure they're part of the transaction.\n\n```typescript\n  @Transaction()\n  async createTwoItems(\n        @TransactionManager() manager?: EntityManager\n  ) {\n    this.create(data, userId, { manager })\n  }\n```\n\n#### Example\n\n```typescript\n@Service('UserService')\nexport class UserService extends BaseService\u003cUser\u003e {\n  constructor(@InjectRepository(User) protected readonly repository: Repository\u003cUser\u003e) {\n    super(User, repository);\n  }\n\n  // GOOD: successful transaction\n  @Transaction()\n  async successfulTransaction(\n    data: DeepPartial\u003cUser\u003e,\n    userId: string,\n    @TransactionManager() manager?: EntityManager\n  ): Promise\u003cUser[]\u003e {\n    return Promise.all([\n      this.create(data, userId, { manager }),\n      this.create(data, userId, { manager })\n    ]);\n  }\n\n  // GOOD: successful rollback when something errors\n  @Transaction()\n  async failedTransaction(\n    data: DeepPartial\u003cUser\u003e,\n    userId: string,\n    @TransactionManager() manager?: EntityManager\n  ): Promise\u003cUser[]\u003e {\n    const invalidUserData = {};\n\n    const users = await Promise.all([\n      this.create(data, userId, { manager }),\n      this.create(invalidUserData, userId, { manager }) // This one fails\n    ]);\n\n    return users;\n  }\n\n  // BAD: you can't return a promise here.  The function will return and the first\n  // user will be saved even though the 2nd one fails\n  @Transaction()\n  async failedTransaction(\n    data: DeepPartial\u003cUser\u003e,\n    userId: string,\n    @TransactionManager() manager?: EntityManager\n  ): Promise\u003cUser[]\u003e {\n    return await Promise.all([\n      this.create(data, userId, { manager }),\n      this.create(invalidUserData, userId, { manager })\n    ]);\n  }\n}\n```\n\nSee the [TypeORM Transaction Docs](https://github.com/typeorm/typeorm/blob/master/docs/transactions.md#transaction-decorators) for more info.\n\n## Complex use cases\n\nWarthog makes building simple CRUD endpoints incredibly easy. In addition, since it is built on top of TypeORM and TypeGraphQL it is flexible enough to handle complex use cases as well. If you need a field to be exposed to either the DB or API, but not both, do the following:\n\n### DB-only\n\nIf you need to add a column to the DB that does not need to be exposed via the API, you should pass the `dbOnly` option to your decorator:\n\n```typescript\n  @StringField({ dbOnly: true })\n  dbOnlyField!: string;\n```\n\nNote that you could also just use the [TypeORM Column Decorator](https://github.com/typeorm/typeorm/blob/master/docs/decorator-reference.md) as well. However, if Warthog adds additional capabilities in this space, we would not have this column metadata, so it is recommended you use the `dbOnly` option.\n\n### API-only\n\nIf you need to add a field that is exposed via the API that is not database-backed, use the `apiOnly` option:\n\n```typescript\n  @StringField({ apiOnly: true })\n  apiOnlyField!: string;\n```\n\n### Custom Query\n\nSee the [feature-flag example](./examples/07-feature-flags/) for an example of where we'd want to build something beyond the standard CRUD actions. In this example we want to add a custom query that makes a complex DB call.\n\n- First add the query to the resolver - [link to code](https://github.com/goldcaddy77/warthog/blob/master/examples/07-feature-flags/src/feature-flag/feature-flag.resolver.ts#L75-L79)\n- Then add the custom query input in the resolver - [link to code](https://github.com/goldcaddy77/warthog/blob/master/examples/07-feature-flags/src/feature-flag/feature-flag.resolver.ts#L31-L41)\n- Then add the custom service method that fetches the data [link to code](https://github.com/goldcaddy77/warthog/blob/master/examples/07-feature-flags/src/feature-flag/feature-flag.service.ts#L28-L48)\n\nWarthog will generate the correct GraphQL query and InputType automatically.\n\n## CLI\n\nWarthog ships with the following commands that can be accessed by running `yarn warthog \u003ccommand\u003e`.\n\nSee the [warthog-starter](https://github.com/goldcaddy77/warthog-starter/blob/master/package.json) project's package.json for example usage.\n\n| Command           | Args      | Description                                                                             |\n| ----------------- | --------- | --------------------------------------------------------------------------------------- |\n| codegen           | none      | autogenerates code from decorated models and resolvers and places in `generated` folder |\n| db:create         | none      | creates DB based on DB specified in config file                                         |\n| db:drop           | none      | drops DB based on DB specified in config file                                           |\n| generate          | See below | generates a model, service and resolver                                                 |\n| db:migrate        | none      | migrates DB (proxies through TypeORM CLI)                                               |\n| db:migrate:create | none      | auto-generates DB migration based on new code additions (proxies through TypeORM CLI)   |\n\n### `generate` Command in depth\n\nThe `generate` command will create a new resolver, service and model for a given resource. Let's start with a complex example and we'll break it down:\n\n```bash\nyarn warthog generate user name! nickname numLogins:int! verified:bool! registeredAt:date balance:float! --folder my_generated_folder\n```\n\n- `user` - this is the name of the new resource (required)\n- ...args - each of the remaining args until `--folder` is a field on the resource\n- `name!` - the name field is of type string by default since no data type is specified. The `!` states that it's required\n- `numLogins:int!` - numLogins states that it is of type int - also required\n- `registeredAt:date` - registeredAt is of type date (which correlates to an ISO8601 datetime). The absence of the `!` means it is optional.\n- ...the rest of the args are self-explanatory. Possible types are `bool`, `date`, `int`, `float` and `string`. If you need to use other types, just add them as strings and update the models manually.\n- `--folder` - this allows you to explicitly set the folder where the generated files should go. This is not recommended and instead you should use the .rc file (see below)\n\n## `warthogrc` config file\n\nWarthog uses [cosmiconfig](https://github.com/davidtheclark/cosmiconfig) for config that shouldn't change between environments (so typically file paths). This means you can put any of the following config files in your project root:\n\n- .warthogrc.json\n- .warthogrc.yaml\n- .warthogrc.js\n- warthog.config.js file (exporting a JS object)\n\nThe following config options are currently available:\n\n| Config Key      | Description                                                                  | Equivalent Environment Variable |\n| --------------- | ---------------------------------------------------------------------------- | ------------------------------- |\n| generatedFolder | Relative location to generated folder (relative path from the config file)   | WARTHOG_GENERATED_FOLDER        |\n| cliGeneratePath | Where should CLI place generated files? (relative path from the config file) | WARTHOG_CLI_GENERATE_PATH       |\n| resolversPath   | Where should Warthog look for resolvers? (comma-delimited list of regexes)   | WARTHOG_RESOLVERS_PATH          |\n\nNote that for `cliGeneratePath`, you can interpolate in the following strings to generate dynamic paths:\n\n- `className` (pascal case)\n- `camelName` (camel case)\n- `kebabName` (kebab case)\n\nExample:\n\n```json\n{\n  \"cliGeneratePath\": \"./src/${kebabName}\"\n}\n```\n\nRunning `yarn warthog generate featureFlag` would create 3 files in the `./src/feature-flag/` folder. See [feature-flag example](./examples/7-feature-flags/warthog.config.js) for a live example.\n\n## Usage in Production\n\nIt is recommended that you not run Warthog's TypeScript files via `ts-node` in Production as we do in development as `ts-node` has been known to cause issues in some smaller AWS instances. Instead, compile down to JS and run in `node`. For a full project example (using [dotenvi](https://github.com/b3ross/dotenvi) for config management), see [warthog-starter](https://github.com/goldcaddy77/warthog-starter)\n\n## Contributing\n\nPRs accepted, fire away! Or add issues if you have use cases Warthog doesn't cover.\n\nBefore contributing, make sure you have Postgres installed and running with a user named `postgres` with an empty password. If you don't have this local Postgres user, you'll need to update the `.env` files in the `examples` folders to point to a user that can run DB migrations.\n\nOnce you have this user set up, you can build a specific example by navigating to that folder and running `yarn bootstrap`.\n\nIf you want to build all examples, you can run `yarn bootstrap` from the Warthog root folder.\n\nIt's helpful to add a new feature to the Warthog and make use of it in one of the examples folders until you've determined how it's going to work. Once you have it working, you can add tests.\n\n## Intentionally Opinionated\n\nWarthog is intentionally opinionated to accelerate development and make use of technology-specific features:\n\n- Postgres - currently the only database supported. This could be changed, but choosing Postgres allows adding a docker container and other goodies easily.\n- Jest - other harnesses will work, but if you use Jest, we will not open the GraphQL playground when the server starts, for example.\n- Soft deletes - no records are ever deleted, only \"soft deleted\". The base service used in resolvers filters out the deleted records by default.\n\n## Thanks\n\nSpecial thanks to:\n\n- [TypeORM](https://github.com/typeorm/typeorm) - DB generation\n- [TypeGraphQL](https://github.com/19majkel94/type-graphql) - GraphQL generation\n- [Prisma](https://github.com/prisma/prisma) - [OpenCrud](https://github.com/opencrud/opencrud) conventions\n- [richardbmx](https://github.com/richardbmx) - Logo design\n\nWarthog is essentially a really opinionated composition of TypeORM and TypeGraphQL that uses similar GraphQL conventions to the Prisma project.\n\n## License\n\nMIT © Dan Caddigan\n\n[1]: https://nodejs.org/api/http.html#http_server_headerstimeout\n[2]: https://nodejs.org/api/http.html#http_server_keepalivetimeout\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgoldcaddy77%2Fwarthog","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgoldcaddy77%2Fwarthog","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgoldcaddy77%2Fwarthog/lists"}