These are chat archives for jdubray/sam
Wow, the cycle.js conference is a "stream"!! Groovy!
With Frameworks, the Front-End/Back-End architecture seems to always be an afterthought. Either you get nothing like React and Cycle.js or you get some form of Data Binding which is worse than nothing.
When you don't need to persist your application state or it is as simple as persisting/fetching posts, you are probably ok. But that's not the kind of application I am working on. I help people architect OmniChannel applications and in that context the Front-End/Back-End articulation is essential. You cannot afford to coule your Front-End to your Back-End.
I have worked as far back as 2009 on this kind of problems and one of my client's biggest program had come to a halt because they could no longer produce the back-end APIs support their Front-End. That was a $1B program that had been very successful business wise, or even technically, one would have been considered to be state-of-the-art architecture, yet by applying the "vertical slice" pattern they had reached a point where everything change in the solution was extremely costly.
The "back-end" is rarely just a Database, if that was the case, life would be easy. There is business logic both application level and enterprise level that need to be factored properly to be reusable and maintainable. Patterns like BFF / Vertical Slice force you to reuse nothing, each time you have a new "screen" you create a new set of APIs. Worse ... sometimes you feel that is not quite right and you start reusing APIs that were built for another screen that's when you are dead. The absolute last thing you want to do is let the View decide which API it needs to call.
Redux had got it nearly right with "actions" and "reducer" but again, Redux actions are anemic (no chance to call an API) and the Reducer is a pure function (no chance to call a CRUD API). React was nearly there, but again, it's not in their DNA to think about this back-end / front-end articulation, then they came with GraphQL/Relay, which again makes sense for them, but GraphQL is again about the View calling an API... really? some days you just want to cry.
I'm making good progress working through my own application of state management and backend integration here. Learnt enough about MVI and SAM and have identified enough of my own reactive stages to put together a nicely abstracted solution. Just continuing to work/debug it by considering all aspects of my feature rich app.
For external APIs I am investigating Horizon and Partial Lenses. Utilizing these APIs is made much more possible by having done good engineering in the first place :smile: