Hacker News new | past | comments | ask | show | jobs | submit login

Solid holiday week project, I like the name! To give some feedback:

- The main use cases I can think of for nap are (a) blackbox integration tests [0] and (b) a trackable HTTP request library via git. At my previous job, we built a similar tool (not nearly as feature rich as nap) to compare stable and candidate API versions. We'd run the library of HTTP request against each version and report on any difference in assertions.

- Scripting makes sense in the form of hooks imo. As a user, I would want to execute Javascript pre-request, post-request, pre-response, post-response, etc.

- There's nothing REALLY BIG you're missing. I think the primary value here is that it's a light weight tool that can be re-used for all sorts of workflows and platforms.

[0] The blackbox integration test use case is an interesting one. There's a recent trend in Javascript-land where some tooling is being moved to Go or Rust for the sake of speed -- integration tests may benefit from improved speed and concurrency. I tend to write tons of integration tests using Jest and they add up to a noticeable amount of time when running in CI.




First, thanks for taking the time to leave your thoughts. Blackbox integration tests are definitely the ultimate goal here. I think tool works as a request library on teams where the typical QA is comfortable with terminal/yaml. Where I work the QA team is already scared of Postman so it'll need a UI probably for them. I have some ideas on reducing how much scripting is needed (expectations was the first, but for custom scripting probably some global interceptor type thing will work), since that'll easily be the most complex part of the tool's use. Pre/post request hooks were one option I had in mind also, so I'm glad to hear it echoed here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: