Play Framework (our most popular framework) used by egraphs

So some time back this case study was posted on egraphs use of CloudBees as the platform for their e-graph service (read the link if you want to know more about specifics).

OK fine, for the lazy - egraphs is like a modern way to get a personalized audio message and written note from (say) a sports star - there is quite a bit more to it and they do biometric authentication of stars to ensure things are legit (you can get personal greeings etc).

In any case, egraphs have been using Play for a while. When they first starting using CloudBees, it was Play 1, they jumped on Play2 the day we opened up the platform more so they could run it.

They also seem to have very large variable loads - nicely suited to elastic clouds. I recall messages coming in via support tickets, cheerily worded "hey guys - just a heads up we are doing a bit marketing push and there may be X million new users on Sunday - just thought we should let you know". Of course we acted all cool and nonchalant:

Well, Play2 has been working a charm so far. With anything of this scale there are always challenges and hiccups (deploying a new version smoothly is always a challenge with that many servers involved).

The thinking for egraphs about using Play was familiarity with frameworks like Rails and Django, and the desire to have a framework that had a similar "batteries included" philosophy.

Will Chan from egraphs notes:

Finally I can write in a typesafe and expressive language on a comprehensive web framework in the style of Rails or Django. Play2 is evolving rapidly because many other people feel the same way and are passionate about contributing to the framework, and we have also seen some of our pull requests be accepted fairly quickly. Also, check out how questions on the Play Framework google group often get thoughtful responses within a few hours. For all of these reasons, I am pretty excited about the trajectory of Play2.

It's also MUCH faster to compile than Play1, and we have been able to do a lot of refactoring in our codebase, both during our migration from Play1 to Play2 and after. It's hard to think of many things that are very painful about Play2, but I definitely wish the default Play database evolutions were not required to follow a strict numeric progression, and I could see that being an issue on a bigger team, but at Egraphs we make do since we're still a small engineering team.

Myyk Seok (also from egraphs):

Play2 provides great support for asynchronous computing, though at times it may feel clunky, for many things it provides very clean mechanisms by removing the boilerplate so you can write just the important parts. Also, I like how easily most our code can remain immutable with Play2 in Scala.

I don't know for sure, but I suspect that egraphs use of Play2 is possible one of the biggest deployments of Play2 so far (if not the biggest) - based on scale and number of users.

I think it is gutsy to go and do something new like this and pick something bold and new to implement it in - but sometimes you have to take the risk to beat the averages (not unlike what Paul Graham writes about )

Nice work egraphs !