Over the past couple of months MyBuilder has be transitioning from primarily a dedicated server-stack (with orchestration through Puppet) to cloud infrastructure by-way of Amazon Web Services.
We have been a proponent of AWS for quite some time, taking advantage of services such as S3 and CloudFront in our current setup.
We are also not unfamiliar with EC2, spreading some of our application requirements onto several instances over the past couple of years.
However, we really have not been taking full advantage of the ‘Cloud nature’ of the product, and still treating each server as something in-between a Snowflake and Phoenix.
When a project becomes sufficiently large in size you will undoubtedly encounter the need to simplify certain tasks, such as managing external dependencies or configuring environment parameters.
Within the MyBuilder code-base we have required these kinds of processes for some time.
Promises are an invaluable abstraction around ‘eventual’ results within asynchronous operations.
I recently had the need to be able to retry a Promise-based action in the event of a failure.
It turned out to be very easy to implement such a process using simple recursive constructs.
We were recently sent a tweet in-regard to a text-area client/server-side length validation not correlating.
After some detective work we were able to find two issues that could have caused this to occur.
In this post I wish to discuss our findings, and how we resolved each issue.
In a recent project we felt it beneficial to introduce the Money pattern.
There are many good resources on this pattern, so I will delegate to those for further definition.
We decided that encapsulating this into a immutable value object allowed for a cleaner API and removed the fear of any unexpected mutation bugs.
However, we noticed a spike in memory and processor usage when wishing to perform many successive actions on such values i.e. summation.