idea: rapidly create throwaway mock-services from command line

[davidmarkclements]

in shell:

fuge> mock my-mock-service
Pattern: {'role': 'service-to-be-done-later', cmd: 'uwatm8'}
Response:
   {
      res: 'ok', 
      nahnah: true
   }
Ctrl^D
Pattern: Ctrl^D
creating mock service
starting mock service
fuge> ps
name                         type            status          watch           tail            count
mongo                        docker          not managed
apache                       docker          not managed
service1                     process         started         yes             yes             1
my-mock-service              mocked          started         n/a             yes             1 

Pattern: and Response: are prompts, the data that comes after is user supplied

The idea is it's framework independent - simply define pattern and response

There's a few angles here

1) create a temporary service that disappears when the shell closes 2) as 1, except don't disappear, save it somewhere internally (not as a generated seneca service) 3) possibly create a way to "commit" or "convert" a mock service into a full generated service, building boilerplate around supplied pattern-responses 4) add/remove/edit pattern-responses for a mock-service

[mcollina]

How can you make it non-specific to seneca? You still want to mess with transports...

[davidmarkclements]

I don't think we'd need to in this scenario - the idea is we're stubbing out something in the system while we build other parts.

If we assume point to point - fuge proxy can take it from there

Whether you're using seneca or not, regardless of transport for other services, you know you're talking to a mock service over http req/res. so with seneca it would be a simple seneca.listen and no args, for anything else it would be some http lib or what not. Once you build that service you choose to set the transport (e.g. add a beanstalk arg to seneca, or whatever way you'd do it without seneca)

[davidmarkclements]

just to add - the underlying code that creates the mock service could (and probably should) be seneca - the point is that shouldn't matter to the overall system

[pelger]

Interesting - definitely worth a ponder...

[davidmarkclements]

just noting micro by @rauchg here as an example of alt. micro-service approach that could/should/would be compatible with fuge

[mcdonnelldean]

@davidmarkclements @mcollina @pelger

I just want to flag that in using fuge in anger I am starting to think the generation stuff should be pulled out into another module. It's not that I don't use it (in fact I intend to build some generators) but I'm just worried it might be doing too much.

Sorry to butt in here, it seemed like a good place to flag.

[mcollina]

I'm completely with you @davidmarkclements

[davidmarkclements]

@mcollina - yay

@mcdonnelldean - have had a few related convos with @pelger about this - but let's discuss elsewhere (possibly new issue)

[mcdonnelldean]

@davidmarkclements Agreed. On this issue, (mocks) yay from me! Love the idea of being able to do this for fast prototyping. +1 from me

[AdrianRossouw]

what's the difference between using a scaffold to pop up a test service, and then not committing it. versus this kind of inline mock.

you could even add them to the .gitignore if you really don't want them to be persisted.

[AdrianRossouw]

@mcdonnelldean @davidmarkclements - we need our own scaffolding tool

[davidmarkclements]

@AdrianRossouw agreed