Feature / Idea(s): Expose lower level APIs

[hartzis]

First off, thank you for the amazing work @ijpiantanida, picking up from where yakbak left off and expanding on it was no small venture, so thank you.

I'm having amazing success with talkback. I'm integrating it into a stack that includes jest and puppeteer via jest-puppeteer.

Using jest and puppeteer I'm able to run my app in an actual browser, headlessly, and write jest tests against user flows to create a complete set of integration tests while having all the api requests proxy through talkback. This is in an early stage, but looks incredibly promising.

Feature Request / Idea:

puppeteer provides the ability to intercept http requests.

If talkback exposed some of the lower level apis like RequestHandler and OptionsFactory this could open up some incredible possibilities.

Using puppeteer's intercept functionality in conjunction with talkbacks tape recording functionality exposed via new apis without the need to create a whole new server could be extremely powerful.

Imagine it, having completely encapsulated full feature user flow integration tests run in a single node process. This aligns very strongly with your testing requirements from your great blog post.

As you can tell I'm super excited about these ideas and tooling possibilities.

In summary, again THANK YOU for your amazing work, and please let me know your thoughts/concerns. I'd love to explore making PRs where I can if this is something you're interested in.

---

Additional Idea: Talkback Middleware

Was additionally thinking talkback could expose a "middleware", which could help users who may already have a server, but still want to benefit from talkback's functionality without needing to make a whole new server?

const talkbackMiddleware = new talkback.middleware(opts);

app.use('/api', talkbackMiddleware)

[hartzis]

📓 In the process of exploring and vetting the above ideas and thoughts I stumbled across something very similiar useing pollyJS.

• https://github.com/Netflix/pollyjs/blob/master/examples/jest-puppeteer/__tests__/dummy-app.test.js

[ijpiantanida]

Hi @hartzis, I'm glad that you have found talkback this useful.

I really liked your idea of exposing the request handler API.

I just released a new version 2.2.0 which includes this feature. https://github.com/ijpiantanida/talkback#talkbackrequesthandleroptions-partialoptions-promiserequesthandler (I think I'm reaching the limits of what one README can handle 😄 ).

I've also included an example using puppeteer https://github.com/ijpiantanida/talkback/blob/master/examples/request-handler/start.js

[ijpiantanida]

For the middleware idea, I'm not sure if I'm understanding it correctly. If we're talking about intercepting request coming to /api/* and returning a saved response when they exist, or continuing the middleware chain if not, then I'm not sure it's something that I'd like to implement. I see how it can be convenient, but I don't like the idea of messing with the server's actual behavior. For now, I'm trying to keep talkback as an outside layer.

Now, if we're talking about providing a middleware just to mount Talkback without opening a new port, then that's something that can easily be implemented with the new request handler API

Feel free to open a new issue where we can discuss this further if I'm missing the point. Thank you for these great ideas!

[hartzis]

@ijpiantanida Wow, thank you, this is amazing! Even including an example with puppeteer!

The length of the readme is nothing btw, check out nock's readme, 1600 lines lol. I personally like a detailed readme. It can be nice to have all the details in one place.

I think more about the "middleware" idea, but i think a lot can be done with the new requestHandler api.

Again thank you!