My 2 cents on Web Back-End Frameworks

Today a colleague of mine was asking about other’s ideas about dropping WordPress as their main framework for development. As someone who worked with CodeIgniter for a while and in a high-traffic website, I had ideas to share which I would like to share with you as well:

 

I think dropping WordPress is a good idea. It has a lot of unnecessary footprints.

Indeed CodeIgniter is a fast and lightweight framework, among all the other available ones. I used to work with it for quite a while, and I was happy with it till it was hit with lots of traffic, then it started to show that even a lightweight framework has a huge impact on performance. We took the components that were heavily loaded out of the CodeIgniter and with a few tricks performance was improved enormously.

Developing based on frameworks is fast and easy at the early phases of development, but later in the project when you want to do something which the framework is not intended for, you will find your hands tied.

You have to either extend the core, or hack it. Both, means you have to understand underlying layers of the framework, and that is time consuming.

I believe the best way is to implement your own core architecture. This way you master the core and you can tailor it to your exact needs.

Then you can use libraries/components/frameworks around it for specific features. (e.g. Django’s admin features are amazing and super-fast to setup, but you could only benefit the Admin section from Django and not the whole architecture).

YOU should be the Master of your application’s framework and not vice versa.

I heard once this beautiful saying about frameworks from “Stefan Priebsch” (@spriebsch); imagine “Ruby on Rails”, it’s on “Rails” so it’s very fast, but when “The Rail” twists, you have to twist too, you have no other choice!

That was my 2cents on back-end architecture. Here is a good article, worth reading.

MySQL Asynchronous vs. Semi-Synchronous Replication

When it comes to choose your MySQL replication setup you have the choice between Asynchronous replication or Semi-Synchronous replication. At the time of writing there is no fully-synchronous solution for MySQL replications.

The way these two differ is interesting and would be very useful when you are choosing your architecture.

In MySQL Manual for semi-synchronous replication it is said very well :

  • With asynchronous replication, the master writes events to its binary log and slaves request them when they are ready. There is no guarantee that any event will ever reach any slave.

  • With fully synchronous replication, when a master commits a transaction, all slaves also will have committed the transaction before the master returns to the session that performed the transaction. The drawback of this is that there might be a lot of delay to complete a transaction.

  • Semisynchronous replication falls between asynchronous and fully synchronous replication. The master waits after commit only until at least one slave has received and logged the events. It does not wait for all slaves to acknowledge receipt, and it requires only receipt, not that the events have been fully executed and committed on the slave side.

So as you can see the ideal situation in terms of data consistency and no data-loss would be the fully-synchronous solution. Which on the other hand may result in a lot of delay in the performance of the system and will make the responses slower, as you are dealing with (at least) two nested levels of transactions. (Although fully-synchronous is not available)

On a Asynchronous solution, Master writes the events in the binary log and it may happen that no Slave would pick it up after Master has crashed or any other reason.

Semi-Synchronous seems to be good and practical solution for many cases where High Availability and No Data-loss is important, but you should consider that semi-synchronous “does not provide strong guarantees against data loss“. [article]

You may ask why ? It is as simple as this, imagine Master has sent out the event and one slave has received it, then Master will commit. But on the other hand the slave could have possibly crashed or timed-out or an error happens. In this way you have received the commit on the client, while in reality data has not been committed on the Slave. [article]

Just wanted to point out the differences and ask you to be careful when you are choosing you solution for replication. Semi-Synchronous Does NOT guarantee no data-loss.