Updated web application development approach

Question

Many poeple have online startups in their heads that can potentially attract millions, but most of the time you will only have a minimal budget (time and resources) to start with what you want it to be delivered within a year. After a short start, you should perform one or a series of updates, which may include: refactoring the code to a new foundation, adding hierarchy (s) to the software architecture, or restructuring the database. This update / refactoring cycle continues as:

• New features available in the latest version of the language (s) / framework (s) that you use.
• Availability of new components / frameworks / plugins that can potentially improve the product.
• The requirement has changes in its direction, the existing product has not been developed to meet new needs.

Based on the foregoing, I want to seriously discuss this discussion and determine the essence of the updated solution for the web application . In the discussion, you can talk about any development stages (initial, early update, incremental modifications) and cover one of the following:

• Select the language (s) for the web application.
• The decision to use a structure or not? (Consider the overhead)
• DBMS selection and design
• Choosing hardware and settings?
• A strategy for constantly changing requirements (which may be natural for a web application)
• General Redesign Strategy / Decision

Answer 1

Our web solution for our company is in its fourth major generation, which has changed significantly over the past 8 years. The new generation introduced many constructive solutions that helped precisely in this task, since it became inconvenient to update the previous generation based on new customer requirements. Thus, in 2009, I spent a lot of time thinking about this problem.

The most valuable thing you can do is use a flexible approach to creating software. In particular, you must maintain an environment in which a new assembly can (and is created) created daily. While daily builds are just one aspect of Agile, this is the most important practice in resolving your issue. Although this is not the same as the ability to upgrade, by itself, it nonetheless introduces discipline into a process that helps reduce the likelihood that your code base will become bulky (or you will become an Astronaut Architect ).

Regarding frameworks and languages, there are two basic requirements: the structure must be durable and stable and that the environment supports the Separation of Concern . ASP.NET did a good job for me in this regard: it evolved rationally and without breaks, which invalidates the old code. I use a separate layer of business logic to manage SoC, but ASP.NET now supports MVC development. In contrast, I came to dislike PHP after months of working with it because it just seemed to encourage promiscuous methods that threatened future updates.

Regarding the choice of DBMS, any modern RDMS (SQL Server, MySQL, Oracle) will serve you well. Here is the key: you will need to support DDL scripts to manage updates. It is just a fact of life. So how do you do this? The most valuable third-party tool is my copy of SQL Compare from Red Gate. This process was a complete nightmare and considerable resistance to my ability to develop my code until I found this tool. Thus, the general recommendation is to use a database for which there is a tool for comparing database structures. SQL Server is just very lucky in this regard.

The equipment hardly cares. You can always upgrade to new equipment while the development process includes a reasonable assembly process.

Strategy for constantly changing requirements. Again, see Agile. I would advise you not to even think of them as “requirements” - in the traditional sense of a large document filled with specifications. Flexible changes in important ways. I do not comply with the requirements of the document, except when you are working on a contract for an external, paying customer so that I can be sure of the proper billing and prevent creep functions. At this stage, our internal process is so fast and accurate that reports from our query / error management software (FogBugz, if you want to know) serve as our documentation when preparing a new version for marketing.

Strategy / solution for a complete reorganization: no. If you attach a reasonable degree of thought to the process that you will use, select the basic tools and ensure separation of problems, then nothing but a complete rejection of HTTP and RDBMS should cause a general redesign.

If you are Agile enough for something to change, you are unlikely to ever find yourself in a position in which everyone should change.

Answer 2

To make the ball roll, I would think that a language / framework that supports the concept of dependency injection (or Inversion of Control, which seems to be called these days) would be high on the list.

Answer 3

You'll learn that RDBMS technology does not scale easily. All vendors will also tell you that when you try several servers, and load balancing will detect their inherent limitations. Everything else can be enhanced with "big iron" and can be more efficient code, but databases cannot be easily divided and distributed.

Web applications, we hope, will foster innovation in database technology and help us break out of the archaic Relational Model. It is long overdue.

I recommend paying great attention to this weak link from the very beginning.