discussion: overlap with secret-stack

[dominictarr]

when I saw your readme, I instantly saw that this was nearly the same as secret-stack

except for the main thing being that secret-stack integrates secret-handshake. I'm planning to rewrite that - actually probably throw it away and write a new thing - secret-stack enabled some separation between services, and a well defined way to load them in or not and to generate a client manifest for interfacing with them.

The main problem with secret stack is that the dependency relationship between plugins is totally implicit. there are several plugins in scuttlebot, that depend on other plugins, it's totally not obvious looking at their code. (because there isn't anything analogous to a require(...) section that loads deps, but like code comments... it's probably not right.

implementing https://github.com/dominictarr/depject has totally changed my thinking about this.
but checkout where I am planning on taking things in https://github.com/dominictarr/depject/tree/v2

[dominictarr]

(I havn't decided yet how depject will attach to muxrpc)

[ahdinosaur]

hey,

yeah, this was heavily inspired by secret-stack, but left out anything i didn't understand or was unnecessary complexity for my use case: a monolithic web app.

the question of dependency relationships is a good one. at the moment each service receives the current state of the server being constructed, so if it needs to call another service it can do so if it is after the other service. but yeah, making this more explicit would be nice.

keen to see how to integrate depject with muxrpc, thanks for sharing. at the moment this isn't a huge priority for me right now because my only use case is monolithic web apps, although in the future i would like to have re-usable services that may depend on each other, patchbay is awesome.

[dominictarr]

depending on ordering makes merges more likely to fail, therefore, requires more maintenance, therefore is centralizing. even if it's a team within an org, easier merges still means easier development.
I havn't figured out how to do fully disorderly programming yet, this is just on the edge of my thinking.

probably muxrpc will just be exposing an object which is the public api...