These are chat archives for jdubray/sam
PLEASE NOTE that Meiosis has changed starting with version 1.0.0. May I ask you which "breaking changes" you introduced in your pattern from 1.0 ? Have you diverged from SAM approach in some way? Thx ;)
No sure if this is still true, but this is what the GraphQL team wrote in 2015 to explain why they were building GraphQL:
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
@pfurini there is no "bad" API, this is like wagging the dog, you can't drive system of record consistency (both on write and also on read)
Graphql is an attempt to circumvent a bad API, stop
the problem with REST from a "STAR" perspective is that it reifies relations and actions behind a single concept (why is it that Computer Scientists can't think with more than 3 concepts?):
So if you pick one, a "link" is an action which IMHO is the most logical, then you have a programming model with no way to express relations, then you start fighting that battle across your entire business logic.
From a pure programming model's perspective, the State Representation should be meaningless to its consumers, just "props" that were provided to them as a reflection of the last known system state. A consumer should be in the position to trigger any action it believes it is entitle to do at a given time. If you notice in "SAM-SAFE" the decision whether an action is allowed or not is taken as part of the SAM instance container, not higher. Only the container "knows" what is the last set of allowed actions.