Website architecture adopts nobackend solution-PHP Tutorial-php.cn

Website architecture adopts nobackend solution

WBOY

Release： 2016-07-25 08:42:42

Original

869 people have browsed it

　The nobackend solution is adopted for website architecture
The current application development model places too much emphasis on back-end construction. In fact, we have been working on simplifying back-end development for many years. Therefore, Li Chao, founder of Brothers in Arms, proposed a different solution for the current environment that pays more attention to UX. ——noBackend, priorityPHP trainingfront-end development.
　That is to say, web, ios, and android are just presentation layers, and persistence operations are collectively left to the API.
Ignore the template rendering for now, we may put this on the front end.
　The current struggle is the issue of web session and app token.
This API is not only verified through tokens, but also has a user session when a web request is made.
　 When there is a user session, there is no need to verify the token.
　Are there any limitations or disadvantages to this approach?
　Backend php..

　Reply content:
　Of course it is possible, and I have many successful cases, and there should be many cases in the industry, although some are deceptive, and some just seem to be what they are, but they are not.
But having said that, it still depends on whether you have a senior architect. If you really have a lot of money, I wouldn’t mind using .NET to prove the feasibility of this architecture to you. (PHP no love sorry)
　If you are really struggling with the issue of token and session, it is either because you are not capable of handling this structure, or you have not played it and are unsure. I don’t know which one it is. In short, the answer to whether it is feasible is yes. of. I understand that the nobackend you are talking about refers to the traditional architecture that does not want to use technologies such as PHP and JSP. That kind of architecture will put a bunch of user business status in the session and write logic on the server side to update the page or operate the back-end service ( For example, updating the database).
　As far as my personal experience is concerned, you can put page updates and the user's current status on the front end. The back-end API is a set of stateless services. This is actually a very common architecture.
　The more troublesome part (as can be seen from your problem description) is the security aspect.
　For native clients, you can consider the oauth implicit grant type, that is, the token is placed directly on the client, because native APP is considered safer.
　For the web, it is more dangerous to put the token directly on the client, but traditional methods (including oauth authorization code grant type) require placing the token in the session.
　There is actually a way to solve this problem. But you'd better ask yourself first, do you really want to be sessionless? In fact, it is generally difficult to completely remove sessions. As far as the entire system architecture is concerned, you just don't use it in your programming vision. There is nothing wrong with reasonable use, and don't engage in fundamentalism. If only the token is placed in the session, if the server crashes, assuming your application handles it well and the front-end business status can be persisted, it is nothing more than asking the user to log in again and return to the previous page to continue. For example, in an online mall, as long as the user puts things in the shopping cart and the backend crashes, it is nothing more than logging in again. Your shopping record is still there and you can continue the operation. This is just a rough description, the specific details will be determined according to business needs, but you should be able to understand what I mean. You can read this Post: Lift, State, and Scaling, regardless of language. What is conceivable is that you may need to build a lot of wheels yourself, because there are no mature tools for doing many things on the front end, which will ultimately slow down your business www.itxdl.cn. Simply put,
　1. The backend provides rest api and a /verify for login verification, and subsequent operations require verification information
　2. The front-end is made into a webapp through ember/angular, and uses ajax to consume the rest api. In practice, I don’t use cookies, just log in every time, because you are already a webapp
　　3. If you need security, go to https. I personally think that if you can avoid cookies, you can avoid using js api directly. The authorization problem is difficult to solve. The secret cannot be downloaded to the browser, and you can only use implicit authorization, but for most services Neither is supported. . . No backend solution? This has been done before. There are quite a few cases in my memory.
　No backend does not mean there is no backend. Isn’t API implementation also a technology like backend? There should be basically no difficulty in developing it now. The questioner's problem may be that he does not realize the difference between server-side token and web session. In fact, it's okay, the communication with the interface server must be token, and the session on the web side must be generated by the web side after verifying the server access permission first.

Let’s go through the process,
　User login as an example,
　1. User logs in and sends verification information to the api server
　2. The server verifies OK and returns a token indicating that the verification is passed
　 3. Create a login session on the web side to record the token obtained in the current login state
　4. Login complete, jump to the application page
　After the above, the user should look at his coupon information
　1. Take the token and user name and other information saved in the web session when logging in, and call the coupon interface
　2. Return to coupon information
　The server did 2 things in this process
　1. Verify token legitimacy (existence, expiration, source, etc.)
　2. If it is legal, calling the service will return coupon information, otherwise, an error will be reported.
Here, you can see that the session is used by the web-side presentation layer, and the token is the session of the interface server. It will be clear if you clearly distinguish the levels.
Note: On the www.itxdl.cn website, a series of backend solutions are listed to help you start developing using noBackend mode.