Software architecture was never simple. Masters in the field of Desktop Software development would tell you the art of making a robust desktop application had many more moving parts than simply writing good Object Oriented code. There is memory management, CPU and processes/threads management that all have to be kept under close watch if you want an app that works.
Wasn’t it Windows XP’s issues with these factors that killed it and perhaps gave Macintosh an opportunity to make a strong comeback?
Many in the web development industry also don’t realize how important those same principles are to the networked application (or the web application). In fact, they are more important. Much more important!
Good Software Development practices make for a lasting solution.
In a desktop application you usually have three main layers: the hardware computing resources; the Operating System running the whole machine; and the software in question.
In a web application it’s not that simple.
You see, many of the layers we mention in this post: can (and usually do) reside on separate machines. Each of these machines and layers have to be programmed and managed well, for the app to work well.
When your web app – be it a simple WordPress content portal or a complex user-centred social app like FaceBook – starts slowing down or crashing often; any one of the small components in the entire system could be the problem.
For example; you can setup an army of web-servers, managed by a LoadBalancer to make sure enough server resources exist to serve your PHP app; but you do not have enough Database servers so the app begins to slow down in response times because the database is over worked.
In the industry we usually default to standard solutions for each of these problems:
- For SQL database constraint adopt a caching software and/or start sharding.
- For application level resource constraints try adding CDNs and other caching mechanisms.
- SQL not working out? Try moving to NoSQL for certain aspects of your app.
- Move over to an SPA/Restful model
- Compress your app’s code
- Anyone feel like piping? Let’s add queing servers to the mix
- For some reason, other scripting languages sound hotter; why not add Pyhton to some functions of your app?
Most of the above mentioned solutions aren’t wrong in my opinion. I would use half of them in a scalability project as well.
However, what makes me chuckle at night (figuratively speaking) is that most of the apps that end up having to go down this difficult path of adopting these scalability measures; never bother tightening their belt from day one of app development!
The story of most web apps I have come accross is the same. The initial days filled with “Hey I found this library. Let’s add it! Quick!” No attention to basic server resource management in code architecture. DRY is not DRA (don’t repeat anyone).
Then a few years later things start creeking. And the above mentioned measures start being looked at.
And then everybody goes home saying “PHP is a poorly written language.”
When I say everything counts. Everything you type into your code editor as part of the final app also counts!
Make sure you design your web apps well. It will have a big pay off in the years to come.
This is why Web Dotz is working on a PHP based data store that we hope will serve all sorts of enterprises and projects with a robust data store to build beautiful SPA products one day.
By Mustafa Ghayyur
July 5, 2018
