up VS cats

This fx rewrite is very exciting. I'll have to try it. I thought of fx as a wrapper around jq, that allowed quick iteration over building jq scripts. Sort of an Ultimate Plumber [1] but only for jq. It looks like it is now more like a JavaScript processor plus an interactive viewer.

Someone mention Visidata[2]? VisiData is also a TUI that is great on tabular data, and it can work with json. If your JSON is mostly tabular in nature, Visidata does a great job at showing that data and allowing you to explore it. A lot of json I deal with is tabular-like data. There is a great tutorial [3], that can help you get your bearings with Visidata. Once you understand those basics you might want to look at this thread [4] for what commands you can use with json.

[1] Ultimate Plumber: https://github.com/akavel/up

Ultimate plumber can do this.

https://github.com/akavel/up

Been using up for years but this looks nice too

Fun. But I can achieve the same result (I think) with ultimate plumber and regular jq, but without being restricted just to jq. Feel free to correct me.

Up - The Ultimate Plumber makes the best pipes !

As an alternative allowing the use of any shell command/pipeline on the results interactively, see also: https://github.com/akavel/up

Would https://github.com/akavel/up solve your problem?

Out of this frustration I've built: https://github.com/Endava/cats. It's for APIs, but mostly addressing exactly this case: don't use strings for everything, if you choose to use it though, make sure you add patterns for checking if things are valid, make sure you think about all the corner cases and all the weird characters that can brake you app, and so on.

If the API has an OpenAPI spec available, you can use: https://github.com/Endava/cats

This is why we need better tools which will give benefits for the added complexity. If you need to create both the feature files AND the code, it's just complexity with little benefits. But frameworks like https://github.com/karatelabs/karate or https://github.com/Endava/cats are hiding this complexity and remove the code layer entirely. Which, in my view, this is where you need to be in 2023, particularly for API testing.

I've built a tool specifically to test if these kind of characters will reach API backends: https://github.com/Endava/cats. My idea was that APIs should explicitly reject or sanitise input containing such characters.

Cats by Endava