tyranid-openapi
v0.5.20
Published
Open API spec and express app generator for tyranid
Downloads
33
Readme
OpenAPI / Swagger spec generator for Tyranid
This project provides a way to generate a complete + valid openAPI spec by adding schema annotations to your tyranid models.
NOTE: this library only creates the spec itself, implementation is left to the app code for now (but might be a good feature for this library later on).
Contents
- Schema Options
- Generating the spec
- Exposing a single collection
- "Parent" collections
- Renaming and Restricting certain properties
- Partitioning a collection into multiple "virtual" collections
Schema Options
There are various options for configuring how the tyranid models appear to the public api. You can see the CollectionSchemaOptions
(specified in as an object on the schema definition named openAPI
) and FieldSchemaOptions
(specified on specific fields in the schema as a property named openAPI
) interfaces in ./src/interfaces.ts
.
Generating the Spec
Once you have specified some collections to be exposed by annotating the schemas, you can generate the actual spec file as follows...
import { Tyr } from 'tyranid';
import { spec } from 'tyranid-openapi';
import { writeFileSync } from 'fs';
import { join } from 'path';
// async function for bootstrap
(async () => {
// bootstrapping without db to just get schema graph
await Tyr.config({
validate: [{ glob: join(__dirname, './models/*.js') }]
});
// generate yaml openAPI spec string
const specString = spec(Tyr, { yaml: true });
// write out to file
writeFileSync(join(__dirname, './my-api.yaml'), specString);
})().catch(console.error);
Exposing a single collection
The most basic way to expose a collection to the public api is by setting the openAPI
flag to true
, and marking a few properties to show. For example...
import { Tyr } from 'tyranid';
export default new Tyr.Collection({
id: 't01',
name: 'metric',
dbName: 'metrics',
// this indicates that we want GET/PUT/POST/DELETE endpoints
// for `/metrics` and `/metrics/{_id}`. Additionally, `read:metrics` and
// `write:metrics` scopes will be created.
openAPI: true,
fields: {
_id: { is: 'mongoid' },
organizationId: { is: 'mongoid' },
// here we mark that we want to expose this field to the api
// also, since it is marked `required`, api users will recieve
// an error if they do not POST/PUT data that includes it.
name: { is: 'string', openAPI: true, required: true }
}
});
"Parent" collections
Some times there might be several collections which you want to have fall under a single set of permission scopes. Additionally, you want the api url to be nested.
For example, say we have a metrics
collection containing metadata about individual metrics (like usage analytics or budget numbers) as well as a metricObservations
collection which contains the actual time series. To keep metricObservations
in the same permission scope as metrics
, we would add the following annotation...
export default new Tyr.Collection({
id: 'mtg',
name: 'metricTarget',
dbName: 'metricTargets',
openAPI: {
// define the parent collection, this means that
// the api paths will be nested under metrics, so
// `/metrics/{_id}/observations`, `/metrics/{_id}/observations/{_id}`
parent: 'metric',
// here we say that we want to use the permission scopes
// (`read:metrics`/`write:metrics`) for this collection
useParentScope: true
},
fields: {
_id: { is: 'mongoid' },
metricId: { link: 'metric', openAPI: true },
date: { is: 'date', openAPI: true },
value: { is: 'double', openAPI: true },
organizationId: { is: 'mongoid' },
excludeProperty: { is: 'string' },
type: {
link: 'metricTargetType',
openAPI: true
}
}
});
Renaming and Restricting certain properties
If there are certain properties that are automatically generated by the database (like timestamps), you can mark them to only be returned / accepted from read endpoints. Additionally, you can provide different public names for properties...
import { Tyr } from 'tyranid';
export default new Tyr.Collection({
id: 't01',
name: 'metric',
dbName: 'metrics',
openAPI: true,
fields: {
_id: { is: 'mongoid' },
organizationId: { is: 'mongoid' },
name: { is: 'string', openAPI: true, required: true },
privateNamedProperty: {
is: 'string',
openAPI: {
// only allow this property in results of GET / PUT / POST,
// do not allow it to be sent as part of an update (PUT/POST)
include: 'read',
// in the spec, this property will be called `publicName`
name: 'publicName'
}
}
}
});
Partitioning a collection into multiple "virtual" collections
If there is a single database collection which represents several distinct types of data which you wish to expose in different endpoints, you can "partition" the collection...
import { Tyr } from 'tyranid';
export default new Tyr.Collection({
id: 'i01',
name: 'item',
dbName: 'items',
openAPI: {
// this will create two new types for the api: `Plan` + `Task` + `Project`,
// with `/task`, `/project`, and `/plan` endpoints, etc...
partition: [
{
name: 'plan',
// here we define a mongodb query to separate the
// data into their specific partitions
partialFilterExpression: {
kind: 'plan'
}
},
{
name: 'task',
partialFilterExpression: {
kind: 'task'
}
},
{
name: 'project',
partialFilterExpression: {
kind: 'project'
}
}
]
},
fields: {
_id: { is: 'mongoid' },
organizationId: { is: 'mongoid' },
name: { is: 'string', openAPI: true, required: true },
kind: { is: 'string' },
planField: {
is: 'string',
openAPI: {
// we might want some fields to only appear on
// certain partitions (can also be an array of partitions)
partition: 'plan'
}
},
taskField: {
is: 'string',
openAPI: {
partition: 'task'
}
},
nestedPartitionField: {
is: 'object',
fields: {
innerPlanOrProjectField: {
is: 'string',
openAPI: {
partition: ['plan', 'project'],
name: 'renamedPartitionField'
}
},
innerTaskField: { is: 'string', openAPI: { partition: 'task' } }
}
}
}
});