kogosoftwarellc / open-api

A Monorepo of various packages to power OpenAPI in node
MIT License
890 stars 234 forks source link

(feature): ES7/TypeScript Decorators #42

Open amcdnl opened 8 years ago

amcdnl commented 8 years ago

Add Support for ES7/TypeScript Decorators

Per my convo with @jsdevel on Gitter, I'd like to propose adding some implementation for decorators.

Example

ZooController.ts

@controller({
   // default route
   route: '/zoo'

   // add additional middlewares for express
   middlewares: [ ... ],

   // custom override for global spec
   spec: './zoo-spec.yml'
})
export class ZooController {
    @api(‘/get’, [ ...middlewares ])
    getAnimals(req, res, next) { 
          // doo stuff
    }
}

App.ts

import { ZooController } from './ZooController';
import { register } from 'express-openapi';

let app = express();
register(app, {
    spec: './spec.yml',
    route: '/api',
    paths: [ '**/*.ts' ]
});

This is kinda angular2-esque with the loaded decorator design pattern which works nicely IMO, define the config at top and the real work happens in body.

If it were me, I'd consider making this project more generic like node-openapi and then writing this proposal seperate like node-openapi-router and then add adapters for connect/koa/etc like node-openapi-connect-middleware.

Resources

jsdevel commented 8 years ago

I'm all for this. Thoughts @MugeSo ?

maxwellb commented 5 years ago

Personally I like the convention over configuration of what's here now. As long as decorators don't become the only way, seems ok. I was actually attracted to the lack of specifying such on each controller or operation. There are other frameworks which already do that as you say, so the lack is actually unique and a benefit in some way here, imo.

jsdevel commented 5 years ago

@maxwellb thanks for the feedback! I don't believe this feature proposal was ever meant to sunset any existing convention. It would be an additional way to configure APIs which would keep the framework more unopinionated.