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

Alfredo, Games Solutions Architect

March 12, 2020

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

Contact Us

If you have any questions, just fill in the form and we’ll get back to you.

Controller: The Workshop Technologies Ltd. Purpose: To provide the services offered through the website or to handle other types of relationships that may arise with The Workshop Technologies Ltd as a result of the requests, procedures, or formalities performed by the user through the website. Legal basis: Consent of the data subject as provided in Regulation (EU) 2016/679 and the LOPDGDD 3/2018. Recipients: Internal automated file of The Workshop Technologies Ltd and third parties for the development, maintenance, and control of the legal relationship established when there is legal authorization by the user to do so. Rights: Access, rectification, transfer, opposition, and deletion. Additional information: You can obtain all the additional and detailed information you need about the processing and protection of your personal data at the link Privacy Policy.

We Come From

Like what you see?

Join your comrades or add a new flag!

Thanks!

Your message was sent. We will get back to you shortly.