Adel F - Architecture of complex web applications

Software Engineering Is Art Of Compromise wiki.c2.com

I have seen many projects evolve from a simple MVC structure.Many developers explain the MVC pattern like this: View is a blade file, Model is an Eloquent entity, and one Controller to rule them all!Well, not one, but every additional logic usually implemented in a controller.Controllers become very large containers of very different logic (image uploading, 3rd party APIs calling, working with Eloquent models, etc.).Some logic are moved to base controllers just to reduce the copy-pasting.The same problems exist both in average projects and in big ones with 10+ millions unique visitors per day.

The MVC pattern was introduced in the 1970-s for the Graphical User Interface.Simple CRUD web applications are just an interface between user and database, so the reinvented MVC for web pattern became very popular.Although, web applications can easily become more than just an interface for a database.What does the MVC pattern tell us about working with binary files(images, music, videos), 3rd party APIs, cache?What are we to do if entities have non-CRUD behavior?The answer is simple: Model is not just an Active Record (Eloquent) entity; it contains all logic that work with an applications data.More than 90 percent of a usual modern complex web application code is Model in terms of MVC.Symfony framework creator Fabien Potencier once said: I dont like MVC because thats not how the web works. Symfony2 is an HTTP framework; it is a Request/Response framework.The same I can say about Laravel.

Frameworks like Laravel contain a lot of Rapid Application Development features, which help to build applications very fast by allowing developers to cut corners.They are very useful in the interface for database phase, but later might become a source of pain.I did a lot of refactorings just to remove them from the projects.All these auto-magical things and convenient validations, like quickly check that this email is unique in this table are great, but the developer should fully understand how they work and when better to implement it another way.

On the other hand, advice from cool developers like your code should be 100% covered by unit tests, dont use static methods, and depend only upon abstractions can become cargo cults for some projects.I saw an interface IUser with 50+ properties and class User: IUser with all these properties copy-pasted(it was a C# project).I saw a huge amount of abstractions just to reach a needed percentage of unit test coverage.These pieces of advice are good, but only for some cases and they must be interpreted correctly.Each best practice contains an explanation of what problem it solves and which conditions the destination project should apply.Developers have to understand them before using them in their projects.

All projects are different.Some of them are suitable for some best practices.Others will be okay without them.Someone very clever said: Software development is always a trade-off between short term and long term productivity.If I need some functionality already implemented in the project in another place, I can just copy-paste it.It will be very productive in the short term, but very quickly it will start to create problems.Almost every decision about refactoring or using a pattern has the same dilemma.Sometimes, it is a good decision to not use some pattern that makes the code better, because the positive effect for the project will not be worth the amount of time needed to implement it.Balancing between patterns, techniques and technologies and choosing the most suitable combination of them for the current project is one the most important skills of a software developer/architect.

In this book, I talk about common problems appearing in projects and how developers usually solve them.The reasons and conditions for using these solutions are a very important part of the book.I dont want to create a new cargo cult :)

I have to warn you:

• This book is not for beginners.To understand the problems I will talk about, the developer should at least have participated in one project.
• This book is not a tutorial. Most of the patterns will be observed superficially, just to inform the reader about them and how and when they can help.The links to useful books and articles will be at the end of the book.
• The example code will never be ideal.I can call some code correct and still find a lot of problems in it, as shown in the next chapter.

In this chapter, Ill try to show how projects, written according to documentation, usually grow up. How developers of real projects try to fight with complexity.Lets start with a simple example.

It was very easy to write. Then, new requirements appear. Add avatar uploading in create and update forms. Also, an email should be sent after registration.