
Javascript drives the technology market
Everything gets built using javascript
Javascript eats the world
The hype about javascript is real.
Quicker you jump faster you can run.
This blog is about what in my belief will be the next thing that gets built using javascript. I strongly think a simple object getter and setter will be the API protocol trend setter and that why it will outnumber mutation and query of GraphQL. Also I’ll explain with comparison, justification, a backendodel, persistence based on object get, set.
Important - ObjectQL is just a name to signify that something new is coming and in reality no such terminology exists.There won’t be any explanation of why something like graphql will be replaced. It won’t but it will have a brotherhood.
In graphQL there are two operations.
Let's derive an alternative protocol from it. When we look at a computer bare metal there are only two operations.
When we look at web applications there are four main operations.
The reason bare metal has two operations but a web application has four operations is optimisation (micro) which we will take care by a better design.
Create update is a write operation and in javascript object notation it is the same operations.
Example - create
var a = {};
Example - Update
var a.name = “true”;
A.name - is a new property creation, a property accessor
Assignment is a write operation.
Next operation is delete. Delete can be seen as delete of a property or update on parent. This is similar to put vs patch.
At this point I have reached no return and instead of explaining to myself I went coding whatever the theories were.
I want usage of
Store = getObject({})
Store.AssessmentTEmplates = [];
Store.assessmentTemplates[1] = {id: 123}
Store.assessments = [];
Store.Assessments [0] = {id : 123}
To persist in the backend for a working version, I chose nodeJS for the BE and it became much simpler. I wanted to automatically push the updates on the store to BE but I wanted to retain the syntax as it is. So I wrote a universal getter and setter and added a network post call similar to graphQL to .
let getObject = (original) => {
return new Proxy(original, {
get(target, name, receiver) {
let rv = Reflect.get(target, name, receiver);
// need to store parent for array values as the key is an index not a propert
parent = name;
return rv;
},
set(target, name, value, receiver) {
// Proxies new objects
if(typeof value === "object"){
value = getObject(value);
// write object
}
if(typeof Number(name)!== NaN){
// use the parent
console.log(parent);
// write object in index
}
// persist
persist(proxy);
return Reflect.set(target, name, value, receiver);
},
deleteProperty: function(target, property) {
if (property in target) {
delete target[property];
// persist
persist(proxy);
}
}
})
}
function persist(value){
fetch("/store", {
// Adding method type
method: "POST",
// Adding body or contents to send
body: JSON.stringify(value),
// Adding headers to the request
headers: {
"Content-type": "application/json; charset=UTF-8"
}
})
}
Whenever I modified the object, it sent to server. This kind of persistence is ideal for application which shares same data for all users. The same design can be used for application that don’t share data among the users to by maintaining users at the top of the store. This blog will not talk about it.
How is this a brotherhood of graphQL and how it will be a trend?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |