These are chat archives for jdubray/sam

19th
Nov 2017
Paolo Furini
@pfurini
Nov 19 2017 00:14
@foxdonut Hi, I was fiddling around, trying to assemble some POC components, to see if I could start implementing SAM-like architecture in my projects.. I noticed that you say 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 ;)
Victor Noël
@victornoel
Nov 19 2017 09:59
@jdubray if we should move, it should be reddit, not facebook :)
Jean-Jacques Dubray
@jdubray
Nov 19 2017 10:21
@victornoel it's interesting how multi-party conversations are so difficult to get right (bugs aside).
Victor Noël
@victornoel
Nov 19 2017 10:24
for using facebook groups in the same kind of setup than here, I really think it is shit :) reddit is great and works very well, the only thing that would make it a bad candidate is that it is thread oriented and not a chat, but I don't think that's a problem, the opposite actually
@jdubray I think you posted the wrong link about OOP :)
Jean-Jacques Dubray
@jdubray
Nov 19 2017 10:30
Great post on "OOP" The comments are worth a read, people are finally asking the right questions and finding the right answers. I think we can declare OOP dead.
Overall, I am pretty happy with gitter, it strikes the right balance for technical discussions
Victor Noël
@victornoel
Nov 19 2017 10:36
Problem is that if you don't come every day to check what happened, you loose many great discussions. Gitter is nice to get support or ask questions or discuss some points, but it's not as a distributed mean of conversing on many subjects.
Jean-Jacques Dubray
@jdubray
Nov 19 2017 10:40
Yes, I see that (or not, since I come every day).
Victor Noël
@victornoel
Nov 19 2017 10:41
:P
Jean-Jacques Dubray
@jdubray
Nov 19 2017 11:46
I just discovered Apollo, it's so amazing: "With that your <TodoApp/> component is now connected to your GraphQL API. " Awesome!
Jean-Jacques Dubray
@jdubray
Nov 19 2017 11:53
There are quotes you would end up regretting
https://twitter.com/czaplic/status/928359227541798912
Paolo Furini
@pfurini
Nov 19 2017 12:43
Know apollo and other similar graphql stacks, but I don't like graphql idea altogether
Jean-Jacques Dubray
@jdubray
Nov 19 2017 13:26
the idea is "ok", but in practice, this is a long shot. You will most likely face many challenges in terms of consistency or just optimization of the query engine (compared to what you would have written yourself).
The horrific aspect, and Apollo go one step further is that we are now back to a databinding logic when dealing with back-end data. People will never learn.
Jean-Jacques Dubray
@jdubray
Nov 19 2017 14:22

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

React broke the data binding paradigm and the first thing people can think of: data binding is missing, let's add it back again.
Paolo Furini
@pfurini
Nov 19 2017 14:32
Graphql is an attempt to circumvent a bad API, stop
Paolo Furini
@pfurini
Nov 19 2017 14:54
Then I don't really get why I should introduce another API just for querying.. I use HATEOAS for my APIs, take for example JSONAPI specification. I can achieve the same expressiveness of graphql without having to introduce another layer to maintain, and I can control all my business/security rules in one point, instead of dealing with another endpoint, with the increasing risk of leaking sensitive data because I forgot to enforce some accessibility rule
Paolo Furini
@pfurini
Nov 19 2017 15:04
using JSONAPI for read-only views of data-rich backends is all I need, and I have full control without so much burden.. to me the "engine of application state" is not ideal for producing "side-effects" (the CUD part of CRUD), but it's ok for querying, with the added benefit of having a rich metadata to automate reporting tools at the client side
when I say "reporting", I mean that I never use such generic endpoints for specialized views, like a data-entry form, but only for generic search/reporting tools that clients use to easily navigate read-only views of some complex data trees
Victor Noël
@victornoel
Nov 19 2017 15:09
do you think that would equally work for, say, doing some query where you find yourself doing join/filtering on table and/or aggregating some columns of those? (example: generating a plotchart from some data in the backend based on some criteria and aggregations)
jsonapi seems great to query some json-oriented (trees) data, but that's all, no?
Paolo Furini
@pfurini
Nov 19 2017 15:13
jsonapi deals with custom projections, filtering, navigating relations, including related entities or not in one round-trip, and of course sorting and paginating
Victor Noël
@victornoel
Nov 19 2017 15:14
I will look into it then :)
do you have some libs to ease the work to recommend in Java? :)
Paolo Furini
@pfurini
Nov 19 2017 15:14
It doesn't seem to support aggregations if I remember correctly
keep in mind that using HATEOAS for writing goes pretty much against TLA+ approach
but for read-only views it's a good solution IMHO
Victor Noël
@victornoel
Nov 19 2017 15:18
yep, I'm only interest in read only here
I'm not sure I want the framework to handle the whole access to data, I want to do it myself (because it is very domain/performance specific), but I want something to help me define the API
Paolo Furini
@pfurini
Nov 19 2017 15:49
I feel your pain, and I'm in search of a lighter approach myself, to integrate in several stacks that I started to implement recently. For example using only a serialization/deserialization lib like https://github.com/jasminb/jsonapi-converter and https://github.com/kamikat/moshi-jsonapi (they are tagged as "client" libs, but as long as they support POJO to JSONAPI serialization, they could be used on the server too)
Victor Noël
@victornoel
Nov 19 2017 15:52
nice, thanks for the pointers
Jean-Jacques Dubray
@jdubray
Nov 19 2017 16:05

@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

Fred Daoud
@foxdonut
Nov 19 2017 16:06
@pfurini Meiosis 1.x is now free of being a library at all, instead it's just a pattern. This gives you much more flexibility and decouples your code from a library API. http://meiosis.js.org
Jean-Jacques Dubray
@jdubray
Nov 19 2017 16:07
If you have a single system of record (aka a monolith), I have a great API design for you! it's call SQL (no literally executing a SQL statement, but close enough).
but even in that case, the front-end cannot drive consistency. If you have multiple systems of records (aka microservices), driving consistency from the front-end is a fatal mistake, especially at the granularity of views.
SAM's foundational principle is to decouple 100% the API calls from the view. I am really proud of that, and that is the correct approach.
there will always be an unsurmountable mismatch between the units of work to achieve consistency and the granularity of views and view components. There is no magic bullet here. You best bet is to decouple them.
Jean-Jacques Dubray
@jdubray
Nov 19 2017 16:41

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?):

  • action -> link
  • type -> resource
  • state -> state representation
  • relation -> link

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.

When you constrain the system enough (say you are building a CMS) then REST works, but for general business logic, REST simply falls flat on its face. Just like other programming paradigm, you'll end up coding the missing semantics without any precise foundation.
Paolo Furini
@pfurini
Nov 19 2017 16:46
for me a REST interface with HATEOAS (like JSONAPI), can be fine to just navigate a given "snapshot" of the state in a given service
Can be useful for simple reports, management queries, and other similar searches.. the only requirement is that the source of these queries must be in a well-defined state, to ensure consistency across the entire query surface
for example, by periodically making a separate R/O snapshot of a given "representation" of the actual data, much like you do for OLAP
Jean-Jacques Dubray
@jdubray
Nov 19 2017 20:30
I created a yalla.js SAM pattern code sample + some react-like components, this is BAU, all these template literal libraries TLL are pretty much interchangeable.
Paolo Furini
@pfurini
Nov 19 2017 22:53
:+1: very interesting, thanks.. I wanted to try yalla myself, I'll take this as a base for further exploration
Janne Siera
@jannesiera
Nov 19 2017 23:09