Refusing to use CMS when designing web applications
Already for a long time solving the problems of designing web applications, or web resources, I use the approach in which I design the logic of work based on the subject area to which the web application will belong. This approach never let me down, and often the result of the work has always satisfied me (in general, the result of the work can satisfy - in fact, it always seems that you can do a little bit better, and the improvement process can be infinite). However, sometimes among colleagues I have to meet the opinion that designing with the use of a CMS is much more efficient. After the last such conversation, I decided to write an article and share my thoughts with the Habra community.
I tried to describe both design approaches and as widely as possible to reveal the approach that I use myself.
This article is not trying to prove that using CMS is not effective. It is effective, but in my opinion only when a new functionality is not supposed to be added to a future resource. And when the original functionality does not go beyond the “business card site” (although the “business card” can sometimes be quite technological and require to implement what with the limited capabilities CMS is quite laborious).
')
Pros CMS:
Cons CMS:
Why I prefer to work in the subject area:
Disadvantages of working with the subject area
At the first stages when creating a simple resource, the development speed using the CMS will of course be higher. But the more the functionality will be increased, the more time it will need to implement it. In addition, at some point it may be necessary to make changes to the source code of the CMS itself. And this practically reduces to zero the advantage of “code reliability”. After all, in fact, after this, all the stages of testing the source product (CMS) must be redone. And this possibility is not always available.
Below, I will describe a generalized version of the web application architecture built using a CMS and using a domain-based design approach.
In this case, as you can see, the business logic, the display logic and the data access logic are connected with the architecture of the CMS itself.
Thus, in order to change the mapping principle (forntend), it is sometimes necessary to intervene in the architecture of the CMS itself.
In addition, the data model is also likely to be based on the objects that the CMS operates on, and not on the objects that could display the essence of the subject area for which the application is being developed.
In this case, connectivity between different parts of the application is much lower. In addition, various modules can be replaced without the need to make changes to all parts of the application.
For example, the frontend can be a web application, while the backend will be a scaffolding-based system, windows application, or a web service powered by external data.
Of course, all of the above does not mean that the project needs to be written from scratch completely. Nobody canceled code reuse principles. And here they are, too, more than ever.
For example, during my work I have developed a number of libraries that I use in all my projects.
Here is a brief list of the most requested functionality that I use most often when developing for the web:
Thus, when designing a new application, I can rely on the inherited functionality, but at the same time I am not attached to an alien architecture.
On the basis of various observations, I can say that the total cost of developing a project that is actively developing (that is, new functionality appears frequently) when using CMS will be higher than that of a project that is designed on the basis of the subject area.
All this does not mean that CMS is not needed. They are needed, and in many cases save time, money and effort. But if the project is different from the "home page" - most likely the design taking into account the subject area will be more effective.
I tried to describe both design approaches and as widely as possible to reveal the approach that I use myself.
This article is not trying to prove that using CMS is not effective. It is effective, but in my opinion only when a new functionality is not supposed to be added to a future resource. And when the original functionality does not go beyond the “business card site” (although the “business card” can sometimes be quite technological and require to implement what with the limited capabilities CMS is quite laborious).
')
Pros CMS:
- tested code tested by many developers
- versatility
- ease of use
Cons CMS:
- the subject area is limited to those objects that are provided in the CMS
- The main logic of the application is determined by the developers of CMS. Making changes to logic is very problematic.
- excessive versatility (without which the CMS itself would be meaningless) leads to redundant functionality
Why I prefer to work in the subject area:
- there is an opportunity to more purely describe the logic of interaction of object domains
- it is possible to change the application operation logic more flexibly
- cleaner code
- display logic, data management logic, and business logic are separate
Disadvantages of working with the subject area
- initially need more time to create a project
- some things need to be written by hand
- developer qualification requirements above
At the first stages when creating a simple resource, the development speed using the CMS will of course be higher. But the more the functionality will be increased, the more time it will need to implement it. In addition, at some point it may be necessary to make changes to the source code of the CMS itself. And this practically reduces to zero the advantage of “code reliability”. After all, in fact, after this, all the stages of testing the source product (CMS) must be redone. And this possibility is not always available.
Possible options for the architecture of a web application
Below, I will describe a generalized version of the web application architecture built using a CMS and using a domain-based design approach.
Generalized web application architecture using CMS
In this case, as you can see, the business logic, the display logic and the data access logic are connected with the architecture of the CMS itself.
Thus, in order to change the mapping principle (forntend), it is sometimes necessary to intervene in the architecture of the CMS itself.
In addition, the data model is also likely to be based on the objects that the CMS operates on, and not on the objects that could display the essence of the subject area for which the application is being developed.
Generic domain-based web application architecture
In this case, connectivity between different parts of the application is much lower. In addition, various modules can be replaced without the need to make changes to all parts of the application.
For example, the frontend can be a web application, while the backend will be a scaffolding-based system, windows application, or a web service powered by external data.
Some limitations and life experiences
Of course, all of the above does not mean that the project needs to be written from scratch completely. Nobody canceled code reuse principles. And here they are, too, more than ever.
For example, during my work I have developed a number of libraries that I use in all my projects.
Here is a brief list of the most requested functionality that I use most often when developing for the web:
- initialization of page metadata (keywords, description)
- installation canonical url
- data initialization for Open Graph (Facebook, Vkontakte)
- sending email
- secure retrieval of request parameters (parameters from normal url, or url using routing are obtained uniformly, with the type already given)
- Exception Handling
- interface generation (for example, Dynamic Data - used exclusively for resource administration)
Thus, when designing a new application, I can rely on the inherited functionality, but at the same time I am not attached to an alien architecture.
findings
On the basis of various observations, I can say that the total cost of developing a project that is actively developing (that is, new functionality appears frequently) when using CMS will be higher than that of a project that is designed on the basis of the subject area.
All this does not mean that CMS is not needed. They are needed, and in many cases save time, money and effort. But if the project is different from the "home page" - most likely the design taking into account the subject area will be more effective.
Source: https://habr.com/ru/post/138435/
All Articles