What’s the use of JSON? – JavaScript – SitePoint

I just learned the basics of JSON. But I wonder what its use is. I I know that you can store and retrieve data with it, but a .json file can be directly downloaded with a browser, let alone a .txt file. So you can only use those if you’re using data that are already publicly known. And then still, you may have hours of labour in creating the file.

Putting the data in a .php file in php JSON format can solve that problem, but that syntax makes it quite complicated again. Why not use an SQL database then?

Can someone explain why it would still be worthwhile to master JSON? Preferably with a real-life example? Thanx in advance.

Hi @fconijn, as far as web development is concerned, JSON can be particularly useful for exchanging data between the server and the client, where the latter doesn’t have access to the database:

my-endpoint.php

<?php $my_data = ['foo' => 'bar'];
echo json_encode($my_data);

my-page.html

<!DOCTYPE html>
<html lang="en">
<head> <meta charset="UTF-8"> <title>My Page</title>
</head>
<body> <script> fetch('my-endpoint.php') .then(res => res.json()) .then(console.log) // {foo: "bar"} </script>
</body>
</html>

JSON is mostly used to transport data. It is not used to store data.

To understand the usage you need to understand modern software design.

In the past PHP applications were backend and frontend in one. All was done in PHP. In fact HTML, CSS, JavaScript and PHP was mixed up in one file.

Today applications have strictly separated layers. In minimum you have backend and frontend. Mostly you have much more like database layer, presentations layer, Business logic layer etc.
But to make it simple let’s just assume we have frontend and backend.

For a web application this will mean that you have the frontend which is mostly done in a JavaScript framework like angular, react or smaller ones like vue or even vanilla JavaScript.
The backend can be developed in php but today it’s mostly done in nodejs, spring boot or even .net (if you are a masochist :slight_smile: )

The backend ist running on the server and is able to access the database, while the frontend is running on the client (mostly a web browser).

Let’s assume the frontend wants to display something. The design and UI is created by the frontend but the data itself is coming from the backend. So the frontend is requesting this data from the backend. This is normally done with a http request.

Let’s assume the frontend will show a customers data, so it requests the customer data from the backend and the backend returns this data.

Now you need a standardized format how this returned data should look like. You cannot transport binary via http so you have to use a text format. In the past formats like SOAP (based on XML) were very popular. But nowadays JSON has made the race, because JSON is super easy to read and a lightweight format.

With json you can serialize and deserialize objects to send and receive them in text format. That’s the big advantage.

When the below form is submitted for an authenticated user the submission is stored as json.

https://ng-druid.github.io/native_forms_rebuild_v1/89087abb-326d-4a93-888e-9c597ba81b8e

The json file can be seen here.

https://d12b7acm1cy55s.cloudfront.net/89087abb-326d-4a93-888e-9c597ba81b8e.json

preview:

{ "text": "cdsdfsfdsfsd", "select": "1", "textarea": "dsfs as c as d sa das d as d asd as d asd as d asds.\n\ndsfs as c as d sa das d as d asd as d asd as d asds.\n\ndsfs as c as d sa das d as d asd as d asd as d asds.", "radiogroup": "2", "slider": "72", "toggle": "83", "checkbox": "true", "datepicker": "2022-03-23T04:00:00.000Z", "autocomplete": "3198", "nested": { "nestedValue": "nested" }, "terms": [ { "humanName": "one", "terms": [ { "humanName": "a" } ] }, { "humanName": "two", "terms": [ { "humanName": "b" } ] } ], "id": "89087abb-326d-4a93-888e-9c597ba81b8e"
}

In a traditional database this would require multiple tables to store properly. However, in JSON the relational information like nested and terms can be stored as part of the single document. This eliminates the need tables.

This is another more traditional example of an ad with attributes stored as json.

{ "attributes": [ { "attributes": [], "computedValue": "30000", "displayName": "Asking Price", "intValue": 0, "name": "price", "type": 0, "value": "300,00.00" }, { "attributes": [], "computedValue": "1", "displayName": "Beds", "intValue": 0, "name": "beds", "type": 0, "value": "1" }, { "attributes": [], "computedValue": "2", "displayName": "Baths", "intValue": 0, "name": "baths", "type": 0, "value": "2" }, { "attributes": [], "computedValue": "2345", "displayName": "Sqft", "intValue": 0, "name": "sqft", "type": 0, "value": "2345" } ], "cityDisplay": "Seattle, Washington (98060)", "description": "ewrewr ew r ew r ew", "featureSets": [], "id": "012829c6-a75d-11ea-b84a-064be6bfebb4", "images": [ { "id": "40acff11-dc45-46c6-98c3-5608649d10cd", "path": "media/40acff11-dc45-46c6-98c3-5608649d10cd.png", "weight": 1 } ], "location": [ -121.8034, 47.4323 ], "profileId": "96677e25-c642-43e2-bd26-1e7305784a80", "status": 0, "title": "New realestate with photo", "typeId": "5665f5f8-5533-4aa1-96f4-b78e02714de0", "userId": "e36b42fe-b09c-4514-a519-e178bb52957e"
}

I would argue that creating the tables and MVC app to persist data is much more complicated than storing data in natural form as json. Especially if you are building a modern front-end using a mvvm framework like React, Angular, Vue, etc.

The demonstration above actually takes this concept further by completely eliminating servers and databases from the tech stack. This is two entire tiers eliminated. The entire app merely runs as a browser native program without a server or database.

In my case json has become a fast, cheap, simple means to store persistent data. Furthermore, there are a large array of storages that use json as highly available, scalable alternatives to a traditional database.

The demonstration above uses a CDN (https://www.cloudflare.com/learning/cdn/what-is-a-cdn/) that can reliably handle an estimated 3500 concurrent, parallel requests. However, there are other more traditional NoSQL options like MongoDB: https://www.mongodb.com/. The demonstration above uses aws s3 and cloudfront but cloudflare does a better job explaining a CDN than aws docs do.

For experimentation purposes you can setup a free Mongo database in the cloud for free: https://www.mongodb.com/atlas/database

If you wanted to try the CDN approach with php I would recommend using Flysystem (https://flysystem.thephpleague.com/docs/) with the s3 adaptor (https://flysystem.thephpleague.com/docs/adapter/aws-s3-v3/).

As seen in flysystem you could also use Azure BLOB or Google Cloud Storage as well.

The CDN approach is limited in search capabilities. The MongoDB approach is not. MongoDB offers many of the same features in terms of filtering, aggregating, searching data that traditional relational databases do. In fact MongoDB offers more features.

In my professional opinion the best search solution is one dedicated to the purpose. All of which use JSON for storage and queries. Many of these search solutions are also compatible with SQL queries like open search.

This is an example of a query in open search that uses json for the request body payload.

POST https://search-domain.us-east-1.es.amazonaws.com/classified_panelpages/_search/template

{ "id": "panelpagelistitems", "params": { "site": [ { "term": { "site.keyword": { "value": "ipe" } } } ], "path": [ { "wildcard": { "path.keyword": { "value": "*" } } } ] }
}

All this said basically any api that you use in this day and age will use json. In older projects you will find SOAP or proprietary methods but modern REST APIs are using JSON. However, its not just for data transfer. JSON can be used everywhere including storage.

As the previous replies have made clear JSON is string formatted data.
I use JSON to send and receive data to the server.
Servers requests can return the response as valid or as a server error
Valid server responses can be in plain text or JSON.
The JSON data I use includes a “status” field which is set to “ok” if the data is valid.
My php code always responds with JSON
Php errors come as plain text which during development get shown in a popup dialog window.
Php code exceptions are sent as JSON with the status field set to the exception type and the data to the exception file, line and stack info.
So when handling request responses I can determine whether the response is:

A server error
A thrown exception
Valid response data

After development instead of the popup an email to me will be generated.

@m3g4p0p — That PHP notation makes it quite a bit easier. But my-endpoint.php is still accessible with a normal http request, isn’t it? I can think of quite a few datasets that I’d rather not have publicly accessible.

You can prohibit that in your .htaccess file (assuming you’re on Apache).

Basically JSON is a common data transport layer, so that different systems can easily communicate structured data with each other.

You could, but then Ajax requests are blocked, too. And I’d think fetch requests as well?

Without saving it as a file on the server first? So, directly?

Yes JSON can be (and commonly is) used directly, no saving on the server is needed.

A lot of APIs require some form of authentication to allow a request to proceed.
If you want to restrict access to your PHP endpoint, you can set this up.

To recap what has been said, JSON can be used to store data (and is), but it is mostly used for transfer of data. A client’s request to a server, a server’s response to a client request.
So your PHP server may well still use SQL to store data, but when the client makes a request, the server pulls the data from the DB, formats it to JSON and sends to the client in response, JS can do the rest on that side.

Another use case where I have used JSON is in structured data mark-up. That can be set-up server side and included in the HTML page as it’s generally static. It’s just a neat way of presenting that data to Google in a way it understands, without too much complex messing up the of HTML mark-up as structured data was previously done.

As an aside…

Deep Cloning

JSON supports:

  1. primitive numbers and strings
  2. values true, false and null
  3. objects and arrays built up of the above types, including nested objects and arrays.

As long as your object only contains the above types, you can use a combination of JSON.stringify and JSON.parse to make a deep clone of that object. e.g.

const user = { id: 1, name: ['Bob', 'Smith'], email: 'bob@gmail.com', address: { street: '1745 T Street Southeast', city: 'Washington', postalCode: '20020' }
} // serialize and deserialize user object
const deepClonedUser = (JSON.parse(JSON.stringify(user))) // changes to cloned object only
deepClonedUser.name[0] = 'Robert'
deepClonedUser.address.postalCode = '20050'

Json.stringify can also be quite useful for logging out the properties of an object and maintain the original order.

console.log(JSON.stringify(user, null, 2 /* indentation */))
console.log(JSON.stringify(deepClonedUser, null, 2)) // user
{ "id": 1, "name": [ "Bob", "Smith" ], "email": "bob@gmail.com", "address": { "street": "1745 T Street Southeast", "city": "Washington", "postalCode": "20020" }
} // deepClonedUser
{ "id": 1, "name": [ "Robert", // <-- only changed on clone "Smith" ], "email": "bob@gmail.com", "address": { "street": "1745 T Street Southeast", "city": "Washington", "postalCode": "20050" // <-- only changed on clone }
}

15 posts were split to a new topic: NoSQL vs traditional databases

JSON is used extensively for storing data. For example see Data Files | Jekyll • Simple, blog-aware, static sites. It says:

Jekyll supports loading data from YAML, JSON, CSV, and TSV files located in the _data directory.

See Configuration in ASP.NET Core | Microsoft Docs; ASP.NET Core uses JSON for configuration data; appsettings.json and launchSettings.json.

There are thousands of other such examples.

See JSON; it says JSON (JavaScript Object Notation) is based on a subset of the JavaScript language. There has been very much that has evolved from JSON; many philosophies, like religions. The original use of JSON was in JavaScript for creating data in memory. It is not really objects even, since JSON has no members (in OOP they are called members; JavaScript calls them functions).

JSON is just a way to represent data. The simplicity makes it very useful.

I wish everything was that easy to explain. It is not that easy to get explanations of many other computer things, like Docker and Kubernetes. Determining the relevance of complicated software such as those can take months before being able to know if they are useful to you.

Data in other formats, including CSV, XML, database and spreadsheet, can be converted to/from JSON. It is possible to write an interactive (GUI) application to create (and maintain) data in any of those formats.

I hate containers. For the reasons you mentioned. I prefer serverless development. Serverless development takes the infrastructure completely out of the equation. No sacrifice in scale, latency or availability required. You just push up functions and everything just works. No need to host apis or apps in expensive, clunky, complex container driven environments that you need to manage. However, containers are far superior for hosting none serverless applications like a php website. However, if you with serverless optimized languages like nodejs, go, and python functions in those languages can just be pushed to lambda environments and become immediately available on the web without any server configuration or container setup. Not to mention a site hosted as a lambda can run for free in the cloud with generous free request tiers like 1million requests. In comparison to a container which always needs to be running and you pay arm and leg for and that cost just multiples as you need to scale and add more nodes.

Leave a Reply

Your email address will not be published.