Because if your way of interacting with the database is encoded in a consistent JSON format, then the server can analyze it easier to decide what to do. That should make sharding and clustering a lot easier.
This wording makes it sound like this is an advantage for the server, that it enables things you otherwise wouldn't be able to do in the server. But even with SQL, something, usually the server, parses the text/string based query into what is essentially a format similar to this. Sharding and clustering would be "easier" too if you didn't need to do them in your application, if the server side stuff just handled it. Removing the need to parse SQL can remove the need to do that from your stack, but the server usually handles this anyway. The way we think about sharding and clustering now usually puts that functionality into the application or into middleware where you need to be aware of it. There's nothing stopping a server from taking a text based SQL query and offloading all those scaling features from the app itself.
You should look at Metaweb query language (http://mql.freebaseapps.com/ch03.html) -- it uses JSON in a reasonably intelligent way to do precisely this.
"Now why do this? Because if your way of interacting with the database is encoded in a consistent JSON format, then the server can analyze it easier to decide what to do."
I've written a SPARQL query parser, which is somewhat similar to SQL. Parsing the string into your internal memory representation is not the hard part of writing a query engine. It's really not difficult to transform SQL into the JSON/SQL shown in the article.
What makes this so great is how many people will take it seriously and angrily comment about this absurdity. Zed Shaw is the only person I know of that will troll by writing extensive amounts of code. It's rather incredible.
This wording makes it sound like this is an advantage for the server, that it enables things you otherwise wouldn't be able to do in the server. But even with SQL, something, usually the server, parses the text/string based query into what is essentially a format similar to this. Sharding and clustering would be "easier" too if you didn't need to do them in your application, if the server side stuff just handled it. Removing the need to parse SQL can remove the need to do that from your stack, but the server usually handles this anyway. The way we think about sharding and clustering now usually puts that functionality into the application or into middleware where you need to be aware of it. There's nothing stopping a server from taking a text based SQL query and offloading all those scaling features from the app itself.