Live data from Hacker News

Show HN: A Swiss army knife for testing HTTP from the terminal

news.ycombinator.com

31–40 of 47 posts

Re: Show HN: A Swiss army knife for testing HTTP from the terminal

#31
post #16
post #12

Earlier quoted context omitted.

> Have a better installation story like a single executable. Holy guacamole this is an entitled sentiment. It’s an open source project and it’s free.

Feedback was explicitly requested. That was my feedback on installation. It's not entitled and has nothing to do with the project being free or open source. Where'd that come from?

Probably from the way it was worded.

Re: Show HN: A Swiss army knife for testing HTTP from the terminal

#33
post #20
post #15

does this require Node.JS? edit: it looks like you need to install 1276 npm dependencies to use this tool https://github.com/artilleryio/artillery/network/dependencie... i'll pass, the risk is unacceptable for value it offers, especially in corporate environments

honest question to the authors: why cannot this tool not be written in JavaScript? what technically prevents you from designing the tool independent of the Node.JS and JavaScript ecosystem?

Maybe it's what they know. Common advice for startups is to not get mired in language/framework debates: use what you already know.

Re: Show HN: A Swiss army knife for testing HTTP from the terminal

#34

It would take me something extraordinary to move away from curl

In Emacs, I found the restclient plugin quite useful. https://github.com/pashky/restclient.el I imagine other editors have similar plugins.

Awesome! This comment made reading this thread worthwhile.

Re: Show HN: A Swiss army knife for testing HTTP from the terminal

#35
post #18

Earlier quoted context omitted.

Sure, if you've got muscle memory for all the flags (plus it lets you reason about all the other programs that pipe stuff to curl). I personally find myself using httpie [1] at least as much. 1: https://httpie.io/

I think curlie is the middle ground and the best (IMO) in the space. A nicer CLI for interactive use and can use and output curl flags for scripting.

As a maintainer, I feel obligated to mention Hurl [1], a tool for testing HTTP with plain text and curl. It’s a wrapper around libcurl, in a single binary, with syntactic sugar for asserts. You can use it also like curl to give you an HTTP output.

[1] https://hurl.dev

Re: Show HN: A Swiss army knife for testing HTTP from the terminal

#36
post #14
post #13

Earlier quoted context omitted.

https://www.artillery.io/blog/swiss-army-knife-for-http-test... Does artillery properly escape the environment variables into json strings? I don't see how it could if you're using bash expansion in double quotes. This feature would only work with string values without spaces or special characters. Don't really see any improvement here. https://www.artillery.io/blog/swiss-army-knife-for-http-test... So by embedding a…

Yeah so the JSON quoting part is something I’m pretty pleased with. We use a YAML parser (JSON is a subset of YAML) to parse those values, which is what allows for double quotes to be omitted. Good point on iterating on the query! We already save the body into a temp file, so we can make Probe be able to run queries on a file. Adding it to the todo list. :) (In my own workflow I use gron a lot for getting an overview…

> We use a YAML parser (JSON is a subset of YAML)

I believe that has more sharp edges than one might suspect

      --json "{username: testuser, password: testpassword, birthdate: 2022-05-10}"

    ...,"birthdate":"2022-05-10T00:00:00.000Z"}
The user may be less surprised if the flag were named "--yaml-as-json" or whatever DX friendly variant one wishes, in order to more clearly mark that string as yaml. The user is actually told about the "JSON or YAML", but only if they try to include some scalar value that isn't legal yaml

Also, I appreciate that every service should strive to respond in 10s, but there wasn't an obvious way to get it to be more patient

    RequestError: Timeout awaiting 'request' for 10000ms
        at ClientRequest. (/home/node/node_modules/got/dist/source/core/index.js:962:65)
followed by a ginormous stacktrace and a console.error dump of some event object

Re: Show HN: A Swiss army knife for testing HTTP from the terminal

#37
post #15

does this require Node.JS? edit: it looks like you need to install 1276 npm dependencies to use this tool https://github.com/artilleryio/artillery/network/dependencie... i'll pass, the risk is unacceptable for value it offers, especially in corporate environments

> Think mini-curl with better UX for common use-cases, plus a couple of extra features.

> it looks like you need to install 1276 npm dependencies to use this tool

Sincere question (probably highlights my lack of understanding Node package management): how can this be a "mini" curl with that many dependencies?

Re: Show HN: A Swiss army knife for testing HTTP from the terminal

#38
post #15

does this require Node.JS? edit: it looks like you need to install 1276 npm dependencies to use this tool https://github.com/artilleryio/artillery/network/dependencie... i'll pass, the risk is unacceptable for value it offers, especially in corporate environments

> Think mini-curl with better UX for common use-cases, plus a couple of extra features. > it looks like you need to install 1276 npm dependencies to use this tool Sincere question (probably highlights my lack of understanding Node package management): how can this be a "mini" curl with that many dependencies?

“mini” in the sense that it doesn’t do everything that curl does. curl does a whole lot. this tool focuses on more common use cases and makes them friendlier. plus with request waterfalls and assertions it does things curl can’t do.

the number of packages is a bit of a misnomer anyway. Artillery Probe is part of Artillery which does load testing, with multiple protocols, support for multi-step scenarios, publishing to a variety of monitoring systems (Datadog, Prometheus etc) and more. That’s what most of those packages enable.

Re: Show HN: A Swiss army knife for testing HTTP from the terminal

#39
post #36
post #14

Earlier quoted context omitted.

Yeah so the JSON quoting part is something I’m pretty pleased with. We use a YAML parser (JSON is a subset of YAML) to parse those values, which is what allows for double quotes to be omitted. Good point on iterating on the query! We already save the body into a temp file, so we can make Probe be able to run queries on a file. Adding it to the todo list. :) (In my own workflow I use gron a lot for getting an overview…

> We use a YAML parser (JSON is a subset of YAML) I believe that has more sharp edges than one might suspect --json "{username: testuser, password: testpassword, birthdate: 2022-05-10}" ...,"birthdate":"2022-05-10T00:00:00.000Z"} The user may be less surprised if the flag were named "--yaml-as-json" or whatever DX friendly variant one wishes, in order to more clearly mark that string as yaml. The user is actually tol…

thanks for trying it out! adding “make timeouts configurable” to the todo list.

you’re right on that YAML-as-JSON thing. If everything is quoted as JSON, those type conversions shouldn’t kick in. Otherwise there’s room for surprises - perhaps we can do something to make those cases more obvious.

Re: Show HN: A Swiss army knife for testing HTTP from the terminal

#40
post #24
post #21

Earlier quoted context omitted.

sure, that’s a valid concern in some environments. fwiw we use Snyk.io for dependency scanning

no, this is a valid concern in all environments, but in some environments this is more of a concern > Snyk.io for dependency scanning so what? does the CLI update itself automatically?

Yes, those dependency trees can be large. Yes, supply chain attacks are a real threat. But Node isn’t that different than Python or Ruby in that regard. How far down the stack do you personally choose to go? I trust you’re familiar with that famous paper published by a certain mr Thompson in the mid-80s?

The world is a big place. There’s a lot of software out there written in Node.js, used happily and productively by millions of developers, many of them in corporate environments.

Given the opinions you expressed elsewhere in the thread here I think it’s clear that this tool is not for you. I hope no one is forcing you to use it.

Post reply on HN