Graphql does not address the problem he's describing. When he says "transformation" his meaning is similar to transformation in an ETL process. What he means is the application loads data, the user takes an action, and the front end code handles updating the objects locally, then sends messages to the backend telling it what the new data state should be.
This is very dangerous behavior for any application. You don't want the front end to determine how much the shopping cart costs or to just tell the backend they've paid, therefore add the items to the orders list. Even if there isn't blatantly obvious security concerns, you should still never let your front end blindly determine data state changes. All such business logic belongs in the backend as much as possible.
What he's talking about is when business logic is split between the front and backend, which makes everything much harder to test on top of increasing the likelihood of duplicate code or even code which does the same thing but looks different enough to not be caught as duplication (which means changing business logic requires finding all the places it was implemented and changing them all, and if you miss any its unlikely anyone else will realize it until it hits prod).
The UI should always just be a shell that sends requests to a backend which determines which updates to make. There are exceptions like when a user makes form based changes to an object, but the only business logic in that case is "let the user decide what the value should be and persist that choice as is". If any additional changes may need to occur as a result of their change, your backend should make them. Even if you just need to determine if a change shouldn't be allowed because of related data, send a request to your backend requesting the answer and any relevant data necessary for display purposes, not the data necessary to make that determination.
There are exceptions to what I've said, but even in those cases, the backend should still verify whether the front end's result is correct. While the front end was working, a change could have gone through in the backend which invalidates that change. This is why things like concurrency/version tokens can be very important.
In any case, Graphql may have capabilities that look like they help keep business logic in the backend, but it doesn't stop programmers from putting business logic in the front end anyway. No matter how you try to look at it, spreading business logic out across your applications various layers always has unintended consequences for maintainability and even scalability.
> What he means is the application loads data, the user takes an action, and the front end code handles updating the objects locally, then sends messages to the backend telling it what the new data state should be.
But you don't have to do it like this at all. I don't understand what this has to do with GraphQL, you can make the frontend never update local state and only fetch from the server if you want. That's an implementation detail not related to GraphQL, REST, or any other API format.
> No matter how you try to look at it, spreading business logic out across your applications various layers always has unintended consequences for maintainability and even scalability.
I agree with you here, but for:
> In any case, Graphql may have capabilities that look like they help keep business logic in the backend, but it doesn't stop programmers from putting business logic in the front end anyway.
Again an implementation detail, if you're the tech lead, just tell your devs (or architect the app in such a way as to) not to put business logic into the frontend.
I wasn't referring to trusting the client's logic and state changes and then sending it back in an update and storing it. But certainly some devs do that.
As a simple example, you may send an entity to be updated and then the frontend makes a decision to say, you changed this value, then alter this other value so that the update request has the values we want (ie: one property may need to be blanked if another property has a certain value). Your frontend has logic it shouldn't and you should be enforcing your data on the backend anyway.
However, I was referring more to a situation where a frontend dev has an API request that it can work with but needs in another format or structure. And then logic is added to that data based on the user inputs or to simply do client side aggregations. Maybe it takes the user's chosen store location and filters out the out of stock products from the API on the client side.
Instead of sending the inputs to the API and have the API's logic handle it and provide you with the dumb data for your frontend to render - here are the products you should render; don't think about anything. So your frontend isn't growing into this brittle thing that is doing too much and is more likely to end up with dupe code as multiple frontend devs get tasked with new but similar components and recreate the wheel.
> In any case, Graphql may have capabilities that look like they help keep business logic in the backend, but it doesn't stop programmers from putting business logic in the front end anyway.
I'd argue that it in many cases it promotes frontend devs adding more business logic. Because your devs can query for whatever they want on the schema, transform the data, do whatever logic in the components instead of relying on an API contract for said data.
It means there's really no thought into: what does this client actually need?
So the frontend devs don't have to involve a backend dev or team to get most of their tasks done, which may be a great thing for their situation.
But the business logic gets pushed more and more into the frontend and gets bloated and brittle.
This is very dangerous behavior for any application. You don't want the front end to determine how much the shopping cart costs or to just tell the backend they've paid, therefore add the items to the orders list. Even if there isn't blatantly obvious security concerns, you should still never let your front end blindly determine data state changes. All such business logic belongs in the backend as much as possible.
What he's talking about is when business logic is split between the front and backend, which makes everything much harder to test on top of increasing the likelihood of duplicate code or even code which does the same thing but looks different enough to not be caught as duplication (which means changing business logic requires finding all the places it was implemented and changing them all, and if you miss any its unlikely anyone else will realize it until it hits prod).
The UI should always just be a shell that sends requests to a backend which determines which updates to make. There are exceptions like when a user makes form based changes to an object, but the only business logic in that case is "let the user decide what the value should be and persist that choice as is". If any additional changes may need to occur as a result of their change, your backend should make them. Even if you just need to determine if a change shouldn't be allowed because of related data, send a request to your backend requesting the answer and any relevant data necessary for display purposes, not the data necessary to make that determination.
There are exceptions to what I've said, but even in those cases, the backend should still verify whether the front end's result is correct. While the front end was working, a change could have gone through in the backend which invalidates that change. This is why things like concurrency/version tokens can be very important.
In any case, Graphql may have capabilities that look like they help keep business logic in the backend, but it doesn't stop programmers from putting business logic in the front end anyway. No matter how you try to look at it, spreading business logic out across your applications various layers always has unintended consequences for maintainability and even scalability.