The logic has to run server side either way.. but that's obvious. Otherwise any idiot with an API key has full control over your system. That's why you don't "make a pure REST API which provides low-level CRUD operations" as you've suggested. If you have invariants which must be held then you can't do that - and with any meaningful system you will have such invariants.

Frontend? You can implement it in a shared library and cross compile. Or implement it in a DSL and interpret (or compile) that for each target platform.

Is that overkill? Then implement the bits (it's almost always a subset) you need in the frontend.

Don't like that but your app can assume an internet connection? Then keep a connection open (i.e. Signal R) and call procedures on the server.

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.

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

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.

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.

> 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.

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.

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.

The proposed “architecture” doesn’t address this, because it’s a nothingburger. What about authn/authz, etc? The only good piece of advice here is to separate your management and customer data.