I was asked how much Magic scales, and how fast it is, compared to other popular solutions out there – And this question intrigued me to such an extent I had to find the answer for it myself. Since there are a whole range of existing performance measurements out there comparing .Net Core to PHP’s Laravel and Python’s Django, I could get away with simply comparing a Magic solution to a “pure” C# and .Net Core Web API, for then to simply extrapolate my numbers unto existing graphs. Maybe you think that this was “cheating”, but since Magic is all about doing less work, and get more results – I kind of felt it would be in the “Magic spirit” to avoid repeating things you could easily find out through a simple Google search.
My conclusions was that Magic is roughly 33% slower than a pure .Net Core controller endpoint, ignoring the fact that Magic has 10x the number of features as its “pure” .Net Core equivalent. Since a pure .Net Core solution is between 3 and 8 times as fast as its Django and Laravel equivalent, this puts Magic into the league as 2.5 times and 5.5 times as fast as their Python and Laravel equivalents. Read the performance article where I got these numbers here. In the video below you can see how I accomplished these numbers, what code I was executing, and how I did the measurement – Such that you can reproduce it for yourself, in case you doubt me.
Conclusion – Magic is between 2.5x and 5.5x faster than Django and Laravel
As a final note, I want to emphasise that the “pure” .Net Core solution did not support paging, filtering, rich querying, or any of the added features the Magic solution gives you out of the box. Hence, the comparison isn’t really a just comparison without mentioning this simple fact. I could of course have pulled in OData, at which point my pure .Net Core solution would also have ended up with query capabilities. I suspect this would have resulted in that Magic would have significantly outperformed the pure .Net Core solution, probably by several folds – But these are my assumptions, and should be taken with a grain of salt, until proven to be correct or incorrect.
As an additional note, I must also say that even though Magic obviously is really, really fast – Magic’s most important feature is not in speed of execution – It is in speed of development. It took me about 30 minutes to wrap up the code for a really simply .Net Controller HTTP GET endpoint. It took me about 1 second to create a much richer and more flexible HTTP GET endpoint in Magic.
Hence, regardless of how you compare Magic to a manual solution, where code has to be written, it becomes an unfair comparison – Simply because with Magic the whole idea is to completely avoid the creation of code. Something I have illustrated previously in one of my videos where I wrap a Sugar CRM database with 222 table, creating 888 HTTP REST endpoints, by simply clicking a button.
Let me put this into perspectives. It took me 30 minutes to wrap up a simple HTTP GET endpoint in C#. If I was to add filtering for it, paging, and query capabilities – It would probably require me (at least) 3x the amount of time. Extrapolating 1.5 hours of development into 888 HTTP endpoints, becomes 1332 hours of software development. 1332 hours divided by 8 becomes 166.5 days of actual development. 166.5 divided by 5 days (working days per week) becomes 33.3 weeks of development. This translates into 7.9 months of development – Ignoring vacations and such. Hence, one man would have to work for roughly 8 months to produce what I did in one second, by clicking a button, and my computer spent 40 seconds delivering – Assuming we can extrapolate 1.5 hours into 888 HTTP REST endpoints. If we were to take this amount of time literally, and translate it into costs, this results in that creating code yourself becomes for this particular use case 4.795.200 times as expensive. Simply because 1332 hours becomes 4.795.200 seconds, and it took me “1 second of man hours” to create Magic’s 888 HTTP REST endpoints.
Of course the above is arguably “China math”, and there are many additional things to consider in a real solution, skewing the numbers towards one or the other directions. For instance, what about maintenance? But if we are to take the numbers literally, you will need roughly 5 million dollars to achieve the same thing manually coding, as you can achieve with $1 and Magic.
1 dollar with Magic brings you the same as 5 MILLION dollars without Magic
Yet again, take the above numbers with a grain of salt, since there are a lot of other factors you need to consider when choosing how to implement your solution. But the above are interesting numbers, and arguably impossible to prove “wrong”, although yet again I want to emphasise that they are “China math” …
But that Magic saves you costs, resources, and therefor money – Is beyond any doubt for those with eyes to see for themselves. Now we also know that Magic results in faster end products, at least compared to everything that can compare itself towards Magic.