Nobackend is used in website architecture

Nobackend is used in website architecture

Nobackend is used in website architecture The current application development model places too much emphasis on backend construction. In fact, we have already done many years of work to simplify backend development. Therefore, Li Chao, founder of brother-in-law, focuses more on the UX environment, propose a different solution-noBackend, with priorityPHP TrainingFront-end development. That is to say, web, ios, and android are only display layers, and persistent operations are all thrown to the api. We may put this part on the front end without considering the template rendering. Currently, it is the question of web sessions and app tokens. This set of APIs does not only pass token verification, but when the web request is a user session. When a user session is contained, the token does not need to be verified. Does this practice have any limitations or shortcomings? Backend php .. Reply content: Of course it is feasible, and I still have a lot of success cases, and there should be a lot of cases in the industry. although some are simple, some just seem to be the same thing, but they are not actually. However, if you have any senior architects and have a lot of money, I don't mind using. NET to prove the feasibility of this architecture. (PHP no love sorry) If you are really entangled in the token and session problems, either because you are not able to handle this architecture, or because you have never played it, I don't know which one is, in short, the answer is yes. I understand that nobackend refers to a traditional architecture that does not want to adopt technologies such as PHP and JSP. it will put a bunch of user services in the session, write the logic on the server to update the page or operate the backend service (for example, update the database ). In my personal experience, you can completely put page updates and the current user status on the front end. the backend API is a set of stateless services, which is actually a very common architecture. It is troublesome (as can be seen from your problem description. Native client, you can consider the oauth implicit grant type, that is, the token is directly placed on the client, because the native APP is considered safer. For the web, it is dangerous to directly store tokens on the client, but the traditional method (including oauth authorization code grant type) requires token in the session. This problem can also be solved. But you 'd better first ask yourself, do you really want to achieve no session? In fact, sessions are hard to be completely removed. in terms of the entire system architecture, you just don't need them in your programming field. Reasonable use is not necessary. do not engage in original principles. If only the token is put in the session, and the server crashes, if your application is well processed and the frontend service status can be persistent, it is nothing more than asking the user to log on again and return to the previous page to continue. For example, in an online store, users only need to put things in the shopping cart, and the background will collapse, that is, re-login. your shopping record is still there and you can continue to operate. This is just a rough description. the specific details should be determined based on the business needs, but I should be able to understand it. You can read this Post: Lift, State, and Scaling, regardless of language. You may need to build a lot of wheels on your own, because many transactions do not have mature tools at the front-end, but it slows down your startup www.itxdl.cn. To put it simply, 1. the backend provides the rest api, and provides a/verify for login verification. the verification information is required for subsequent operations. 2. the front-end uses ember/angular to make a webapp and uses ajax to consume the rest api. In reality, I don't need cookies. every time I log on, it will be because you are already a webapp. 3. if you need security, use https. I personally think that cookies can be free from direct use of js APIs, which is difficult to solve. secret cannot be downloaded to a browser and can only be implicitly authorized, but most services are not supported... No backend solution? This is already in use. There are many cases in memory. If there is no backend, there is no backend. API implementation is not a backend technology. Now, there should be almost no difficulties. The problem with the subject may be that the difference between the server token and the web session is not realized. In fact, the communication with the interface server must be a token, and the web session must first verify that the server access permission is generated by the web. Let's take a look at the process, For example, 1. log on and send verification information to the api server. 2. the server authentication is OK. A token is returned, indicating that the verification is successful. 3. create a logon session on the web client to record the token obtained by the current logon status. 4. log on to the application page. After reading the above, you need to check ta's coupon information. 1. call the coupon interface with the token, user name, and other information saved in the web session at login. 2. return coupon information The server has done two things in this process. 1. verify the token validity (existence, expiration, source, etc) 2. Valid. the coupon information is returned when the service is called. Otherwise, an error is returned. Here, you can see that the session is used by the web-side performance layer, and the token is the session of the Interface Server. the layer is clear. Note: a series of backend solutions are listed on www.itxdl.cn, which can help you start to develop the noBackend mode.