executor: allow to boot loopback without remotes

[yorkie]

Hi StrongLoop community, I created another loopback runtime which doesn't have remote objects, of course no middleware and phases will be defined there, I also wanna use loopback-boot to boot that application, but occurred some errors on checking/assertions in this repository.

Created this PR to fix what I have met :-)
Another runtime of loopback-similar is at https://github.com/weflex/pancake-agent

[yorkie]

Ping ~~

[superkhau]

@bajtos I'm assigning this one to you as you are the expert in this area.

[bajtos]

Hello @yorkie, thank you for the pull request.

First of all, I am wondering why cannot you modify your pancake runtime to accommodate for the requirements of loopback-boot?

Since setupMiddleware already returns immediately when there are no middleware entries, why can't you modify your bootloader to delete middleware entries from the instructions?

Alternatively, what is preventing you from implementing dummy app.middlewareFromConfig() and app.remotes() that will not perform any actions but simply fulfil what's expected by the consumers of this API?

I guess my main concern is that by starting to support runtimes that are similar to loopback but not fully API compatible, we will have to add more and more exceptions later in the future, which will increase maintenance costs.

[raymondfeng]

BTW, for the newly refactored/enhanced loopback-boot (#181), you are allowed to configure what plugins should be used. As a result, you can skip middleware/swagger.

[yorkie]

I guess my main concern is that by starting to support runtimes that are similar to loopback but not fully API compatible, we will have to add more and more exceptions later in the future, which will increase maintenance costs.

Yup, this is what I want to do in this PR.

BTW, for the newly refactored/enhanced loopback-boot (#181), you are allowed to configure what plugins should be used. As a result, you can skip middleware/swagger.

Ok, let me wait for #181.

[bajtos]

Closing in favour of #181