Stop leaking and implying logic in your Frontend
Many of the business systems we build are for managing life cycles and workflows. It provides ways to make the state transition from beginning to end. One of the challenges when building systems is that they evolve, and you can start leaking business logic to the frontend or clients where you end up with duplicate logic littered all over the place. Here's a way to solve that issue.
🔗 EventStoreDB
eventsto.re/codeopinion
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to a private Discord Server and any source code in my videos.
🔥 Join via Patreon
/ codeopinion
✔️ Join via KZhead
/ @codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c7a0b3ff38/codeo...
The REST And Then Some
• The REST And Then Some
Want to learn more about software architecture and design? Join thousands of developers getting weekly updates! 🚀mailchi.mp/63c7a0b3ff38/codeopinion
the poor man's HATEOAS
I've been looking for this comment
what do you say makes it a 'poor man's HATEOAS?
@@BradySie-wo6vf because it's way simpler than actually implementing HATEOAS.
This is "simply" using REST correctly
@@codewkarim i thought this was HATEOAS do you guys know of resources to actually implement it
It reminds me of the debate around catching exceptions vs. validating the data first: Instead of checking if an operation failed, and what it's status code is, we provide a way to check if an operation can be made (in this case by returning a list of possible operations in each state change)
Ultimately the validation used when making the request is the same validation used to provide the operation back apart of the initial response.
After working on a system with convoluted business logic for a few years, we found ourselves using the same pattern. The only "real" alternative (and ONLY if you control the clients and the installed versions) is exposing your entire suite of business logic rules to the frontend, which allows introspection by anyone including adversaries and other nefarious users. So it's really not an alternative!
In the real world no one has the time, nor interest, to steal your business logic.
@@7th_CAV_Trooper most likely not, but why put out an invitation?
While this is a possible solution, I would prefer the BFF pattern where a distinct UI controller lives on the server side and translates the business model states to ui model states.
These two things are not mutually exclusive: you can do HATEOAS to explicitly describe the allowed operations to those who consume your public facing API while the BFF orchestrates how those API calls are handled, it's a matter of encapsulation.
Rather than a list I feel an object is better. set power for example could provide a min/max field or even a strongly typed reason on why the action is unavailable. UI can just do {actions.setPower && } (react example) rather than looking through an array too making composition a breeze.
how to use this pattern with CQRS without duplicating business logic? Should I generate possible operations on command side and persist them with my model?
I wonder... is there a library/framework that implements this pattern? Both as a server and as a "client side gode gen" type of deal. I'm aware of general purpose swagger client gens and swagger outputting libs, but due to the wider possibilities, they don't assume state relations like what this pattern entails.
Not really. It's not really hard to implement, but there could be something that would make it easier to start with.
Sounds similar to Scott Washlin concept of 'designing with capabilities' i heard of few years ago. Any of you know any enterprise grade software that does that and it works well?
I'm aware of Scott but not that concept from him, I'll check it out. And yes this absolutely works in enterprise software because most of it is driven by state and the operations that can be performed given the state.
I don't really agree with the argument that this allows you to easily evolve/change the API because clients can still have the old version of the page loaded after you have changed the API. That seems like a difficult problem to solve if you don't want to be strict about breaking changes on the API in traditional sense
Ensuring compatibility, publishing more than one version for a period is a separate issue. This doesn't replace that, but the clients will not necessarily need to make updates still.
What if I need to post some data with operation? Client still need to know the data structure. If client should know about data structure then it may know about url.
it's not about knowing url, but which operations are available. everything else might help but I agree, that won't be enough for a lot of requests
You can go full blown and pass the data needed for a request. This is exactly what an HTML tag does. However I find that too dynamic and often rely on design time to understand the data required when coding to make the request. But as pointed out, it's about knowing what operations are available. You still need to know how to make them,
@@CodeOpinion thanks, maybe it makes sense then.
How to use hypermedia if a method is a post with complex objects as parameter?
You can go full blown and provide the client with the data required. This is no different than an HTML . However, I find that too dynamic and rather it's a matter of just knowing at design time (coding) what payload body is required for a request so it can be implemented if available.
I've never really thought about this problem, so this was an interesting watch. But I'm also not sure how I feel about attaching operations to a response, because it feels like the API would have to presume to know too much about a client - like what the end user is capable of doing or the screen from which the command was given. What if a specific user doesn't have security clearance for altering the toaster's strength? Is that operation only included in the response after the API has calculated what John Doe has permission to do? Or is that command always available? What if there is a different screen that the front end redirects to that is read-only? Should the operations collection be empty in that case? What if the user only has access to the toaster for the next ten minutes? Should the operations list include a time at which all the buttons are disabled? What if the command was successfully processed but the operations list wasn't able to be calculated? Are all of our controls disabled potentially for no reason? Maybe this doesn't matter from a practical standpoint. There are numerous ways of handling the above scenarios. But the line between an endpoint doing its job and doing too much is too gray for my current understanding.
The server doesn't presume to know anything about the UI. It only knows about the allowed state transitions, which it already knows if you designed your state machine with explicit transition rules.
Plus, not every process seeking to perform state transitions is a UI. These could be down stream services.
IMHO allowed operations are intersect of possible state transitions and authorization
Does this pattern has a name?
Affordances. I'm more giving an basic illustration of hypermedia.