EDUCAÇÃO E TECNOLOGIA

oData, GraphQL and ObjectQL


Javascript drives the technology marker

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.

  1. Query
  2. mutation.

Let’s derive an alternative protocol from it. When we look at a computer bare metal there are only two operations.

  1. READ
  2. WRITE

When we look at web applications there are four main operations.

  1. CREATE
  2. READ
  3. UPDATE
  4. DELETE

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?

  • Uses POST same as graph
  • Tight connection between front end and the backend.
  • I’m not sure and this exercise was mentally interesting and never reached production.

This is a start for a new protocol for client server communication using javascript and offers in-time synchronisation. Try it out, and I’d be glad to know your feedbacks or improvements on the design.