Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support protocols implemented in other languages #174
JDBC is an example that would be difficult to implement purely in node, but should be quite reasonable implementing in Java. A protocol that shelled out, taking the imposter config as stdin and output the response, could make for interesting extension.
It feels like custom protocols should be passed on the command line, since they're a security vulnerability when shelled out through the API if it's called remotely:
Then you could call it as normal:
mountebank could ship with core ones like jdbc that hide the fact that they shell out from the user, while still allowing new ones to be tested before inclusion in the core.
A second shell call could generate the response.
After further thought, handing off TCP packets to another process and expecting them to transform that into a mountebank request means not taking advantage of server libraries written in other languages. If I had written http by handing off TCP packets to another process, I wouldn't have been able to use http server code; I would have had to use TCP code and completely re-implement an http server.
An alternative architecture may be needed. For all protocols, mountebank could fork a new process that spins up an actual (http, tcp, ldap, jdbc, etc) server. The core mountebank server (port 2525) could add an endpoint that translates a mountebank-encoded request (e.g. just the fields the user cares about) to a mountebank-encoded response, which the actual server could transform into a real network response. That means all behaviors and predicates would be handled by mountebank, as well as managing the state of requests for the --mock flag, and all network management could be handled by the other process. Logging could either use the stdout file handle given by mountebank, or use a mountebank endpoint from the protocol server to mountebank. mountebank could stop the process to kill it, meaning there would not need to be any admin endpoints on the protocol itself (I think).
Originally, mountebank created imposters in-process, simply by opening up a new socket of the given
Supporting more protocols means making protocols easier to add. This requires removing any hooks
The next interaction is the request to http://localhost:2525/imposters, which validates the request
The call to
The protocol should accept connections and simplify each request to the protocol-specific
Proxying adds complexity. For a proxy response, mountebank should respond to the call to
I'm concerned that the process creation could create a race condition. As it stands right now,
Something the mountebank process itself does is to rely on the pidfile creation to remove
It's also unclear how mountebank will handle the DELETE request for an option. Should it
There are four interaction points not well covered by the architecture above: documentation,
Logging may be handled by capturing the stdout stream of the child process
Some of the concerns above could be solved by having each protocol exist as a library and an optional application. The node library could be responsible for starting and stopping (which maybe could even be in-process), ensuring that the app is bound to the socket before returning (e.g by having the app write to stdout), validation, documentation, etc. The app could work as described above.