I still remember that the first time I tried to separate the front and back ends, it was a spa application built with nginx + react. The back end was java, which mainly processed the business logic and logic parts, returned json data, and configured html + js pure static files in nginx. Then through the reverse proxy to the java backend to solve the cross-domain problem, and then use ajax to interact, the model is very simple and very effective
Mainly solve several problems
1. Independence, because the front and back ends are separated, they can be completely independent of each other during development. The so-called independence actually means that the front and back ends belong to two projects, which are stored in their respective git repositories. The submitted code will neither conflict nor need to be merged.
2. Decoupling. After the back-end development is completed, you only need to submit the code and publish it to the test environment, while the front-end only needs to start an nginx and then reverse proxy to the test environment, and then you can start the development work. It's that simple.
3. Version update. After the project is launched, it is usually necessary to continue iterative update. At this time, the value of separating the front and back ends is presented. For the front-end style and layout update, only the front-end needs to be updated, which has almost no impact on the back-end, so only the front-end needs to be tested. It avoids the mistakes of some developers. When the front-end is updated, the back-end service is unavailable. Because the front-end and back-end are separated and deployed independently, the stability of the back-end is improved, and the variability of the front-end is maintained.
But it also brings some other problems. The main logic is written in js, and it becomes a fat client. When the network speed is not good, the experience is not very good. Another problem is seo. Of course, what I did before was mainly aimed at Wechat side, and does not consider seo, so even this is acceptable, then only the problem of front-end loading performance is left.
Front end I solved it like this
Using webpack + gulp
webpack is used to compile and package js, in fact, it can also be used to compile css, but according to the actual combat, I found that the css compiled by webpack will be a little bigger than that compiled by gulp, and for mobile phones, it is a little less. Yes, so I chose gulp mixed compilation
The amd+cmd module loading method is mixed in the js layer, the common modules will be packaged into common.js, and each page module will independently compile a js file, which will be loaded asynchronously when the page is loaded
I originally chose react-router for front-end routing, but I found it was not easy to use. Later, I chose backbone for routing, and found that it was not cost-effective to introduce backbone just for one route, but the routing part has been written in backbone style , so I wrote a mini version of the front-end routing compatible backbone to achieve seamless switching. The code is only a dozen or 20 lines in total. Based on hash implementation, it perfectly supports asynchronous loading of webpack with loading effect. Before loading for amd The effect has been changed to react-router, and I found it very troublesome, so I don't need it. What I want is lightweight and concise.
The front-end style part uses weui as the basic framework, and some components are still very useful. After encapsulating it, I found that I only used some components. For the icon part, I used Ali's font icon, so I cloned the source code of the weui project. Come down, I only quote the part I use, the size is instantly reduced by more than half, is there any
React is actually controversial, one is its size, the other is its syntax jsx
Let’s talk about the syntax first, I feel that after writing habit, I don’t want to write jquery at all. I used to be a jquery lover, I feel that jquery has nothing to do No, and I also wrote a lot of plug-ins for the project, various jquery, and the front-end of the background is also a framework I wrote with jquery+bootstrap. In fact, when I first saw react, I didn't feel much, because the projects are all based on jquery, and I can't say that I can change it. I just saw the example on the fb official website, and it passed.
Later people always ask me questions about react, in order to answer him I went to the official website to see the documentation, and then tested it locally. After I was OK, I told him that it was actually like this. I was interested in it and decided to try it next time with a new project, so I often went to git to follow its latest developments. I remember that the version at that time was 0.14. At that time, react was just a single file. Now it has been split into react, DOM project module, some people say that jsx is a step backwards, some people say that it is progress, in fact, it is mainly the css part. In this part, I still introduce classes through external styles, and only write rendering logic in jsx. The components are small and beautiful. , without dom operation, all behaviors are predictable, of course, some colleagues never forget jquery, so there are often in react('#id').addClass('cls'), and<script type="math/tex" id="MathJax-Element-5">('#id').addClass('cls') and </script>('#id').data ('id'), $(this).find('input') Various search elements, I have to admire jquery's popularity, no, it should be deep into the bone marrow, it's time to scrape the bone to heal the wound, cough cough
Another is its size. After gzip, there is still 40k. For me, who is a bit obsessive-compulsive, it is indeed a bit large, so I can only try to compress the size of other modules. Fortunately, after adding cdn and cache, except for the first It was a bit bigger at one time, and the others were as smooth as silk. I always wanted to fork a react code, and then make a mini version, but I never had time to study its code. Later, I found that Ctrip seemed to have done something I always wanted to do. The main thing is to simplify react. After using it, I found that most of the pages have no problems. Due to the time problem, there is no in-depth and no switching. Now I don’t know how it is developing.
The ajax module is also one of the component encapsulations. Why didn't jquery or zepto be used, or that sentence I am trying to simplify, of course, the module I encapsulated is also compatible with jquery's ajax, and some interceptors are added in it to process the login status judgment. , timeout handling, exception handling, the way of calling ajax is basically unchanged, the code is not written there by one person, some of it will be better to keep, convenient for others
I haven't posted the code here. Why? In fact, it mainly expresses an idea. Everyone writes the code differently. There are N many ways to implement the same function. What kind of code is written, mainly one Technology precipitation and ideological precipitation
Due to the successful launch of the project and the subsequent iterations, I have more confidence in the separation of front and back ends. The most heard on the Internet is that nodejs is used as the front-end middle layer, but whoever uses it knows.
From this, the foreshadowing of the front-end development based on nginx was laid, and several similar projects were successively made. In a very accidental opportunity, lua was compiled into the tengine module, and in tengine, a few paragraphs of processing were written in lua. Code, I began to yearn for the development of nginx + lua, so I have this development experience based on openresty, and I can share it with you here.
<script type="text/javascript"> $(function () { $('pre.prettyprint code').each(function () { var lines = $(this).text().split('\n').length; var $numbering = $('<ul/>').addClass('pre-numbering').hide(); $(this).addClass('has-numbering').parent().append($numbering); for (i = 1; i <= lines; i++) { $numbering.append($('<li/>').text(i)); }; $numbering.fadeIn(1700); }); }); </script>