A pragmatic look at functional programming: The Quick Seat project (Part 3-3)

TWS Avatar

Alfredo, Games Solutions Architect

As seen in the previous two articles, after some research and brainstorming we were convinced that functional programming could help us develop powerful software with fewer lines of code, maximising reusability and greatly reducing the risk of bugs. This would translate to savings in development and maintenance costs, a reduced number of incidents and a performance boost, allowing us to reduce our services blueprint.

So, we decided to upgrade the tech stack of our Poker product and build our next deliverable, the Quick Seat feature, with a new set of micro services written in Scala. They would extract the list of Poker tables from a legacy component and offer a new API for players to automatically sit at the most convenient table, calculated by a pretty sophisticated algorithm based on player skills, table occupation and wait times among other things. We choose Scala because it was quite easy to adopt. It runs on the JVM, so all our Java pipelines would work. No infrastructure changes were needed: pom files would simply need to declare the use of the Scala compiler. We’d still deploy, run and monitor our JVMs the exact same way.

And then the project was officially launched. We put together a squad of five developers and started with a bit of Scala self-training; turns out a couple of online courses were enough to get us started (Functional Programming Principles in Scala by Martin Odersky was particularly useful). Then we got to coding.

Four sprints later we were ready to deploy our first feature, based entirely on Scala code except for 10 C++ lines we needed to add to one of the legacy components. We produced two new microservices, a connector to the legacy architecture and an API layer.

 

The first load test showed amazing results: the load we previously sustained with 16 of the old nodes running at 70% CPU, we could now handle with the new 8 nodes running at less than 10% CPU. Non-blocking futures and promises in conjunction with pure functions and streams translate to very fast and efficient processing!

We then released Quick Seat to production, took a deep breath and flipped the feature flag switch. Two days later we had our first incident: the 10 new lines in the legacy code had introduced a memory leak which caused the component to crash. Everything else was absolutely fine — we fixed the memory leak and haven’t had a problem ever since.

What have we learnt from our experience with functional programming?

  • FP does provide great business value. Power, performance, safety. It speeds up development while reducing costs.
  • FP is less about different programming languages and more about different programming principles. You need to stay pure, stay immutable, stay side effect free, stay non-blocking, stay abstract. Think more, code less. Evolve as a developer. There is a learning curve, but it is far from steep. And it pays off handsomely!
  • There were some questions around resourcing. Was it going to be difficult to find functional programmers? Maybe more expensive? But we turned this around nicely: instead of looking for Scala developers, we offered the opportunity to OOP developers to get started with FP in our team. This had a positive impact and attracted great talent. Only overhead was the required initial training, but with some of us already proficient after our first deliveries, it got easier and easier.
  • Three years have passed and we are still fully invested in FP in the Poker product. We truly believe it will dominate the market in the near future. More and more companies are adopting functional programming with excellent results, and traditional OOP languages are shifting towards a more functional approach.

Are you considering taking the step? Here’s some useful advice:

  • Start by getting a good understanding of functional programming principles.
  • When possible, make the most of the FP capabilities of the OOP language of your choice.
  • Then choose a small, non-critical project and build it using a pure FP language.

Chances are, you will not want to go back. Happy FP’ing!


About the author
Alfredo is our Games Solutions Architect. With more than twenty years of experience in software development, he has worked in a variety of sectors such as localization, data mining and video streaming. He is now passionate about online gaming development and a strong advocate for functional programming.

Share this article

Next Articles

Finding Inspiration in Interface Design
March 09, 2020

Finding Inspiration in Interface Design

Inspiration is an elusive beast. The more you chase her, the faster she runs.
Your candidate journey at The Workshop
February 25, 2020

Your candidate journey at The Workshop

This blog post should help our candidates understand what it takes to apply to The Workshop, to go through the typical process, and how to prepare for it best.
A pragmatic look at functional programming: abstraction, parallelism and testing (Part 2-3)
February 14, 2020

A pragmatic look at functional programming: abstraction, parallelism and testing (Part 2-3)

Beyond object-oriented programming: unleashing the power of functional programming with a much higher level of abstraction.