Service at root. '/'

[keesee]

I'm experimenting with using feathers as a chassis for mirco-services. is it possible to have a service as the root route?
I'm running into errors with hooks... src\services[name][name].service.js:17 service.hooks(hooks);

TypeError: Cannot read property 'hooks' of undefined at Function.module.exports (...\src\services[NAME][NAME].service.js:17:11)
at Function.configure (...node_modules\feathers\lib\application.js:150:8)
at Function.module.exports (...\src\services\index.js:5:7)

....

Steps to reproduce

    // app.js  
    // remove 
    app.use('/', feathers.static(app.get('public')));

    // [NAME].service.js
    // use at home '/'
    -app.use('/', createService(options));

(First please check that this issue is not already solved as described
here)

• Tell us what broke. The more detailed the better.
• If you can, please create a simple example that reproduces the issue and link to a gist, jsbin, repo, etc. This makes it much easier for us to debug and issues that have a reproducable example will get higher priority.

Expected behavior

Tell us what should happen

Actual behavior

Tell us what happens instead

System configuration

Tell us about the applicable parts of your setup.

Module versions (especially the part that's not working):

NodeJS version:

Operating System:

Browser Version:

React Native Version:

Module Loader:

[daffl]

Services always have to have a name. I added a more specific error message for that in #729

Duplicate of #718

[aral]

Hey @daffl, would you mind reviewing this decision in light of the following use case:

I am implementing an ActivityPub server and the root path (the domain) represents the person’s handle in the federated system. (So, e.g., I will be @ar.al and people will be able to mention me using my domain as a handle.) As such, under the W3C ActivityPub spec, other servers will hit https://ar.al expecting a GET response with an Actor object.

Afaik, this is currently impossible to implement in Feathers without falling back to plain Express. (This is not a showstopper for me but it would be nice to have all routes under the same approach.)

Currently, when I try to mount the route, I get:

 '/' is not a valid service path.

IMHO, / should be a valid service path, representing the default service at the given domain.

Thanks for your time + look forward to hearing your thoughts :)

[daffl]

I would probably go with a middleware in that case. The problem with / is that slashes get truncated in a service name so it will just be an empty string which makes for a bad identifier (since it is falsy), especially when used via websockets. We could add an exception for HTTP (which I'd like to try to avoid) or add a fallback name like __default that will be mounted at the root in a future version.

[aral]

I like the __default fallback idea (would you like me to open a separate issue for that?) The service itself having a name is a good requirement and that should cover that base while also providing flexibility for situations like this where changing the path would expose unnecessary complexity to the interface by affecting the URL structure/usage.

[tim-field]

Would also really like a way to do this. Use case for me is when implementing a HATEOAS endpoint were I would like the root entry to be able to send links which describe the services available

[daffl]

Registering a root service is now possible in version 3.3.0 or later via app.use('/', service)