Refusal to use CMS when designing web applications

    For quite some time now, I have been solving the problems of designing web applications, or web resources, in which I design the logic of work based on the subject area to which the web application will belong. This approach has never failed me, and often the result of the work has always satisfied me (how much the result of the work can satisfy me - after all, it always seems that you can do a little more better, and the improvement process can be endless). However, sometimes among colleagues I have to meet the opinion that designing using 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 to reveal as widely as possible the approach that I use myself.

    I am not trying to prove with this article that using CMS is not effective. It is effective, but in my opinion only when new functionality is not supposed to be added to a future resource. And when the initial functionality does not go beyond the limits of the "business card site" (although the "business card" can sometimes be quite technological and require the implementation of what CMS with limited capabilities can be difficult to achieve).



    CMS advantages:
    • tested code tested by many developers
    • universality
    • ease of use

    Cons of CMS:
    • 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 the logic is very problematic
    • excessive versatility (without which the CMS itself would be pointless) leads to redundant functionality

    Why do I prefer to work in the subject area:
    • it is possible to more clearly describe the logic of interaction between objects of the subject area
    • it is possible to more flexibly change the logic of the application
    • cleaner code
    • display logic, data management logic, and business logic are separate

    The disadvantages of working with the subject area
    • initially it takes more time to create a project
    • some things need to be written by hand
    • developer qualifications above

    At the first stages, when creating a simple resource, the development speed using CMS will be of course higher. But the more functionality will be expanded, the more time will be needed for its implementation. In addition, at some point, you may need to make changes to the source code of the CMS itself. And this reduces the advantage of “code reliability” to practically zero. After all, in fact, after that all the stages of testing the source product (CMS) must be re-run. And such an opportunity is not always available.

    Web Application Architecture Options Available


    Below I will describe a generalized version of the architecture of web applications with those built using CMS and using a domain-based design approach.

    Generic web application architecture using CMS



    In this case, as you can see, the business logic, display logic, and data access logic are related to the architecture of the CMS itself.
    Thus, in order to change the principle of building a display (forntend), sometimes it is necessary to intervene in the architecture of the CMS itself.
    In addition, the data model will also most likely be based on objects that the CMS operates on, rather than objects that could display the essence of the subject area for which the application is being developed.

    Generic Domain Model-Based Web Application Architecture



    In this case, the connectivity between the various 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 scaffold based system, a windows application, or a web service powered by data from external sources.

    Some limitations and experiences from life


    Of course, all of the above does not mean that the project must be written from scratch completely. The principles of code reuse have not been canceled. And here they are also more than ever by the way.
    For example, during my activity I developed a number of libraries that I use in all my projects.
    Here is a short list of the most requested functionality that I use most often when developing for the web:
    • initialization of page metadata (keywords, description)
    • setting canonical url
    • data initialization for Open Graph (Facebook, Vkontakte)
    • sending email
    • safe receipt of query parameters (parameters from ordinary 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 tied to a foreign architecture.

    conclusions


    Based on various observations, I can say that the total cost of developing a project that is actively developing (that is, new functionality appears often) when using CMS will be higher than a project that is designed based on the subject area.

    All this does not mean that CMS are not needed. They are needed, and in many cases save energy, time and money. But if the project is different from the "home page" - most likely designing taking into account the subject area will be more effective.

    Also popular now: