The JSON Architecture An architecture pattern for data driven functional programming 

About Me Constantin Dumitrescu, find me as @dumconstantin on Ask me about: JS, FP, Docker, Automating things, Development Tools, Radical Management Projects: ramda-loader, json-patch-utils, baobab-jsoneditor Presentations so far: - The Philosophy and Practice of the Pure Function / 5 Feb, Cluj - The JSON Architecture / 11 May, Bucharest :) 

The JSON Architecture An architecture pattern for data driven functional programming - what it is, how did it come about, benefits? 

Overview 

Part 1. Data Transformations 

Data Transformation - The single purpose of computer programs is to move letters and numbers around - Why should the computer know what “this” is? - Unfortunately for them, data transformations should be data-less - OOP is when data and transformations are joined in marriage but always argue about separating - it’s painful, tedious and consumes a lot of resources 

Pure Functions 

Pure Functions - Are like atoms (“that which cannot be split”) - Probably the most boring thing in the universe - Always prefer curry-flavored functions - Pure functions know about the entropy of the input data - Can eliminate racism between programmers - Have random powers! (like Quickcheck) - Are reversible if the input types and output types align - Compose pure functions! 

Observables & Streams 

Observables & Streams *from RX Docs 

Observables & Streams - ... are the combination of CPS(continuation-passing style), Events, Promises, Futures and Channels - An Observable is an Array with wristwatches instead of commas: - Observables are like springs that create a stream - Flowing data is immutable - Now is not the time for errors, catch them later - Time stops when we stream - OMG! Thinking in 5 dimensions - Streams Pointfree - Compose streams! 

Part 2. Persistent Data Tree *from Redux Docs 

Persistent Data Tree - Avoids cyclic dependencies between data, one of the by- product of OOP in Time Driven systems - Data trees hold the absolute truth! - The connection between the data nodes are declared in a single place (the data tree) instead of a myriad of objects - The flow of data is obvious and unidirectional - The state is copied through reference, no memory leaks! - Same steps, same state - beat that OOP! 

Essential State 

Essential State - Like essential amino acids, comes from outside the system - Like collection items, you and label them precisely. Also, box them and keep them safe! - Never use Arrays! - ?!Has no meaning whatsoever for the program, simply put, it’s just letters and numbers - The Actors of the Business Domain create the essentials - Should be identical in shape and color on the Backend, on the Frontend, in the Database and everywhere - Keep the essentials, normalize somewhere else 

Derived and Accidental State 

Derived and Accidental State - Derived state is the combination and transformation of essential state - Accidental state is what happens when you don’t live in an ideal world and when you need to keep a journal - The Derived state controls the program. Demonstration: a) The program is controlled by “If Statements” decisions b) Decisions are derived from the truth d) The truth is the essential state e) “If Statements” use derived states, thus The Derived state controls the Program - Remember, you can always derive a derived a derived state, so compose the derived state! 

Cursors 

Cursors - Use them to see from far away - Kinda like Channels (CSP Communicating Sequential Processes) - You don’t care when something happens, but you’re looking anyway - Work on Essential, Derived and Accidental states - Deliver immutable data - Use them with streams! - Compose cursors! 

Dynamic Nodes 

Dynamic Nodes - Suprise! A dynamic node outputs derived state - They sit in trees! - Cursors + Pure functions = a dynamic node - Lazy, never do processing unless requested - Use events to signal updates - Fun fact! Most cursors in your application will watch a dynamic node - Compose dynamic nodes! 

Part 3. Effects 

No content

Effects & Side Effects - Effects are the reason you wrote the program in the first place - A side effect is: “any unintentional and detrimental consequence”, e.g. an infinite loop! - An effect begins where the system ends and the outside world begins - Mutating state is not a side effect, that’s just an intentional bad design - Any output is an effect: 42 - what was the question? - Effects should be declared in a declarative way 

Part 5. 

The Overview once again 

JSON Data & JSON Schema { "$schema": "http://json-schema.org/draft-04/schema#", "type": "object", "properties": { "user": { "type": "object", "properties": { "name": { "type": "string" }, "email": { "type": "string", "pattern": "^\S+@\S+$" } }, "required": [ "name", "email" ] } }, "required": [ "user" ] } { "user": { "name": "John Doe", "email": "[email protected]" } } 

JSON Patch & JSON Pointer let patch = [ {"op": "replace", "path": "/user/name", "value": "Jane Roe"}, {"op": "add", "path": "/user/address", "value": "51 Street"}, {"op": "test", "path": "/user/id", "value": 23} ] let data = { "user": { "name": "John Doe", "id": 23 } } let data = { "user": { "name": "Jane Roe", "address": "51 Street", "id": 23 } } 

Part 6: Demo Time 

Opportunities & Benefits - Real separation of concerns: 1) Controller: How it happens 2) Model: That Thing that something happens on 3) (Effects) View: What the world sees - Pointfree = Stop writing code! = 1000% increase in stability and whatever is bugging you... - Portability!!!! Take your code from one language to the next with minor syntax changes! - !!! 5 minute project handover !!! - Open sourced all the way! 

Opportunities & Benefits - Reuse everything between projects! - Bulletproof testing in isolation - Client stack traces no longer needed - just gimme the state.json file! - When developing the Effects you don’t need data transformations! Just modify the state tree as you please - Democratising Software Architecture - Focus on the business domain rather than on application bugs 

What the management needs to see - Better productivity = x2, x3, x4 more $$$ - Better quality (SLA anyone?) = x2, x3, x4 more $$$ - Appealing to investors - long term software without code decay or legacy code issues ($$$) - Hassle-free project handover internally or by third party - Learn once - use everywhere - interoperability between developers & technologies - Decrease lifecycle costs of software products $$$ 

And finally, The JSON Architecture is a postulate for making the life of developer’s happier, less stressful and more fun so that they can start contributing, and giving back, to what really matters: “The goal of programming is to act as a bridge to reconnect us, reinventing society and making a true democracy.” * anonymous quote from the net 

Thank You very much! I hoped for a Jerry Seinfeld and Morgan Freeman combo... But, if that didn’t happen, you can reach out and I’ll answer any questions: [email protected] And @dumconstantin on twitter/github/etc