Config options - disable UI, disable Swagger

[bajtos]

There should be an easy way how to disable explorer (either UI only or everything) when running in production.

A possible solution: add two new properties to the option object used by middleware factory function.

These two new properties then can be configured either from server/boot/explorer.js, or using the upcoming component infrastructure (see https://github.com/strongloop/loopback-example-component/wiki).

[ricardohbin]

+1

[oakley808]

+1

[bajtos]

@ricardohbin @oakley808 Can you contribute this feature yourself?

[bajtos]

On the second thought, I don't think it makes sense to disable the UI while keeping the Swagger metadata available. With metadata available, one can run an own copy of the Swagger UI (e.g. via http://petstore.swagger.io/) and configure it with the Swagger metadata provided by the LoopBack server.

See also strongloop/loopback#1134, it points out a similar problem.

Here is the solution I would like to see implemented instead: extend loopback-boot's support for component-config.json (see strongloop/loopback-boot#86) to allow developers to enable/disable components on per-environment basis.

At the moment, explorer can be configured as follows:

// server/component-config.json
{
  "loopback-explorer": {
    // config
  }
}

We need to extend loopback-boot so that a component like loopback-explorer can be disabled in production via the following JSON file:

// server/component-config.production.json
{
  "loopback-explorer": null
}

@raymondfeng Thoughts? This is similar to (but not the same as) the way how middleware can be disabled on per-environment basis via server/middleware.production.json. I am also aware that this feature is useful for 2.x only, as strongloop/loopback-boot#93 will obsolete it.

/cc @PradnyaBaviskar

[raymondfeng]

@bajtos With your proposal, do we need to change the loopback-explorer code to accept the config object and decide if itself should be disabled?

[bajtos]

No, loopback-explorer does not need to be changed, this feature will be handled by loopback-boot. That's why I am proposing loopback-explorer: null as opposed to loopback-explorer: { enabled: false }.

[raymondfeng]

OK, so if loopback-explorer: null or loopback-explorer: false is configured, loopback-boot doesn't even bother to load the loopback-explorer component, right? If so, I'm +1.

BTW, we should consider to use this convention to remove/disable properties inherited from base models.

[bajtos]

OK, so if loopback-explorer: null or loopback-explorer: false is configured, loopback-boot doesn't even bother to load the loopback-explorer component, right? If so, I'm +1.

Yes, that's the plan

BTW, we should consider to use this convention to remove/disable properties inherited from base models.

I am fine with that, thought it's completely out of scope of this issue.

[ricardohbin]

surely @bajtos, I can give a look at this ;)

[bajtos]

The loopback-boot change has been landed via strongloop/loopback-boot#103, let me know if it works for you.