5 ms·

How does this architecture handle this concern: Say I have a web application, written in JS running in the client browser. It uses the REST API. I also need a

How does this architecture handle this concern: Say I have a web application, written in JS running in the client browser. It uses the REST API. I also need an Android app. Does the Android app use the same REST API? If so, is the business logic re-implement both in the front end web JS code and inside of the Android app? Or is the business logic embedded in the API? If the rest API is pure, it will provide low-level CRUD operations with minimal business logic. The business logic will need to be written in each frontend. Making sure the business logic is correct and in sync across the front ends becomes a challenge. If the business logic is embedded in the API, then many of the API endpoints will be less REST and more RPC style. But then the utility of Django REST framework is diminished. How would you navigate this?

ahoka 3y ago
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.
arcbyte 3y ago
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
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.

ahoka 3y ago

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.

arcbyte 3y ago

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

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.