This is a solid primer on the usefulness of jq (a lightweight, command-line JSON processor.)

In this article, I’m going to go over the basics building blocks of jq in enough depth that you will be able to understand how jq works. Of course, you still might occasionally need to head to google to find a function name or check your syntax, but at least you’ll have a firm grounding in the basics.

Too often, web tiers are full of boilerplate that does nothing except convert a result set into JSON. A middle tier could be as simple as a function call that returns JSON. All we need is an easy way to convert result sets into JSON in the database.

PostgreSQL has built-in JSON generators that can be used to create structured JSON output right in the database, upping performance and radically simplifying web tiers. Fortunately, PostgreSQL has such functions, that run right next to the data, for better performance and lower bandwidth usage.

I certainly wouldn’t advise this in many (most?) scenarios, but I can see a time and a place where “cutting out the middle man” would be quite advantageous, indeed. Keep it simple. Keep it lean.

Craig Kerstiens:

Postgres has had “JSON” support for nearly 10 years now. I put JSON in quotes because well, 10 years ago when we announced JSON support we kinda cheated. We validated JSON was valid and then put it into a standard text field. Two years later in 2014 with Postgres 9.4 we got more proper JSON support with the JSONB datatype. My colleague @will likes to state that the B stands for better. In Postgres 14, the JSONB support is indeed getting way better.

A small but solid improvement to how you query JSONB, making it more JSON-y than ever.

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.