TL;DR:Elixir, Phoenix, React, and Redux are mature and productive technologies for building incredibly fast, massively concurrent, reliable, real-time web applications. Nothing else comes close.
In Engineering Terms, Where We Are and Where We Want To Go
HelloSign been able to build a successful business based on a simple set of technologies: PHP, Symfony, and jQuery. To this day, these technologies serve as core parts of our stack and work quite well. We do not see us ever completely removing these parts of our codebase.
Yet we’ve had some issues in terms of maintainability, performance, and productivity, especially with jQuery. Maintaining complicated imperative jQuery code can be something of a nightmare. Plus there were parts of our architecture that were not giving us the performance our customers needed. This led us to a search for some long-term solutions to these tricky problems.
Ultimately, we embraced a few approaches to our problems as we started to scale.
For greenfield projects, we settled on a new tech stack consisting of Elixir, Phoenix, React, and Redux. But the tech stack is really an outcome of a shift in philosophy at HelloSign toward functional programming and immutability, and event driven architectures. This new approach allowed us to build a massively concurrent, fault-tolerant, real-time application at scale.
In October, I gave a talk at API World called “10 Mistakes to Avoid When Building an API,” which was a compilation of mistakes and missteps the HelloSign engineering team made while building our API. It was a hit!
But wait, why would we want to share mistakes?
Our engineering team has embraced the company values of “Transparency” and “Constant Improvement.” We regularly hold post-mortems to brainstorm ways to fix, improve, learn, and grow. This talk was actually a result of many post-mortems that were boiled down to a handy list of not-so-obvious lessons that others might be able to benefit from.
Below are the mistakes and lessons covered in the talk at API World:
I’m a senior part of HelloSign’s API support team, so I see a lot of different API use cases. Each new customer brings a unique set of variables to the table. But despite the differences per customer case, there a few core questions that unfailingly come up. These questions need to be answered before we can get the ball rolling.
We thought it would be helpful to add a top-level overview of some of the core components of our API with some of the basic questions that need to be asked as you plan your integration.
If you’re a developer, you likely spot (and ignore) irksome bits in your code or product regularly. Perhaps it’s an excessively long if-block or a border offset by 1 pixel too many. Maybe you manually run through 5 steps every week to get your test database just right.
We let these annoyances slide because we might not have time to fix them. We also understand that what seems small isn’t always a quick nip-tuck fix.
Last year, the HelloSign engineering team started holding a quarterly Bug Squash to clean up these exact types of issues. Like the name implies, it’s a two-day event to fix small bugs but we also use the time to make workflow enhancements, perform housekeeping, create developer tooling, fix broken windows, and tinker with small projects.
It’s had a positive effect on team morale and satisfaction, and resulted in improved product quality and provided useful improvements to the team and our users.
On every wall of our HelloSign office, there hangs a list of our nine core company values. These include things like extreme ownership, transparency, and making our users awesome.
While every value is important to our team, one we hold in particularly high esteem is “constant improvement.” Over the last 6 months we’ve taken constant improvement to heart as we made our HelloSign API more empathetic to developers and more customizable for the companies who wish to embed the eSignature experience into their app or website.
The result has been a suite of new updates for API users, present and future. Check them out below!