Turn: Should we build back-end as API

Originally from: Http://www.infoq.com/cn/news/2015/07/api-or-not

Not so long ago, on the Stackexchange website, a user named SLC mentioned that he was designing an ASP. There are some flags about whether to design the backend as an API, and I hope to get some advice. A stone stirred thousands of waves, this post quickly got a lot of attention and reply. Now let's look at the specific situations and problems that SLC faces.

SLC-designed web site is a typical ASP. NET MVC application, which he uses in the development of some classic MVC pattern, that is, the combination of controller, view and model, call a Manager object in the controller's method to get the data and create the view model. There was no problem, but one of his colleagues objected that the code was too strong to be reused if it was to create a desktop version of the app. His best practice is to create a set of APIs on which to build a Web site, desktop app, or mobile app.

SLC has reservations about this view, citing several reasons why he considers this inappropriate:

• The design of the backend as an API is overly abstract, and great flexibility also means a great deal of complexity.
• Some of the built-in features in MVC will become useless, such as the ability to redesign roles and certifications;
• In order to ensure the security of API calls, a token system must be designed, and the corresponding tokens should be attached to each API call;
• Each function in the whole program must write a corresponding API call;
• Tools such as interfaces or abstract classes are not available in the API, and frameworks such as WCF have very limited support for interfaces;
• In a desktop or mobile application, you often avoid fine-grained API calls, so you have to create some batch or coarse-grained methods to support these systems.
• This violates the Yagni principle, unless you have decided to support a variety of applications with the same functionality at the same time, otherwise it will only unnecessarily increase the workload of development;
• debugging becomes very difficult due to the inability to implement end-to-end single-step execution.

supporters

User GBJBAANB strongly supports the way the backend is designed using the API, and he believes that this approach not only allows code to be reused, but also provides higher security and better design. The realization of oneness will result in the rigidity of architecture, which is difficult to expand, replace and improve. He also takes the most popular microservices as an example, in this design the backend is implemented as a number of small services, each providing a set of APIs for the client to invoke. He also points out that SLC has a misconception about the concept of APIs, which is not a remote class library, but rather a service that provides data. The Web site can obtain data through the API and perform certain operations on the data locally.

GBJBAANB also reviewed some of the points cited by SLC:

• MVC itself is a design that follows the concept of isolation services, but the ASP. NET MVC Framework organizes these design elements together. So using the API doesn't mean abandoning the idea of MVC, but it lacks some of the supporting methods in this framework. If you rely too much on these helper methods, you are bound to bind yourself to this framework, in which case you can write your own helper methods, or look for some third-party class libraries.
• Debugging is just as easy. First, because the API is a separate layer, it is entirely possible to test the API for isolation, which is not even necessary for debugging purposes. If you do need end-to-end debugging, you can also open multiple visual Studio and attach to multiple processes for debugging.
• This is a good thing to do with extra design to ensure safety. If all the security aspects of the Code are implemented in the Web site, once the hacker breached the Web server, it is equal to gain all access, including the database. And if you set up an additional API layer, then security can be greatly improved.

Gbjbaanb finally made some design suggestions for SLC, from a hierarchical perspective, the site is a presentation layer, and the API is the application layer. The design of business logic can be viewed as either data-centric or domain-centric, although the latter appears more "pure".

opponents

And there's a lot of noise against the API. Fotijr says that while microservices are a hot spot for the moment, it doesn't mean it's always worthwhile. Loose coupling is a good thing, but if it makes the whole development cycle too painful, it's not worth the candle. He also suggested placing the model in a separate data Access project so that MVC or desktop applications could be reused directly. JACQUESB also does not support design as an API, and he argues that simply creating an API does not guarantee loose coupling, and if poorly designed, there is tight coupling across server boundaries.

a little humble opinion

Next, I will simply express my personal opinion on this issue. The first is the understanding of the API, where the original author seems to simply interpret the API as a distributed API for a standalone process, such as a Web API, remoting, or RPC call. In the broad sense, as long as the code calls through the background of business logic and data, can be understood as an API. So the question is not how to design the API, but how to design it.

Next look at the design of the original author, he used the method is to call the method of a Manager object within the Controller method to access the data, then presumably can be inferred that his business logic is a data-centric design idea, the pattern used is likely to be a transaction script (Transaction Script). The advantage of this approach is simple to understand, but the design of the model is likely to be a model of anaemia, that is, the business logic is scattered in the application layer corresponding to the use of the method, over time, its difficult to maintain the shortcomings will be gradually exposed.

The better way is to follow the design principle of separation of concerns, isolate the business logic from the application logic of the corresponding use case, and place the business logic in a highly cohesive domain layer, while the presentation layer (i.e., Web site, desktop, or mobile application) invokes the corresponding business logic indirectly through the application layer. From this perspective, the APIs required by SLC are the methods and objects exposed by the application layer (such as data transfer objects), and he himself has expressed his understanding of this in a later reply. As to whether to design the API of the application layer as distributed, this is not the main problem.

I do not agree with the fact that the reuse of APIs enables the same set of logic to be applied to different presentation layers. Admittedly, in a layered architecture (or other similar architecture), it is theoretically possible to reuse the same application logic. However, in practical applications, due to the different characteristics of the client, the application logic is often adjusted to achieve the most optimized user experience. The composite UI style used in the site may be designed as a task Based UI on the mobile side, and the difference between UX and use case will directly lead to changes in the Application layer API. If you want to persist in reusing application logic, it is necessary to compromise the UX to some degree, and in making the decision to reuse it, the software organization must have a deep understanding of its impact.

In fact, in my opinion, the greatest advantage of layering is to maintain the design and code cleanliness, conducive to long-term design evolution and code maintenance, and to promote unit testing, while the different layers can be parallel development, testing and deployment. I believe this is also the intention of SLC colleagues.

Turn: Should we build back-end as API