New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Service at root. '/' #728

keesee opened this Issue Nov 12, 2017 · 6 comments


None yet
4 participants
Copy link

keesee commented Nov 12, 2017

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

  • 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:


This comment has been minimized.

Copy link

daffl commented Nov 12, 2017

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

Duplicate of #718

@daffl daffl closed this Nov 12, 2017


This comment has been minimized.

Copy link

aral commented Jan 4, 2018

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 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 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 :)


This comment has been minimized.

Copy link

daffl commented Jan 4, 2018

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.


This comment has been minimized.

Copy link

aral commented Jan 4, 2018

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.


This comment has been minimized.

Copy link

tim-field commented Oct 28, 2018

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


This comment has been minimized.

Copy link

daffl commented Dec 16, 2018

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

@daffl daffl reopened this Dec 16, 2018

@daffl daffl closed this Dec 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment