3 ms·

Business logic is never, never, never in any UI. ALWAYS in the API. APIs with business logic have no bearing on RESTful vs RPC. None whatsoever. I don't trust

Business logic is never, never, never in any UI. ALWAYS in the API. APIs with business logic have no bearing on RESTful vs RPC. None whatsoever. I don't trust the article author to understand this based on the choices made.

radicalbyte 3y ago
I like it when people like that work at banks. You can have a lot of fun with "pure REST APIs which provide CRUD operations" on bank accounts. Especially when the important business logic - such as credits and debits - are implemented in the frontend :-)
isoprophlex 3y ago
The whole thing defending that you must absolutely "ETL into NoSQL and do state management into a separate RDBMS" is a red flag for me, too.
Etheryte 3y ago
I think you're missing the point. Business logic isn't only what you commit to a database, it's also how the user interacts with the data. Of course you always validate what the user sent you in the end, but there's a lot to be done on the frontend as well. A good example is validation. You often want to have validation of some sorts and that belongs both in the backend and on the frontend. The backend part ensures your database is always safe and sound while the frontend part is responsible for giving the user early feedback. The question the comment above yours is asking if and how do you keep that in sync between your API, your Android app and and your webapp.
- arcbyte 3y ago
  > A good example is validation. It is a good example to bring up because front end validation is not business logic, it is presentation logic. For some simple use cases that might not be obvious to many people but let's just consider a sign up form accepting an email address and a password. There definitely validations you want to perform in both places - the password needs to be 10 characters and have at least 3 of numbers, uppercase, lowercase, and special characters. Those exact password validations will be the same in both the UI and API. But let's consider the email. The business rule here is that only deliverable emails that are openable by the person signing up should be accepted for new users. You cant validate that on the front end. The best you can do is check for an @ symbol or run a more complicated regex (whales be there) before passing it off to the backend to actually send an email, encode signup details into a special link, and do all the work necessary to satisfy the business rule. Its trivial to further drive that point home that UI validations are not business logic even when the same validation appears as part of business logic. You do some minimal checks to save the user time on the UI, but those shouldn't even be looked at as validations. They should be thought of as affordable for the user to prevent wasting their time with trivial, predictable errors.
  - Etheryte 3y ago
    This is a very narrow take on what validation is and what it's used for. A better example would be managing resources, what operations you can perform, what resources are assignable to what groups etc, are all validation and if you don't have that structure on the frontend your UI is as usable as picking a date by writing a cron expression. No one is saying you don't need this logic on the backend. What we are saying is you need it on the frontend too, otherwise you don't have a UI to begin with.
- radicalbyte 3y ago
  He's replying to a post which suggests that a REST API should just be CRUD* over a database & implement everything else "in the front-end". The unfortunate truth is that our industry is full of examples where people have done exactly this. With predictably bad results.

radicalbyte 3y ago

I like it when people like that work at banks. You can have a lot of fun with "pure REST APIs which provide CRUD operations" on bank accounts. Especially when the important business logic - such as credits and debits - are implemented in the frontend :-)

isoprophlex 3y ago

The whole thing defending that you must absolutely "ETL into NoSQL and do state management into a separate RDBMS" is a red flag for me, too.

Etheryte 3y ago

I think you're missing the point. Business logic isn't only what you commit to a database, it's also how the user interacts with the data. Of course you always validate what the user sent you in the end, but there's a lot to be done on the frontend as well. A good example is validation. You often want to have validation of some sorts and that belongs both in the backend and on the frontend. The backend part ensures your database is always safe and sound while the frontend part is responsible for giving the user early feedback. The question the comment above yours is asking if and how do you keep that in sync between your API, your Android app and and your webapp.

arcbyte 3y ago
> A good example is validation. It is a good example to bring up because front end validation is not business logic, it is presentation logic. For some simple use cases that might not be obvious to many people but let's just consider a sign up form accepting an email address and a password. There definitely validations you want to perform in both places - the password needs to be 10 characters and have at least 3 of numbers, uppercase, lowercase, and special characters. Those exact password validations will be the same in both the UI and API. But let's consider the email. The business rule here is that only deliverable emails that are openable by the person signing up should be accepted for new users. You cant validate that on the front end. The best you can do is check for an @ symbol or run a more complicated regex (whales be there) before passing it off to the backend to actually send an email, encode signup details into a special link, and do all the work necessary to satisfy the business rule. Its trivial to further drive that point home that UI validations are not business logic even when the same validation appears as part of business logic. You do some minimal checks to save the user time on the UI, but those shouldn't even be looked at as validations. They should be thought of as affordable for the user to prevent wasting their time with trivial, predictable errors.
- Etheryte 3y ago
  This is a very narrow take on what validation is and what it's used for. A better example would be managing resources, what operations you can perform, what resources are assignable to what groups etc, are all validation and if you don't have that structure on the frontend your UI is as usable as picking a date by writing a cron expression. No one is saying you don't need this logic on the backend. What we are saying is you need it on the frontend too, otherwise you don't have a UI to begin with.
radicalbyte 3y ago
He's replying to a post which suggests that a REST API should just be CRUD* over a database & implement everything else "in the front-end". The unfortunate truth is that our industry is full of examples where people have done exactly this. With predictably bad results.