"Turn" no-end (nobackend): Front-end priority web Development "translation"

Each app is made up of two things: the app's unique features and the features that all apps share, such as user registration, login, forgotten passwords, and so on. From the user's point of view, those unique functions boil down to the user interface and the behavior patterns of the system. And after the visual appearance of the function, the user does not care, they only expect the system to run as expected.

The front-end and back-end have their own focus, and therefore often require different skills, which are done by different developers. The development principle of the No-end (nobackend) can further solve these different emphases, so that developers on both sides can focus more on the work they are really passionate about.

A simple example

The backend often needs to provide the API to the front end, here is a simple example of using the API for user login.

12	POST /session{ "email":"[email protected]", "password": "secret" }

The front-end developer is responsible for sending the above request and responding to the results, taking into account extreme situations such as loss of connectivity or unpredictable server errors. In contrast, the design principles of the back end suggest that the API is defined by the front-end developer, using the front-end code to describe the backend functionality, for example:

123	signIn( ‘[email protected]‘, ‘secret‘ ).then( showDashboard ).fail( showError )

We call this a Dream code (DREAMCODE), because the code is often written before the actual code can be run. In the beginning, this does not make much sense, but instead of sending an AJAX request and invoking the corresponding callback function, but the API defined in this way is more powerful in many ways:

1. Flexible

If users want to log in, they are only concerned about the behavior itself, and will never care about it:

• Whether the request is a server that is sent to the application or a central authentication server
• is an HTTP POST request or a put request.
• Whether it was sent via WebSocket.
• Verify that the cookie used is using the session ID or a custom header
• Whether the app will send the request again after the previous request

Signin the implementation of this method can be adjusted to reflect changes in the backend, but for the API itself, front-end developers do not need to modify it.

2. Simplicity

From the front-end developer's point of view, the implementation of the Signin method is much simpler, the code can be much less, and from the back-end developer's point of view, although the beginning to devote more effort, but compared with the RESTful API, the previous API is easier to define, document and test.

3. Front-End Drive

Front-end developers can lead the entire design process for building applications. Describing back-end functionality in a Dreadcode way allows developers to focus more on the user experience, avoiding distractions from discussing specific implementation details, and delaying project progress due to waiting for the backend API to be implemented.

A more complicated example.

When you look at a more complex example, the former advantage becomes more pronounced. Suppose you want to send a message with a PDF of the current page attached.

123456789

SendEmail({ Subject:"Hello, world!.", text: "This mail have been sent from the frontend" ,< Span class= "line" > html: "This mail had been sent from the frontend" Span class= "p" >, to: "[email protected] ", attachments: [ Span class= "NX" >convert (document. Body ). to ( "report.pdf" ]}) /span>

It can be quite difficult to get this piece of code to run and keep it from being affected by spam. But at least you can write some quick and dirty implementations right away, and then improve it at 1.1, without having to change the API in the process. The key point here is that front-end developers can think of this as an existing feature, so they can focus on the user experience without having to worry about how complex the backend developers have been to implement this functionality so far.

Some of the existing Nobackend solutions

A nobackend solution should provide a front-end API to handle some common back-end tasks, at least including user authentication, data persistence, and synchronization. Here are some of the options to follow:

• Backendless
• Deployd
• Firebase
• Hoodie
• Kinvey
• Parse
• RemoteStorage
• Sockethub

You can also refer to the following: Unhosted. Most of the above lists are managed services, and for those who want to host their own servers, they can choose to open the Deployd.

Original: http://nobackend.org/2013/05/welcome-to-noBackend.html

"Turn" no-end (nobackend): Front-end priority web Development "translation"