Show HN: Nap – A File-Based HTTP Execution Framework | Hacker News Reader

Show HN: Nap – A File-Based HTTP Execution Framework

github.com

5 pointstwodave3 comments

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.

So, this is an idea I've been scratching at during the holiday week. It's my first project in Go, so be gentle. The code hasn't quite caught up with the documentation, but I think I'm far enough where I'd like some feedback.

This project is an attempt to remove Postman as a dependency from my general workflows for testing HTTP APIs. The project name was chosen because it's short and a synonym for REST. I believe this sort of tool should:

- be free (MIT license)

- be file-based so work can be committed to Git

- easy to work with (at least for developers, via YAML and eventually some light scripting support)

- be able to run headless as part of a CI/CD workflow

No cloud cruft. No subscription model. No telemetry. No ads. Zero infrastructure. Maybe if I get enough interest I'll build a UI and sell that, but the core CLI should always be free.

I've got an idea how I'll be adding scripting support (probably javascript, via the Otto package).

Here's the ask--does this project make sense? Should I keep going with it? Is something REALLY BIG missing that I haven't mentioned?

Obviously I've thrown this together in about 10-15 hours--there's plenty of room for growth/refinement. Still, I think it fills a need. Worst case I'll be using the tool myself, but I want to know just how useful it is. Thanks in advance!

Reply on news.ycombinator.com