github.com/antonmedv/fx

fx is a terminal-based JSON viewer/processor that's handy for interactive exploration and debugging. In practice, it shines for ad-hoc inspection of API responses and log files during development. The interactive mode with syntax highlighting and navigation feels smooth for quick tasks.

From a security perspective, there are significant concerns. The library executes JavaScript via an embedded VM (goja) to process JSON transformations, which creates substantial attack surface when handling untrusted input. There's minimal input validation on the JSON or JS code paths, and error messages can leak file paths and system information. The dependency chain includes the JS runtime and various parsers that need monitoring for CVEs.

For production pipelines or automated systems processing external data, I'd recommend jq instead. fx works well as a developer tool on your local machine with trusted data, but integrating it into services that handle user input or external APIs introduces risk without clear security boundaries or sandboxing guarantees.

Using fx in day-to-day development has been refreshingly straightforward. It's primarily a CLI tool rather than a library you import, which means the 'API' is just command-line arguments and interactive keybindings. The learning curve is nearly flat - pipe JSON to it and start exploring. The interactive mode with syntax highlighting and collapsible nodes makes debugging API responses much faster than scrolling through raw JSON dumps.

The JavaScript-based filtering feels natural if you already know JS, letting you write `.filter()` and `.map()` expressions directly on your JSON. Error messages when you write invalid expressions are clear enough to fix quickly. However, documentation for advanced features is sparse - I had to experiment to discover some keybindings.

Community support is limited since it's a niche tool, but GitHub issues get responses. Most common use cases (pretty printing, filtering, selecting paths) work exactly as expected with no surprises. When things don't work, it's usually obvious why - typically a shell quoting issue rather than fx itself.

Using fx in Go projects is refreshingly simple - it's primarily a CLI tool that you embed or invoke. The learning curve is minimal because the core concept is straightforward: pipe JSON through fx and transform it with JavaScript expressions. When integrating it into Go applications, you're typically just executing the binary, so there's not much API surface to learn.

The error messages are helpful when you make syntax mistakes in your transformations, clearly pointing to where things went wrong in your JavaScript expressions. Debugging is intuitive since you can test transformations interactively in the terminal before embedding them in your code. The GitHub repository has responsive maintainers who address issues promptly, and there are enough examples to cover common scenarios like filtering arrays, extracting fields, and reformatting output.

The main limitation is that it's more of a standalone tool than a library with rich Go APIs. You're essentially shelling out to the fx binary rather than importing sophisticated packages. For basic JSON manipulation tasks this works great, but for complex programmatic usage you might want a pure Go solution.