jq is a hugely useful tool for anyone dealing with JSON of varying shapes and sizes. If that’s you, but you haven’t given jq a serious try, this is a great little primer on its use and use cases.

Peter Ohler:

I had a dream. I’d write a fast JSON parser, generic data, and a JSONPath implementation and it would be beautiful, well organized, and something to be admired. Well, reality kicked in and laughed at those dreams.

This post lays out Peter’s plan, his journey, and his lessons learned in great details. Seems like it’d pair nicely with the recent Go Time all about JSON.

JSON (JavaScript Object Notation) is used all over the web as a text-based way of transmitting data. In this episode, we explore Go’s encoding/json package, and others with Daniel Marti.

I love this idea of having a singular, parseable data source for your resume that can be read & formatted in many different contexts & places. Once cool example of this is react-ultimate-resume which uses JSON Resume as its data source.

This does not mean curl can fetch some JSON and print it to STDOUT. That would not be new. What it means is that the --write-out option now supports JSON as an output format. Pipe that output to a tool like jq and you get something like this:

{
  "url_effective": "https://example.com/",
  "http_code": 200,
  "response_code": 200,
  [lots more but I snipped them for length]
}

Which is pretty cool, if you ask me.

Think of this like jq, but for people who love parentheses. 😀

cat test.json | jql '(elem "countries" (elem (keys) (elem "name")))'
[
  "Poland",
  "United States",
  "Germany"
]

When demoing Hyperview to new engineers, there’s one comment that frequently comes up about the HXML data format:

“XML, really? It’s bloated and outdated. Why not use JSON? It’s the future.”

These comments imply that JSON is the “one true file format” that should be used for everything, but we don’t believe there’s such a thing. Each format makes tradeoffs in encoding, flexibility, and expressiveness to best suit a specific use case.

The author makes a pretty solid argument that JSON is better for lists, while XML is better for trees.

JSON formatted files are readable to humans but the lack of comments decreases readability. With JSONC, you can use block (/* */) and single line (//) comments to describe the functionality. Microsoft VS Code also uses this format in their configuration files like settings.json, keybindings.json, launch.json, etc.

This is a Go-only implementation, but the concept is portable to any language (hint, hint).

A HTTP based JSON storage. It lets you store, read & modify JSON data over HTTP APIs for FREE. Ideal for small projects, prototypes or hackathons where you don’t have to spin up your own data store.

Please don’t store anything mission critical here, but like the quote above says this could be a nice option when you just need a place to temporarily dump some data you’re working with. Simply grab a BOX_ID from the homepage and then POST away:

curl -X POST 'https://jsonbox.io/$BOX_ID' \
    -H 'content-type: application/json' \
    -d '{"name": "Schrute", "position": "Assistant (to the) Regional Manager"}'

{
  "How to use": "Paste your JSON here and press Ctrl+Enter to format!",
  "Help": "Check the console for errors if it fails to parse.",
  "Themes": "Toggle dark/light theme with Ctrl+B",
  "Share": "Print a shareable URL to the console with Ctrl+L",
  "Source": "View the source on GitHub at https://github.com/kritzware/json",
  "Info": "Press Ctrl+I at anytime for a reminder of these instructions"
}

Built with Nuxt.js.

The Couchbase team did a great job putting together this fairly-reasoned analysis. It gives side-by-side comparisons of Postgres’ JSON query syntax and SQL++/N1QL, which is the query language used in Couchbase. It touches on indexes, performance, ergonomics, and finally where each is a good fit.

I’ve personally found that Postgres’ JSON data types provide just enough document-orientation that I can sprinkle in where it makes sense in our data models. But, as with all things in developer-land, YMMV!

This looks great for quickly seeing the structure of a JSON object without all the scrolling. Pretty cool that the output is valid JS so you can copy/paste it to other places as well.

Inspired by jq and GraphQL.

Ludicrous speed!

That gif is worth 1k words vs me trying to explain it to ya 👇

JSONPlaceholder is a free online REST API that you can use whenever you need some fake data. It’s great for tutorials, testing new libraries, sharing code examples, …

It comes with a set of 6 common resources. You know, the usual suspects like /posts and /comments. Prefer to use your own data? The whole thing is powered by json-server, which will get you up and running in 30 seconds-ish.

This is an excellent post with some immediately useful takeaways (and some open source, to boot). Chris starts it with a compelling description of JSON API’s value proposition:

how to use JSON API as an “anti-bikeshedding weapon”

Building Restful APIs requires hundreds of tiny decisions, which is like having a bike shed on every corner. Outsource the little stuff!

Transforms JSON into discrete assignments to make it easier to grep for what you want and see the absolute ‘path’ to it. It eases the exploration of APIs that return large blobs of JSON but have terrible documentation.

Also works in reverse, so you can turn your filtered data back in to JSON.

To display a tweet properly, it needs to be well formatted. This means identifying and linking entities like usernames, hashtags and URLs. In simple terms, it is converting a typical tweet object like this…

It is dizzying how complex the tweet data structure has become over the years. We’ve come a long way from 140 characters of unicode.

It’s unfortunate that this only works with iTerm2. Anybody up for a port? 😏

Pipe some JSON to the quicktype CLI and it will spit out types and code to read/write/validate the data in your language of choice. Currently supports 10 target languages. There’s also a web-based version so you can kick the tires.

Chris McCord with a great round-up of advancements to the popular Elixir web framework. Highlights include H2 support, faster dev compilation, and a harder/better/faster/stronger JSON encoding library.

Imagine a JavaScript app that keeps all of its state in model objects. Now imagine that those objects are automatically synced and merged across network-attached devices. That’s Automerge in a nutshell.

It works a lot like Git, really, except for one big difference… no merge conflicts to resolve!

The Netflix team managed to squeeze out some huge performance improvements over Active Model Serializers:

We want to ensure that with every change on this library, serialization time is at least 25 times faster than Active Model Serializers on up to current benchmark of 1000 records.

At first glance I thought this was a drop-in replacement for AMS, which would’ve been epic, but it has its own API. That being said, its API is pretty similar and looks easy to use.

Exactly how much faster is this library? It can serialize 250 records in 3.01 ms vs AMS’s 138.71 ms!