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
- Faster development (One place to unit test your logic)
- Faster client code execution (No need ajax since same validation javascript files is being served by nodejs to your client side)
- 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.
作者:Chuck Lu GitHub |
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了
2019-07-16 HearthBuddy Plugin编写遇到的问题
2019-07-16 HearthBuddy的plugin加载
2019-07-16 Unexpected ConvertTo-Json results? Answer: it has a default -Depth of 2
2015-07-16 WCF Host中的BaseAddress 和 Endpoint中的Address的区别
2015-07-16 使用vs自带的wcf配置工具
2015-07-16 Automatic Code Generation-->Implement Interface
2015-07-16 Learning WCF Chapter1 Exposing Multiple Service Endpoints