These are chat archives for jdubray/sam

13th
Dec 2016
Jean-Jacques Dubray
@jdubray
Dec 13 2016 06:08
I read this post earlier and tend to disagree with the analysis. My answer is in this post: http://www.ebpml.org/blog15/2016/08/services-apis-and-microservices-part-2/
MVC architectures tend to push for a 6 layer application architecture, if not you'll eventually pay the price in maintenance. By contrast SAM collapses that architecture in 4 layers because two of them are commin between the front-end and the back-end
I have had some separate discussions with a French team which seem to invest heavily in CQRS / GraphQL architectures and that's typically where MVC on the back-end will lead you because you don't want to pay the price of these redundant layers, but unfortunately the semantics of both CQRS and GraphQL will lead in the majority of cases to a dead end.
Jean-Jacques Dubray
@jdubray
Dec 13 2016 06:14
The first trap one should try to avoid would be to think that "inter-action" semantics (such as query and commands) are part of the programming model. They are not, they express important considerations at the wiring level, they are immaterial to the programming model.
As you can see in SAM, there are no distinction at the action level between query and commands. In both cases you enter the system as an action.
Jean-Jacques Dubray
@jdubray
Dec 13 2016 06:20
With respect to GraphQL, this is basically a virtual database engine technology which has been around for 20 years. RedHat bought MetaMatrix a few years back, Composite Software has tried to come up with a similar solution just to realize that they had to put a full fledge integration platform at the back of it (in their case webMethods) just to make it work. Most recently eBay tried to build something like GraphQL (it was called ql.io). The lead engineer was a neighbor at the time, so I know quite well about that project and as I mentioned earlier I was also a co-author of the SDO spec. GraphQL will remain a toy and not provide much solution to the MVC space. People want to use GraphQL in MVC architectures because of the proliferation of API calls. They want to embrace the View-Model coupling (as stated by the GraphQL team) and provide an interpreter to express queries from the view's perspective without having to build dedicated APIs.
SAM is 100% counter to these approaches because it focuses on:
1/ state alignment between the nodes of the distributed system (action->model->state representation)
2/ the decoupling between the view and the model
IMHO, this is where the solution lies and why MVC either on the front-end or the back-end need to be replaced
Interestingly (but not surprisingly), SAM can also be used to manage complex API orchestration (joins, or distributed updates). Having such a versatile pattern that works at all levels of the architecture while minimizing the number of layers and achieving maximum decoupling between each layer via an action/state representation paradigm seem to indicate that SAM brings something really new to the table, but what do I know?
Edward Mulraney
@edmulraney
Dec 13 2016 07:11
how does graphql couple the view to the model?
i see the graphql layer more as a state function, than the model
Jean-Jacques Dubray
@jdubray
Dec 13 2016 10:26
For me the lowest coupling is achieved by the state function, you compute the properties of the view components from the model
GraphQL introduces a stronger coupling because it assumes that one can express a query from the model to populate the view properties

to quote the GraphQL team:

GraphQL is unapologetically driven by the requirements of views and the front-end engineers that write them. […] A GraphQL query, on the other hand, returns exactly what a client asks for and no more.

If the model doesnt' exactly have what the client asks, you are out of luck
Having the view orchestrating the calls to fetch what it needs is simply the wrong architecture. After all the work the React team did to achieve functional HTML and a reactive architecture, here comes the GraphQL team that returns Front-End architecture 30 years back.
Jean-Jacques Dubray
@jdubray
Dec 13 2016 10:31
But I understand that's the kind of argument that can only be settled by side-by-side coding. You code with GraphQL and I code with SAM and we contrast and compare.
All I know for sure is that a GraphQL approach has been tried several times before and it always failed.
There are very logical reasons for that.

This claim from the GraphQL team is simply fallacious:

Structured, Arbitrary Code: Query languages with field-level granularity have typically queried storage engines directly, such as SQL. GraphQL instead imposes a structure onto a server, and exposes fields that are backed by arbitrary code. This allows for both server-side flexibility and a uniform, powerful API across the entire surface area of an application.

Jean-Jacques Dubray
@jdubray
Dec 13 2016 10:37
There is no way in the world that arbitrary code can be homogeneously queried/CRUDed
Have you ever tried to execute complex joins over a set of APIs? have you ever tried to compensate failed updates?

So I would tend to disagree with that assessment:

i see the graphql layer more as a state function, than the model

Jean-Jacques Dubray
@jdubray
Dec 13 2016 10:50
GraphQL is both at the actions and state level but with the assumption that the action can predict the end-state (CRUD it), which is not (generally) true. It might work well for Facebook and a data model that can be CRUDed (such as user profiles, and posts). When you start having complex business objects like in the enterprise, which properties are often spread across multiple systems of record, in a redundant way, then that model fails.
Edward Mulraney
@edmulraney
Dec 13 2016 12:08
i dont think youve understood graphql correctly
the server still has to make sense of the request
theres no magic

If the model doesnt' exactly have what the client asks, you are out of luck

yes? as opposed to what?

we used graphql in a startup i contracted in this year. we used apollo as the bridge for the UI. it certainly didn't send us back 30 years
Jean-Jacques Dubray
@jdubray
Dec 13 2016 16:54
@edmulraney I strongly prefer a model where the view components publish events and listen for new properties, I do believe that pushing (again) for the view to "query" something is setting us back 30 years. Considering nothing has changed in 30 years it might feel just like yesterday, the future is reactive, functional. I may not have use the exact same definition as other people for these two words, but I believe this is where the future lies.
Jean-Jacques Dubray
@jdubray
Dec 13 2016 17:05
Here is a presentation from the RESTafarians trying to save what's left of REST faced with the challenges from the GraphQL guys: https://speakerdeck.com/arnaudlauret/dot-dot-dot-and-graphql-for-all-a-few-things-to-think-about-before-blindly-dumping-rest-for-graphql
GraphQL is replacing one (poorly designed) query language REST by another (only sightly better designed) query language.
Jean-Jacques Dubray
@jdubray
Dec 13 2016 17:12
The problem that REST and GraphQL have tried/are trying to address is that the relationship between (data) model and API is difficult to manage.
First, you need to position the APIs in the architecture, that choice is not trivial nor indifferent. SAM provides a clear articulation, as far away as possible from the view components. Since SAM works also in headless architectures (just node-to-node), SAM basically says that you cannot call an "API" from the client/consumer's perspective. You can only express an intent that will be translated into the API calls.
Jean-Jacques Dubray
@jdubray
Dec 13 2016 17:20
When you truly have a complex relationship between (data) model and API message formats, I suggest solving that problem specifically rather than trying to solve it at the programming model level.
I have a solution for that, I have developed a tool that computes message formats as a projection of a logical data model. Here is a quick introduction to the tool: http://www.ebpml.org/blog15/2015/02/message-formats-and-common-information-model/
Here is the full analysis that explains how data model, message formats and resource orientation are all aligned: http://www.chorusjs.com/wp-content/uploads/2015/02/cim.chorus.pdf
Edward Mulraney
@edmulraney
Dec 13 2016 17:31

I do believe that pushing (again) for the view to "query" something is setting us back 30 years.

What do you mean? The view has to send a query somehow to get the data, whether it's a REST/GraphQL API

Jean-Jacques Dubray
@jdubray
Dec 13 2016 17:32
That's exactly what I challenge. You have think in terms of the nodes of a distributed system and state alignment between these nodes.
State Alignment !== Query
You can never have a node put another node in a given state, you can only align their state.
Edward Mulraney
@edmulraney
Dec 13 2016 17:37
to understand the other node's state i'd need to at least ask it what it's state is?
Jean-Jacques Dubray
@jdubray
Dec 13 2016 17:39
That's the beauty of state alignment, the minimum required is that it is in a compatible state (e.g. if I send a new action, it will generally be allowed, pending that that state of the underlying node has not changed...).
State alignment never requires that large amount of state is shared, only a state representation.
That's the change of perspective that needs to happen
This is already how we implement our systems because there is simply no other way. It is never practical to share large amounts of state, but unfortunately we do it from a CRUD's perspective, not from a state alignment perspective.
It is simply wrong to think that one node can CRUD the state of another. period.
Edward Mulraney
@edmulraney
Dec 13 2016 17:52
so youre saying employ SAM on the server too?
Jean-Jacques Dubray
@jdubray
Dec 13 2016 17:57
Yes, SAM can be used to orchestrate APIs, that's where I started actually. I was looking for a replacement for BPEL.
Edward Mulraney
@edmulraney
Dec 13 2016 17:58
but i still need to request something from this sam server to get the state?
yes, there will always be some inter-actions
but you need to decide with great precision of the nature of your programming model and then choose the inter-action mechanism (aka wiring)
Our monolithic view of the world (Facebook being the ultimate monolithic system, serving 2B users) no longer applies
The systems that we are building are too complex to fit that model
You just can't say that one node in the distributed system has enough knowledge to CRUD the state of another node. That approach needs to change. I hope that stated that way I can convince you.
Edward Mulraney
@edmulraney
Dec 13 2016 18:02
so my http request will send a SAM proposal to the API? the API will make sense of the proposal and either fetch data or mutate data?
what does a request for users look like?
REST: GET /users
Graphql: users { }
SAM: ?
Jean-Jacques Dubray
@jdubray
Dec 13 2016 18:07
That's the key, there is no uniform specification of an action... We have to drop the point of view that objects rule the programming model, they don't.
An action translates an intent into a proposal, both intent and proposal are messages. Yes, there is a relationship between these messages and the underlying resources, but it needs to be expressed as I do it in the CIM plugin (chorus.js), not at the intent/action level.
Edward Mulraney
@edmulraney
Dec 13 2016 18:09
what might it look like just for sample purposes? minimal version like my examples above
Jean-Jacques Dubray
@jdubray
Dec 13 2016 18:09
Then you need to decide how you wire two nodes to convey the intent and receive the state representation. Request/Response is just one way.
It's expressed as a "projection":
projection QueryEntity1[Entity1] { 
             // We alter the multiplicity and remove properties of Entity1
             alter id { min 0 } 
             alter prop1 { min 0 } 
             - prop2 
             - prop3 
             - prop4 
     }
Entity1 would be user and queryEntity1 would either be intent or proposal
Jean-Jacques Dubray
@jdubray
Dec 13 2016 18:24
The problem with both REST and GraphQL is that you can never express the message of an inter-action in terms of data model. It simply does not work. Even SQL doesn't try to do that. A projection is nothing more than a SQL statement in disguise.
Zach Dahl
@schtauffen
Dec 13 2016 18:27
does speakerdeck not have audio to accompany the slides?