Prepare for feathers v3 about feathers-rest HOT 9 CLOSED

The v3 compatible version can be found in https://github.com/feathersjs/feathers-rest/tree/major

I agree that it should be moved eventually but was thinking of leaving it here for now to make the migration less painful and then put in a deprecation warning once there are other frameworks that are support. Thoughts?

from feathers-rest.

Yes I agree to not rename it till we have at least one full framework support, and the whole ecosystem has stabilized.

Till then not likely to cause any issues, people can just be aware of the fact that default/legacy support is express everything else has an explicit naming.

from feathers-rest.

I got pretty far already. Would love for someone who knows/likes Koa to help me out finishing the feathers REST adapter for Koa. Cheers!

from feathers-rest.

Note that I forked the master branch for my feathers-rest-koa, but the master is currently very Express centric. I'll look at the major branch shortly.

So far I've added a createSetter factory method, to provide functions to operate on the ctx (in Express on res)

function createSetter(ctx) {
  let _ctx = ctx
  return {
    setStatus: (code) => {
      _ctx.code = code
    },
    setHeader: (name, value) => {
      _ctx.set(name, value)
    }
  }
}

// ...
else if (method === 'create') {
  setter.setCode(statusCodes.created);
}

The main rest method now takes options to customise as needed and use takes an async function

export default function rest(opts = {}) {
  return function () {
    const app = this;
    let configJson = opts.configJson || koaConfigJson
    configJson(app, opts)

    let configFeathersRest = opts.configJson || koaConfigFeathersRest
    configFeathersRest(app, opts)

    app.rest = wrappers;
    let register = opts.register || defaultRegister;
    register(app, opts);
  };
}

export function koaConfigFeathersRest(app, opts) {
  app.use(async function (ctx, next) {
    ctx.feathers = {
      provider: 'rest'
    };
    await next();
  });
}

I will try to integrate this with the changes in the v3 branch ie. major. One of the major changes I see is another factory layer:

export function createWrapper(method, getArgs, opts) {
  return service => {
    return async function (ctx, next) {
      let createSetter = opts.createSetter || defaultCreateSetter
      let setter = createSetter(ctx)

      // ...

Cheers!

from feathers-rest.

Currently the problem is that feathers doesn't seem to add the Koa REST routes via .use, as in test/config.js:

  app = feathers()
    // Note: rest factory will configure json body parser
    .configure(rest(opts))
    // .use(bodyParser()) // supports json (now done via configure(rest()))

    // FIX: calling .use does not add the routes via koa-router!!
    .use('codes', {
      get(id, params, callback) {
        callback();
      },

      create(data, params, callback) {
        callback(null, data);
      }
    })
    .use('todo', todoService);

So how does this currently work and where do I tweak it?
In feathers core? Yes, seems to be here

use (location) {
    // ....

    // Any arguments left over are other middleware that we want to pass to the providers
    this.service(location, service, { middleware });

    return this;
  },

Which calls service to configure the new service:

service (location, service, options = {}) {
    // ....

    // Run the provider functions to register the service
    this.providers.forEach(provider =>
      provider.call(this, location, protoService, options)
    );
    // ....

    return this
}

Here the this.providers (such as the rest provider!?) are iterated and called to provide endpoints for the service definition.

How do I turn on debugging? I guess I will have to npm link to feathers core and go from there to see what the problem is.

Cheers!

from feathers-rest.

I definitely recommend to go with feathers@pre (and what's in the major branch) that way you can override .use as done in https://github.com/feathersjs/feathers-express/blob/master/lib/index.js#L17. As you pointed out, the setting up of routes is done by pushing a provider to app.providers as done in https://github.com/feathersjs/feathers-rest/blob/master/src/index.js#L30. Thanks again for looking into this!

from feathers-rest.

I think this can be closed and we track other framework integrations separately. A WIP upgrade guide for v3 can be found at https://gist.github.com/daffl/e718f93acc7bfe32fd1e5aed0f8e7827

from feathers-rest.

Wow! Looks awesome @daffl :) Good job!

from feathers-rest.

With regard to supporting other "frameworks", might be a good idea to start with something simple, such as express with Promise support, then build from there:

https://medium.com/@Abazhenov/using-async-await-in-express-with-node-8-b8af872c0016
https://www.npmjs.com/package/express-promise-router
https://github.com/luin/express-promise

What do you think?

from feathers-rest.