Interface design in the separation architecture of front and back

Source: Internet
Author: User

The separation of front and back is generally referred to in the software development process, front-end code and back-end code development, non-interference, do not use the back-end language to write the front end, nor the front-end technology to write back-end, from the formal, generally do not use JSP or PHP mixed code, but not to say that you can not use JSP or PHP file format. After the front and rear separation, the communication between the front and back ends is usually called through the HTTP interface.
The concept of separation from the front and back ends many people will have misunderstanding: the front and back separation can not use the JSP file: in fact, the separation does not necessarily have to use HTML files, as long as the JSP does not write a large number of back-end code, then JSP is just a file suffix, It's been Javac precompiled, Needs to be compiled in a Web container. Class into an HTML document returned to the browser, the browser is still to get the HTML document, but for the end-to-end separation of the deployment method is not convenient, but not to say. The JSP file is not separated from the front and back, for example we can use JSP to get the project's BASEP Ath, and the front end can know the full path to the interface when it sends an HTTP request. For example, if you send an AJAX request in the project's/app/modules/users/index.html:

$.ajax ("getuserlist?page=1&limit=20",...)

The request address issued in this way is:

Http://serverName:port/projectName/app/modules/users/getUserList&page=1&limit=20

This makes it easy to have a 404 error, because in fact our interface path is:

Http://serverName:port/projectName/getUserList&page=1&limit=20

So what if we use an absolute path.

$.ajax ("/getuserlist?page=1&limit=20",...)

If your project is deployed in the root directory of tomcat (usually root), that's fine, otherwise the actual request becomes:

Http://serverName:port/getUserList&page=1&limit=20

This absolute path is relative to Tomcat, omitting the project name, and if you're not part of the Tomcat root directory, you still get a 404 error, where we need to configure the project name:

$.ajax ("/projectname/getuserlist?page=1&limit=20",...)

This is no problem, but if you have a lot of Ajax requests in your project, take this project name everywhere, and if one day, ProjectName tells you that the project deployment has changed (and sometimes you have to), the hard work of the front-end engineers has come.
For a single page application is OK, you can do a global configuration to save this projectname, so, if there are changes are only a place, but for multiple page applications, it is not possible to define a JS global variable every page, but we can use the ability of Java, Use the methods in the JSP to write this variable dynamically on the page:

<%
    String Path = Request.getcontextpath ();
    String basepath = request.getscheme () + "://" + request.getservername () + ":" + request.getserverport () + path + "/";
%>

<script type= "Text/javascript" >
var basepath= "<%=basePath%>";
</script>

There are, of course, other ways to solve this problem. But doing so I think does not violate the front end detach schema, because at runtime the front-end code and back-end code are still separate. In the JSP does not use Struts's tag library, also did not call the Java method to obtain the data to generate the HTML, the data is still after loading asynchronously takes. the front and rear separation cookie,session is useless.

This misunderstanding may be that the AJAX request is not related to the session, in fact, sessions are managed conversations, as long as the same session of the HTTP request, whether to request a page, or Ajax request an interface, as long as the same source and in the same session, All belong to a session, Ajax request to the back end, still can get the information from the session inside the HttpRequest.
- front and rear separation is the front-end, just the front end, the back end of the end of the matter, non-interference
This sentence is not wrong, but is not absolute, in a project, the team if done before and after the division of labor, it is necessary to cooperate well to do the project, Perhaps for the entire stack of engineers, the front and rear end can be done together, but for the front and back separation of the architecture, the same function requires the front-end engineers and back-end engineers to work together to complete, the advantage of separation is to let people focus on doing what they are good at, so that the front-end experience better back-end architecture more stable, So that the front-end and back-end engineers have more energy to do more testing, so that the front of the heart thinking of the page, the back end of the logic, the database is done storage, no good co-ordination, just want to clear the responsibility, so the points are not as points.
- * Front and rear separation is not possible with template technology
for template technology, there are back-end templates such as Freemarker and front-end template technology such as Jade, regardless of which template is to generate HTML, template is to extract the structure, Let the data to match the template, to achieve the purpose of reuse, the back-end template needs to be compiled, and the front-end template can be directly returned, then is not the use of back-end template technology is not the front and back end of the separation.
This is not the same as using JSP, in fact, using a back-end template is similar to writing some HTML output in a JSP, but it's not the same, because the template technology framework is typically encapsulated so that your data and templates are separate, only to be combined when you need them. Rather than JSP Java and HTML mixed with the way, in general, for the page experience, even if the use of back-end template technology, template files are often front-end engineers or the entire stack of engineers to write, do not understand the front-end technology is impossible to write template files.
But anyway, from the compile and run point of view, the backend template technology is not suitable for the front and rear separation of the architecture, because files such as FTL do not have good IDE support, in addition to the data with the page to compile the assembly and load to the page performance is not high, using AJAX users can quickly see the page, This is more enjoyable than waiting for a blank window. interface design for the front-end detach schema

In the front and back end separation architecture, the front-end and backend are focused on their own technical areas, but to complete the function they have to cooperate well, then the role of the team is very obvious. The front and rear separation architecture is more suitable for large projects, and for small projects with very limited staff, a person all take care of the most convenient, but for many people's team, front and rear separation requirements have more communication, communication costs will obviously rise, to know more communication, contradictions are inevitable, so we play together must set good rules, There is no rule that makes a mess.
In terms of architecture, the front-end to communicate the most is nothing more than the requirements and interfaces, the front end needs to be done in the same way as the prototype and the design, so it often communicates with the product manager and the designer, and the front-end requires a lot of data interface, which requires back-end support, imagine if the team has five front-end five backend, If there is no good interface specification and communication mode, then these five front-end often need to look back to see the interface, such as the addition of a parameter, or a value transmission of the wrong, or the front and back of the inconsistent, or the data format is not negotiable, then the backend engineers have time to write code. And the front-end engineers also spend a lot of breath.
Today we don't talk about front-end communication with UI or requirements, because in most cases the format of the prototype diagram is similar to each company, and each company or even the team's interface document (the interface provided by the backend) may vary widely, there are many no documents, two people consulted, the code also wrote, if one day another newcomer, That's all, he needs to understand the front-end code and back-end code and even the database, combined with the requirements of the document, and a number of people to do a series of communication will be able to understand exactly how to achieve, if the team more people, the situation will be more complex, especially in a project only a backend, there are several front-end cases, there is no good documentation, A bunch of people to find this backend to ask, the situation can be imagined.
The actual work you use the most documents are word, Excel, txt, I think these several formats are very bad, word many people edit inconvenient, and modify up trouble, Excel and txt I think is purely coping, is not suitable to do interface documents.
There are also many companies doing well in this area, such as the development of a solution to the problem of the system, or money to simply buy a, in the new interface or change, directly in the system, we can see.
For those who do not have such a condition, my suggestion is not to agree a good format, to standardize, and to reduce communication costs.
I recommend using the JSON file format, JSON is a good data interchange format backed by both back and forth, it's small, lightweight, easy to handle, easy to understand, easy to modify, and, with time and effort, you can write a small program that converts JSON to any document format you need, For example, convert JSON-formatted interface documents into HTML and publish them to a Web site, and if you want, you can have the program do this automatically, as long as the interface is changed and posted to the Web site immediately.
For example, we can define an interface like this:

{project: ' ERP ', BasePath: ' http://m.co.erp/rest/', [{name: ' Get user list ', url: ' Usr/list ', a Uthor: ' Tang Jianguo ', Https:false, method:[' get ', ' POST ', params:[{pageno: ' page number ', DE Faltval:1, Required:false, type: ' int '},{pageSize: ' per page size ', DEFALTV 
        Al:20, Required:false, type: ' int '}], headers:{' content-type ': ' application/html '}, response:{retcode:{Name: ' Return code ', type: ' int ', Comment:
                ' 1 success, 0 failure '}, rows:{type: ' array ', Comment: ' User list data ',
                    fields:[{accounts: ' Account name ', type: ' String '},{
                    UserName: ' User name ', type: ' String '},{Age: ' Ages ',
          Type: ' String '      },{sex: ' Sex: 1 male, 2 female ' type: ' Boolean '}}} ,
    }]
}

The above is simply written in a format that only makes reference, in addition to the description of this interface, the sample address can be defined, this way is easy to read, input and output is very clear, the team as long as the discussion, the formation of specifications, later with a new interface or changed the old interface, only used in this change on the above can be, And with most of the text tools can be edited, submitted to the Svn,git is also easy, think about, this will reduce the number of communication costs AH.

If you like to see HTML format, no problem ah, write a program, whether Java or JS, can easily turn the contents of the above into an HTML document, no longer need to open a large word to edit.

Maybe you think the way it says is low, your company or project already has a bigger way, also hope that you can share it, if your team in the front and back end of the separation architecture encountered interface design problems, I hope the above ideas to you, solve the problem does not have to directly get a tall, This simple definition, as long as the discussion is good, it is more convenient, and write this document is very time-saving, as long as a JSON interface template to write, then directly copy under the modified several fields, the document came out.
Why do programmers embarrass themselves?

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.