Suggestion: implement API server as a module?

[PKGeorgiev]

I'm running into the following issue: I'm using NodeRED with the newest version of node-red-contrib-sonoff-server. The different in this version is that the node loads only the sonoff Dispatch/WS module (sonoff.server.module.js) but not the API part (sonoff.server.js). So if I need the API part I have to stop NodeRED (to avoid network port conflict) and manually run sonoff.server.js. This is a bit inconvenient since NodeRED is driving my real home automation flows.

That made me thinking if it is possible to implement the API part as a separate module (for example sonoff.api.server.module.js). It would accept "devices" object in its constructor. The file sonoff.server.js will stay the classic standalone nodejs app. It will take care only for building config, env vars and creating instances. Something like:

// call sonoff server for device handling 
var devices = sonoffServer.createServer(config);

var apiServer = sonoffApiServer.createServer({sonoffServer: devices});

This way node-red-contrib-sonoff-server may load both modules that share the same device repository.

[mdopp]

Just form my understanding, can you please let me know the reason, why you would like to have the http-server and node-red running at the same time? For me, everything that I was doing with the http-server can be done with node-red, but a little bit more elegant.
But if you let me know your case, we will find a way to re-integrate the http-server again.

[PKGeorgiev]

I'm currently working on a mini front-end that is using your APIs so it will not work. Also it is easier to me to enumerate devices and lookup their params in raw (json) form. Also to my knowledge node-red-contrib-sonoff-server does not show all parameters.

[PKGeorgiev]

Btw something else that I've struggled - the config options httpPort & httpsPort are named a bit confusing for me (and others too? #12 ) - I always confuse values - was it http or https etc. Also users should be familiar with the way sonoffs work which is not always the case. What do you think about giving these params more descriptive names like apiPort (a.k.a. httpPort), dispatchPort (a.k.a httpsPort)?