Mark Harrison

We had an existing App, written in (Apple) Swift, that was running fine, and calling an API. We'd done that as the first App, since our website users were clearly heavily dominated by iOS users.

Our use case is student safety, though increasingly we're seeing our platform used by companies for employee safety!

However, the trigger for moving away from Swift was two fold: * we wanted to introduce a real time messaging solution (for fire alerts) * we wanted to launch an Android app

Expo.io gave us the tools to build a single App that could run on both Android and iOS. Our App update on the Apple Store was accepted as a replacement for the Swift one, and the Google Play store was likewise straightforward (due, in no small part, to the clear documentation on the Expo site.)

Our use case comes from schools - so we use the term "pupils" and "staff" in a way that an organisation might use "people" and "managers." Expo appears to give us a clear way forward to an instant notification world in which "staff" (who mainly use our website) will be able to send instant notifications to "pupils" (who mainly use our app.)

The requirement was the classic "cache the results of a SQL query for a period of time."

While the Internet is full of "Redis is fuller featured" posts, the key issue for us was the actual performance. We discovered, in various stress scenario testing, that Memcached outperformed Redis for simple key-value retrieval dramatically (over twice as fast.) That's not to say that Redis is bad - we use that in other places where the requirements are more sophisticated than simple key/value retrieval.

The only place state lives. Some basic database triggers simplify an awful lot of stuff that would be huge amounts of code in an MVC architecture. MySQL

For balancing the presentation tier, and for SSL offloading (which is great for performance.) AWS Elastic Load Balancing (ELB)