Experience of Web front-end and back-end separation


Because the company has a special project, a program written entirely in PHP (smarty) before, now it will turn to PHP + node. So I carelessly instilled the idea of separating the front and back ends with node into the back-end students.

Because we are currently working on angular projects, we have a deeper experience.

Now let’s talk about the idea of front-end and back-end separation, or draw on http://ued.taobao.org/blog/2014/04/full-stack-development-with-nodejs./

1. The First Generation of Web Programs I Contact

Why am I in contact? In Java. Maybe someone used EJB before. I haven’t, but I heard it’s huge.
The first generation I came into contact with should be JSP + Servlet. At that time, the basic method was to parse JSP into a Servlet, then Tomcat converted the servlet into the corresponding html, and then released it. Pages communicate with pages entirely through servlets, and they don’t touch too much or too deeply.
It was just that there was no separation of ideas when Java code was written in JSP, or even code for data manipulation. The whole code looks bloated.

2. Spring Age

The slightly obvious separation is the arrival of Spring. At that time, there were three layers of architecture. Let’s not mention those caches. Dao + Service + Web, Dao provides the underlying data support, Service writes business logic, Web provides pages. The classic way is to stuff a bunch of data into a request or session, and then write java code in JSP or template language such as jstl. Often back-end students will write a demo page to test (can’t you really write demo? The front-end students can carefully cut some pages – > brush the knowledgeable – > write a CSS – > brush the knowledgeable. After the back-end students have written the service, the front-end students will then cut the page to the back-end. Back-end students fill the pits one by one.

This may just be our graduation project, and there may not be a real front-end Engineer at that time, only PHP / Java Engineer + UI and so on.

3. Rest Age

It is the back end that provides WebService, and the front end that is responsible for data representation. This should be the first generation of front-end and back-end separation. At this point there may be a real separation of the front and back ends. The reason for Rest, I guess, is that a Server has to do this on multiple terminals (Android, Iphone, Web, etc.).

The Soap protocol didn’t seem very visible at this time, at least I didn’t see much.

This method is still very useful, the front and back end of each function. At this time, the back end only needs to provide the purest data service, and generally uses JSON for data exchange. At this time, the front-end will generally use node as the front-end server, of course, you can also not use it. Then the problem comes naturally. Data exchange between front and back ends becomes a key link, including data format, synchronization session, error monitoring and so on.

In fact, this time is still the way the back-end template. It’s just the Smarty template of php, the JSTL expression of java, and now it’s the EST in node and so on. But this separation method plays a key role in subdividing work and improving development efficiency. Whether the performance has been improved remains to be investigated.

By monitoring interface faults, it is easy to detect instability of back-end services. The current API monitoring is very pure, although not perfect, but still found many problems.

4. Front-end MVC Era

At present, we are using Angular. This can completely abandon the node layer template approach, which should be the second generation of separation.

Each has its advantages and disadvantages.