So iFlexStudio is approaching alpha-demo stage, but in the meantime I'm trying to sort in my head exactly why I've spent the last few years playing with this technology. So, in the spirit of a picture is worth a thousand words, I've tried to diagram the concept.
So, first of all I accept of course that the HTTP model can be far more advanced than the diagram lets on, however I am going to say that mechanisms for achieving more with the traditional method are beyond the capabilities of most hosting providers and the diagram as shown probably represents 99%+ of individual hosting installations.

Problems with the traditional model
  • Lack of scalability and prone to DDOS attacks
  • No protection against software of hardware failure
  • Potential for database and / or CPU overload

These issues are all addresses pretty much immediately with the new model. Yes, I know it looks more complicated, but the idea of iFlexStudio is that it does all of that for you, so you get everything shown on the model without leaving your IDE.

What else is in the box?

Difficult to know where to start on this one, there are so many things I would consider massive I'm not sure which should take first place, so I guess in no particular order of importance;

  • You no longer need a LAMP stack, no more webserver
  • You no longer have HTTP, so all those evil HTTP expoits out on the web .. gone
  • No more AJAX calls, so all those SQL injection attacks .. gone
  • The message router can typically handle 10x the number of concurrent requests that you would expect from Apache, and you can add as many Microservices as you wish (well, ,000's) so you immediately have a huge capacity advantage. When you consider that message routers can be clustered, then you pretty much have unlimited scalability out of the box. In reality, database limitations are probably going to dictate the edge of the envelope.
  • The scheduler can load-balance workload between microservices, so custom load balancers, haproxy and others, they're all out of the picture too.
  • Low-latency, everything is websockets so data transfer is a fraction of the equivalent HTTP
Async vs Sync

What's the difference and why is it a big deal? Well, Synchronous is the traditional model for making a request.

  • Consumer (A) asks provider (B) for something
  • Consumer (A) blocks
  • Provider (B) goes and does some work, then comes up with some data
  • Consumer (A) wakes up and accepts the date from Provider (B)

Whereas Asynchronous requests are a little different;

  • Consumer (A) asks provider (B) for something supplying a callback routine
  • Consumer (A) carries on about it's business
  • Provider (B) goes and does some work, then comes up with some data
  • Provider (B) sends the data back to (A) and triggers the callback routine
  • Consumer (A) executes the callback routine with the data as a parameter

Now you're going to say, "yes, but http requests are executed by the browser in parallel, and AJAX requests can be run without blocking the main Javascript thread - so we're already Asynchronous", to a degree you'd have a point,but that's the browser being Asynchronous rather than the server.


If I make 40,000 concurrent connections to an Apache server with a PHP-FPM back-end, typically it's going to get pretty upset for a number of reasons. Most Apache servers will have trouble hitting 20k concurrent connections just in terms of sockets, let alone the ability to service 20k waiting clients. This is due to the Synchronous nature of HTTP requests, while the request is in flight the server will hold a session open leaving an AJAX call sitting in the browser waiting for a response.

Imagine if you will a fully Asynchronous call. The browser will connect to the message router and maintain a persistent connection, and it will subscribe to a return channel. As and when, the browser will then call a routine provided by a MicroService by sending a message to the message router, with the required parameters. At this point the browser does not block and there is no AJAX call sat in the browser waiting for a response, the browser is immediately back into the event loop.

The message router will then (if possible) send the request to an appropriate MicroService for servicing, or, if resources are tight, it may queue the request until resources become free. When the microservice has serviced the request and returned the response to the message router, the data is then sent back to the browser to wake up the appropriate callback.

So with request queuing and load-balancing over multiple microservices, again the potential capacity is far greater and there is almost unlimited horizontal scaling available via the addition of more microservices and clustered message routers.

Bonus points

Ok, so there are lots of technical reasons why the Asynchronous mechanism is going beat the Synchronous option, but there are some hidden features that I didn't realise before accidentally seeing them in action.

I often hear people extolling the virtues of consistency and ACID database transactions, particularly in SQL vs NoSQL discussions, but what I don't typically see is the same discussion about what users actually see with regards to consistency.

Take a favourite niggle of mine, the out of stock conundrum.

  • Customer # 1 pulls up product (A)
  • Customer # 2 pulls up product (A)
  • Both customers see that there is only one item left in stock
  • Customer # 2 has to take a phone call
  • Customer # 1 orders product (A)
  • Customer # 2 returns to his screen, sees what he wants with available stock
  • Customer # 2 attempts to place an order
  • Depending on the implementation, at some stage the order will fail because the item was actually out of stock when Customer # 2 clicked on order. The point being that the screen was out-of-sync with the database, which resulted in the Customer seeing incorrect or at the very least, out of date information.

Before the "yes but ...", the customer was looking at out of date information, in my mind that should never happen, but it is the default state of play with regards to Synchronous HTTP based systems. You can specifically code around this, and mitigate the issue by polling for changes on a regular basis, but that's not standard.

This would be the equivalent Asynchronous implementation;

  • Customer # 1 pulls up product (A) and subscribes to channel "productA"
  • Customer # 2 pulls up product (A) and subscribes to channel "productA"
  • Both customers see that there is only one item left in stock
  • Customer # 2 has to take a phone call
  • Customer # 1 orders product (A), when the order is accepted, the server broadcasts a new stock level of zero on channel "productA"
  • Customer # 1's screen reduces the stock level to zero
  • Customer # 2's screen reduces the stock level to zero
  • Customer # 2 returns to his screen, to find the stock level is now zero and is free to immediately dial back the person they just spoke to and berate them for causing this injustice.

We expect this sort of functionality from Facebook and Twitter, but to have this sort of functionality as the default in all websites and online applications, this is a bit new. Just to try to drive the point home;
In this example, the user placing the order would have two active subscriptions, one for the product on the screen, and one for the user they are logged in as. When the order is placed, anyone logged in as the given user would see the order confirmation and stock level update, anyone else would see just the stock level update. So the secondary bonus here is that you can easily synchronise the displays of people logged in on the same account, which has massive potential when it comes to support, training and collaboration.

For a practical example, if you log into iFlexStudio on two different browsers (two different tabs or from two machines, makes no difference) and open up a terminal session on one account, you will see the same open on to the other browser. Every keystroke you see in one terminal session will be mirrored on the other. If one terminal session is closed, the other will close too. If you create a new file on one screen, as soon as you finish typing the file name, you will see the file tree on the other screen open up and the name of the file will appear.

Not only is it potentially very useful, it's also very cool .. :)

What about WAMP?

So I need to be a little bit careful here, I upset some poor chap during the summer when I made a claim that WAMP based applications were between 5x and 10x faster than HTTP based applications, and he accused me of claiming to be able to break the laws of physics ..

First thing to say is that everything in this area is subjective and prone to benchmarking, but that aside I'm quite happy to stand by my claim. To elaborate, when you make a HTTP request, typically there's over 500 bytes just in header information, then another couple of hundred bytes coming back. A WAMP websocket transaction on the other hand just sends data, there is no overhead above and beyond the basic TCP/IP packet, which could be as little as 60 bytes.

So, if you allow me to equate speed to the amount of data that needs to be processed and transmitted over a wire, then it doesn't seem unreasonable to argue a potential ten fold performance increase for WAMP based applications.

... Ok, this was going to be a short entry, time to go shoot something.

(Dear GCHQ screen scraper, something on the XBox, not literally something...)