Could the principles of Calm Technology provide the basis of a methodology for evaluating Tech We Trust?
Yes! Keep it simple stupid.
However, we cannot do everything ourselves immediately. In the meantime our reality includes complex systems we cannot fix overnight. It is prudent for use to use the best tools though they may be bloated. Calmness is at the end of the rainbow of frameworks and services we use but as a user becoming enabled in the app ecosystem I need to use the best tools available today in spite of how they are implemented and the number of dependancies.
I think we need a front end back end like QraphQL despite the bloat. It provides a user view of information independent of their organization of their sources. It enables user objects independent of the developer objects user have no control over. It simplifies user programming immensely by removing all concerns about data sources. It can enable an agile ecosystem where we might control our self-sovereign interface to our stuff, stitch our stuff to other graphs with privacy by default and capability based security and share programs and resource configurations among ourselves we can deploy ourselves on our private clouds.
I am always happy to try a calmer front end back end enabling the same utility. We can keep QraphQL as only an emerging standard for addressing information in our view of the world and replace the bloat later. In the mean time we can organize and orchestrate our information resources employing GraphQL and seamlessly migrate into a calmer future.
I suggest we also embrace The Reactive Manifesto
Complex systems tend to fail. The more elaborate systems are the harder they are to maintain, diagnose and standardise. Moreover, complex systems increase the risk of exposing more security vulnerabilities.
Should we trust tech built on the basis of developer expediency or the principles of Calm Technology? I would choose the latter.
I agree completely but do not consider GraphQL excessive bloat. Einstein said make things as simple as possible but not too simple. As individuals it is possible for us to control the front end of software we use. Generally we have little control of the back end. A self sovereign tech stack requires a back end of the front end in order that applications are not enslaved to the back end. As we move to browser based apps making front end application development independent from back end development liberates the user interface application.
The front end developer needs tools to make it easy. The extra libraries aiding that process should not be considered bloat.
GraphQL makes rich application development as easy as copy and paste much of the time granting the ability to control their apps to non-programmes. We can envision graphical interfaces giving control to ordinary users without having to copy and paste stuff.
With GraphQL documentation and client generation are free. Nodes are typed automatically. Applications are backend independent.
Using GraphQL, ReactJS and Apollo To Create Amazing Apps
Zero To GraphQL In 30 Minutes
Things are complicated but tools can make it easier to deal with the complex. I suggest a unified query and mutation language across the myriad of information resources is worth the bloat.
I posted this topic hoping to discuss the merits of Calm Technology. The topic seems to have shifted to the merits of GraphQL. I’ll attempt to respond in terms of both:
GraphQL is a query language for your API and a server-side runtime for executing queries. Backends that don’t natively support GraphQL require a custom GraphQL server wrapper. This undoubtedly introduces complexity and risk. GraphQL extends the surface area of attack and exposure of potentially serious security vulnerabilities.
Security should be the top priority of any self-sovereign identity technology stack. An architecture that prioritises frontend developer convenience over system integrity and trustworthiness does not adhere to the principles of Calm Technology.