Which side is more logical: front-end or back-end?

Which side is more logical: front-end or back-end?

When you program, you write
1. Business logic
2. View Logic

Business Logic: It deals with the security of your application (Authentication and Authorisation) and the actual data. This is the backend of your app. Business logic should never appear in your front end because your front ends can be multiple(viz. Android, HTML, iOS), and if you write your business logic on front end, you will have to replicate it on all front ends. This is a severe code smell.

View Logic: It deals with GUI elements. For a good, elegant and intuitive GUI, you need to write a good view logic at your front end. This is important as well because customers directly see and interact with the front end of your app.

So going back to your question, both sides are equally logical.

How safe is it to move business logic into the frontend with JavaScript frameworks like Angular and React?

I’m not sure the parameters of the question are completely clear; in other words, what do you see as being the “business logic”?

From one perspective, the answer is “completely unsafe.” At the end of the day, the application itself is there for all to see and understand. Obfuscation via “minification” or “uglification” is a deterrent遏制的, but determined malicious parties WILL read your code and understand what it is doing. So, if your “business logic” has proprietary专用的 algorithms, you have exposed them. No amount of encrypting and protecting the data interchange can prevent this absolute fact.

However, if what you mean by “business logic” is simply calculations and non-proprietary mutations突变 of data, there is no real issue with letting JavaScript handle it. Whereas we formerly gathered input via forms and submitted it to the back end to run calculations, we might trust our JavaScript application to handle this side of things before submitting. The back end needs to sanity-check (for things like type and range), but maybe it doesn’t need to run the actual calculations anymore (again, as long as they’re not secret). The same security checks (injection protection, for example) that we have always needed still need to be there on the back end, but that’s neither here nor there.

To summarize: “business logic” can mean different things. If the code itself is what needs protecting, you CANNOT trust JavaScript.


Perhaps more importantly, though: I believe you are misunderstanding what adopting a framework like Angular or React is doing for you. Those frameworks are NOT typically grabbing up “business logic”. For the most part, they are simply responsible for presenting a view. The back end is almost always still responsible for the heavy lifting, particularly when databases (or database-like information storage and retrieval) become involved. The front end might shift the data models around to varying degrees, but ultimately the data is still sent to the back end.

These frameworks ideally make it easy to present the back end’s data to the front-end user, over a mostly-universal UI tool in the form of a web browser.

 

 

How to avoid repeating business logic between client and server?

You can do one more thing.

Create your validation and business logic code with JavaScript only. But make it as loosely coupled very much. If possible only take JSON as input and JSON as output.

Then setup a nodejs server just beside the PHP server to serv those logic to clientside. So that in client side it can be used without AJAX call.

Then from server-side (PHP) when you need to validate and run all those business logic call cURL to nodejs to validate those data. That means it is a http call from PHP server to nodejs server. Nodejs server will have another code which will take those data and validate with the same code and return the result.

By this way you can make

  1. Faster development (One place to unit test your logic)
  2. Faster client code execution (No need ajax since same validation javascript files is being served by nodejs to your client side)
  3. All business logic will go to nodejs server. (When business logic changes you need to touch only this part, so that in near future if you need to create some other interfaces also then you can use this server to validate your data. It will work just like your Business Rule Server)

Only things you need to do is setup a nodejs beside PHP server. But you do not need to change all of your code to nodejs server.

When to implement logic in the front-end vs the back-end?

In other words: Any security-related things, verification and validation logic belongs to the server, all authentication and authorization stuff, … and: when you need to make sure that there is one reliable instance to decide some things, e.g. on prices, discounts, and so on.

There is a saying in web programming, and that is: All input is evil.

So whatever comes from your frontend (which basically is your JavaScript application) should be handled with care. Always black- or whitelist input, encode it, transform it, check it, and so on … and the only place where you can do this reliably, as it's the only place that is under YOUR control is the server.

Moreover: Never put secrets into the client, such as credentials (for your database, e.g.).

Hope this helps.

 

原文地址:https://www.cnblogs.com/chucklu/p/13320980.html