Today’s post is an interview with our VP of Engineering, Brian Pugh. As Lucidchart transitions away from PHP, we thought it might benefit the development community to have one of our in-house experts make the case for Scala as the best solution for web-based applications.
What kind of shop are we running here?
Brian: We are a SaaS business pushing the limit of what can be done in a browser. Lucidchart is a fully functional diagramming application running inside the browser with no Flash, Java or other plugins. It’s just pure Javascript creating an experience in the browser that feels like a native app. That doesn’t just happen. We spend a lot of time thinking about how to write, organize, and package Javascript to ensure it is both maintainable and performs well.
What are some of the challenges you’ve faced?
Brian: Handling explosive growth in product usage is a good problem to have, but a problem nonetheless. We’ve had some growing pains as we have literally seen exponential growth in usage. About a year ago, we could see that our current server architecture had too much overhead and some limitations that would make it difficult to grow by orders of magnitude each year.
For example, the CakePHP framework we were using required loading a lot of session data on every request, was not designed for storing data across shards and doesn’t have great support for parallel processing.
We decided to move from a somewhat monolithic single server-side application to a services approach. We also decided to look across the board to find the programming language and framework that would best meet our needs going forward for these services. We looked closely at frameworks in PHP, Java, and Scala, and finally settled on Scala and the Play! framework.
What did those technologies provide you?
Brian: Scala allows us to use functional programming concepts without abandoning the entire object oriented paradigm. It runs on the JVM so we get all the benefits of the tools that have been written for the JVM as well as the large number of libraries available in Java. Both Java and PHP started to feel like “legacy” languages to us the more we spent time coding in Scala. Java is really verbose in comparison to Scala and the lack of any meaningful approach to lambda expressions is a real hole.
PHP is great for rapidly bringing things up, but the object-oriented features feel like they were tacked on as an afterthought rather than designed into the language from the start. As a code base gets larger and more complex, that starts to hurt. Neither Java nor PHP have meaningful functional programming support to speak of. Having functional concepts in Scala has helped us create well structured code for complicated problems such as generating images of diagrams. It has also been extremely helpful as we do more parallel processing using actors and futures in our services.
Play! gives us a rapid development environment similar to what we’d been used to with our PHP code base, while also giving some guarantees that a statically typed language provides that a certain class of errors do not exist in the code. Scala with Play! feels a lot like some of the dynamic languages and frameworks even though it is a statically typed, compiled language.
What other issues went into your consideration?
Brian: We are hiring a lot of new people. We’ve doubled our team size in the last year and plan on doubling again in the coming year. As a code base gets larger and more complex, I find there begin to be more advantages to a statically typed language. In addition to the guarantees I mentioned before, the type information helps developers quickly come up to speed on code they’ve never seen before.
Also, the refactoring tools are great and allow us to refactor comfortably when we see the need. While there is a pretty steep learning curve to Scala and Play!, the move to these technologies is already paying off. Response times are down for processor intensive code– such as image and PDF generation–by around 75%. Also, the number of outright failures, in which no image would be generated due to errors or timeouts, has been reduced by orders of magnitude.
Any tips for other startups out there?
Brian: I am a big fan of the “release early and often” philosophy. Also, people make the difference. The interview process should be rigorous. We send out a pre-interview programming test to all candidates. Those that do well with that test are invited in to interview with at least four Lucidchart engineers and work through various programming challenges in the office (or over Skype) before we make a final hiring decision.
We also work to create an environment that our top performers would never want to leave. That means creating a strong professional relationship with each employee and providing flexible compensation packages, which include equity options. And it doesn’t hurt to ensure that pizza is never in short supply.
[Note: Interested in Scala? We’re hiring!]
No Comments, Be The First!