Feathers: How can I change the root base URL for the whole API?

[pedrommuller]

Hi I'd like to change the route of the API from

http://localhost:3030/

to

http://localhost:3030/api/v1/

including all middlewares like authentication for example, so far I can change the route n the services by just modifying the app service,
const userService = app.service('/api/v1/users');

but I'm not sure how to change the authentication base URL, as far I know is

http://localhost:3030/authentication
and I'd like to include the prefix mentioned above.

Is there a way to config the whole path? if that's not possible how can I change the path for the authentication service?
Thanks

[JigSawFr]

+1 for same question

[subodhpareek18]

I would say the easiest way would be to have a feathers subapp and then mount that within another express or feathers app. Which will look something like:

// api.js

import feathers from 'feathers';
import rest from 'feathers-rest';
import sequelize from 'feathers-sequelize';
import socketio from 'feathers-socketio';
import errorHandler from 'feathers-errors/handler';

const db = require('../feathers/models');
const api = feathers();

api.configure(socketio());
api.configure(rest());

Object.keys(db.sequelize.models).forEach(key => {
  api.use(key, sequelize({
    Model: db[key],
    id: `${key}_id`,
    paginate: {
      default: 10,
      max: 25
    }
  }));
});

api.use(errorHandler());

export default api;

// server.js

import feathers from 'feathers';
import api from './api';

const app = feathers();

const init = () => {
  app.use('/api/v1', api);
  const server = app.listen(3001);
  api.setup(server);
};
export const run = () => init();

Further reading:
https://docs.feathersjs.com/middleware/mounting.html
https://docs.feathersjs.com/middleware/routing.html#versioning

[marshallswain]

Thanks @zusamann. It's either that or rename each service, individually, which is the route I prefer. I haven't seen an app that needed more than 20 services, yet, so I wouldn't think it would be that difficult.

If mounting a lot of middleware, then maybe the above comment is the better way to go.

[subodhpareek18]

Yes @marshallswain you are correct. If simply wanting to have a new path then renaming is the obvious trivial solution. I went in the other direction of defining the whole API as it's own microservice.

[tguelcan]

+1 for same question for the newer version...

[marshallswain]

I think this article explains the best way to do API prefixing: https://blog.feathersjs.com/feathersjs-in-production-configuration-api-prefixing-logging-and-error-catching-2a80e044e233

[krcourville]

Same issue here on new version. In my scenario, I'm trying to get a feathers app to run in an Azure Service Fabric cluster which provides a reverse proxy that maps the application to something like: http://myserver.somewhere.io:19080/myapp/feathers-api/

The Express 4.x Router supports this scenario. Is there a way to use Express Router?

UPDATE:
So far, #516 has helped me with minimal code changes.

[daffl]

Why would the app have to worry about a reverse proxy endpoint? The REST endpoints are using a normal Express router but again, this does not apply to websockets which makes it really finicky to work with. There are several options for prefixing linked in the article and through the https://github.com/luke3butler/feathers-versionate plugin.

[krcourville]

I wish I didn't have to worry about it, but it definitely doesn't work to just deploy to Service Fabric.

I'm still trying to understand the Service Fabric reverse proxy. What I know so far is:

• Service Fabric clusters have a minimum 5 nodes (virtual machines).
• By default, your app is deployed on every node and is given an port from a from a configured pool (I'm passing this port to the feathers app).
• The Service Fabric Reverse Proxy is supposed to alleviate the pain of port administration by giving you a single endpoint url like I mentioned above.
• I believe the Reverse Proxy also serves as a load balancer.

So far, I'm still getting a 404 when connecting using changes via #516 . This tells me it's hitting the express server but not serving the request. My initial thought is that the proxy is screwing things up because the app expects its base path to be "/".

I'll give versionate a try, too.

[krcourville]

After enabling DEBUG env variable for Express, I was able to confirm that REST request were not hitting Express, and that the proxy was returning the 404. Then, I finally tracked down my primary issue being a missing property in the Service Fabric endpoint config. Was missing "UriScheme".

<Endpoint Protocol="http" UriScheme="http" Name="ApiEndPoint" Type="Input" Port="16001" />

REST works fine with Service Fabric now with no changes. Now, to get socket.io working. Still trying out versionate.

[marshallswain]

Ah. Thanks for sharing the update @krcourville. That's good info for the rest of the community.

[lock[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue with a link to this issue for related bugs.