Unregistering services and hooks

[Download]

Currently, once the app is running, it's pretty difficult to unregister Feathers services and hooks.

We would like to be able to support unregistering all event handlers associated with a route, so we can recreate and re-register them while the server keeps running. If we do this right, it will enable people to use hot reloading techniques such as Webpack's Hot Module Replacement with their Feathers services and hooks.

API suggested by @daffl in Slack:

app.service('/myservice',  null)

would completely undo the effects of

app.use('/myservice', myservice)

...and thus allow us to use HMR like this:

services/myservice/index.js

'use strict';

let app; // hang on to the app object
module.exports = function(){
  app = this;
  register()
};

function register() {
  // re-require on every invocation to facilitate HMR
  // `require` caches modules once loaded, so second require is fast.
  const hooks = require('./hooks');
  const Service = require('./service');
  app.use('/myservice', new Service());
  const service = app.service('/myservice');
  service.before(hooks.before);
  service.after(hooks.after);
}

function unregister() {
  app.service('/myservice', null);
}

if (module.hot) {
  module.hot.accept(['./hooks', './service'], function(){
    unregister(); // unregister the old service and hooks
    register(); // ..and register the new ones. 
  })
}

// not sure if it's useful to keep this next line...  modules referencing 
// `Service` would need to make sure they get the new one somehow...
// module.exports.Service = Service;

[ElegantSudo]

That's a bit complicated. Is there a way we can augment this, so that on each deploy these tasks are already being reviewed and executed?

[Download]

@ElegantSudo Can you elaborate on what is complicated? Basically the contents from the example above come from:

1. the feathers CLI generator (but moved the logic into a function register)
2. the Webpack HMR api (e.g. see the example on their Wiki)
3. The unregister function, which is basically the essence of this proposal

I think most of this code would be generated for you by feathers generate service.

[ElegantSudo]

@Download that's a valid point. What I really meant is: can we add this to feathers so that this process is automated upon server deploy for every application?

I think hot module reloading is an essential feature for any developer with an application.

[marshallswain]

The generator will be pluggable, so customization like this will be possible. We probably don't want a Webpack build in the default generator, but adding it through a generator plugin should be fairly straightforward.

[Download]

@marshallswain @daffl I cannot set the milestone for this issue, but it should be set to 'Buzzard' according to the conversations in Slack.

[Download]

I'm having doubts about the currently proposed API..

Let's suppose we had done this:

app.use('/myservice', myService)

Then we could unregister myService by calling app.use again with null as the 2nd argument:

app.use('/myservice', null)

Ok... But does this imply that we could also have done:

app.use('/myservice', someOtherService)

In other words, does app.use always unbind any old service that was bound to that URL, or does it only happen when we explicitly pass null ?

If it always unbinds the old service and passing null (or undefined?) is just a way to say that there is no new service to replace the old one than I think that's great. If however in the second scenario when we app.use('/myservice', someOtherService) it doesn't unbind the old service, so null is a magic value to trigger the unregister, then I think it would be better to just make a separate method... unuse for example.

Any thoughts?

@marshallswain @daffl @ekryski

[marshallswain]

We can make it so that

app.service('my-service', null)          // tears down an existing service. 
app.service('my-service', newService())  // tears down and replaces.

For teardown, you would have to pass null, otherwise it too closely matches app.service('my-service'). Passingnull gives it a sense of explicitness.

[ekryski]

or we move to something like app.mount('/users', userService()) and app.unmount('/users'). If you want to reference a service you still simply do app.service('users') and in order to support backwards compatibility we can alias app.service('/users', userService()) to app.mount and can toss a deprecation warning.

That might also make it more clear on the client that you are just referencing a server side service most of the time. I feel like that is something that people get a bit confused about because you use app.service to both register and reference a service where on the client you aren't registering many services. Thoughts?

[marshallswain]

Yeah. I like separating the API like that.

app.mount('users', userService())   //setup or replace
app.unmount('users')                //teardown
app.service('users')                //lookup

[Download]

Agreed. And since this issue is planned for Buzzard it would be good timing for such an API change.

I like how Feathers builds upon Express, but I do get quitte confused at which methods are from Express and which from Feathers sometimes. In fact I think I messed up the terms already in my comments above. Having the API separated like this will make it clearer I think.

[daffl]

In the jQuery days it used to be pretty common to use methods as getters and setters at the same time (e.g. $().attr('href') and $().attr('href', 'value') but I guess it has fallen a little out of fashion.

I'm not sure if introducing new methods is necessary though. When we implement #258 and make Feathers framework independent it will have its own API and not extend Express anymore. The only downside I see in that case to stick with app.use('/service', myService) I can see is that it looks to Express-y and might be mistaken as a way to register middleware functions (which it won't anymore). Like @marshallswain said, it could teardown implicitly (and be able to set it to null) and we make app.service('name') always return the service and drop support for app.service('name', myService).

[Download]

I think this discussion is relevant:
app.use('/location', service) vs app.service('/location', service) #287

• Come Buzzard, Express is going to be just another server for Feathers, so use is becoming less clear
• use is already overloaded pretty heavily by Express itself. Even in Express I get confused by it...
  • For request/error handlers
  • For middleware
  • For subapps
• service is unique to Feathers afaik, and is pretty descriptive

app.service('users', userService())   // setup (replaces any old service)
app.service('users', null)            // teardown
app.service('users')                  // lookup

This looks pretty clear to me. I know I have, as a new user, spent some time reading the Feathers JS source code because I didn't understand what extra stuff Feathers' use was doing that Express' use does not. Having it be a completely separate method will make it much clearer that it does do extra special things.

I looked into what it takes to perform unregistering a service but I got a headache from it :) Express itself does not make it easy, because unregister is something that has to be hacked in by accessing 'private' state in the app object if I can believe the Stack Overflow anwsers on questions relating to it.

[daffl]

I agree, I'd prefer that syntax, too. If everybody is on board sticking with this we might even want to consider updating all the service examples from .use to .service in preparation for #258.

I'm always surprised that Express never added support for unregistering middleware (if you have a reference to the middleware function it shouldn't be too hard to splice it out of the stack). I guess Express hot module reloading is just hacking it the same way then. Unregistering the socket events will definitely be more straightforward.