Sometimes, you have to look back to move forward

As we start the new year, we’ve been looking back at what we learned in 2018, and how we want to change our technical approaches in 2019. Working in an agency environment, with diverse projects and clients, gives us a lot of opportunities to learn new technologies and continually broaden our skillset. 

With so many opportunities, it’s important to take time to step back and reflect on what we’ve learned so far, what we still need to learn, and where we want to focus our energies and attention to make the most of 2019.

Learning a new craft

We’ve traditionally been a WordPress-centric studio, and over time we’ve gained a lot of familiarity with its many strengths — and its many weaknesses. For some projects, the familiarity of WordPress and the ubiquity of plugins makes it an easy default choice. However, projects which require extensive customisation, or a fast and scalable API, quickly run up against WordPress’ limitations as a publishing platform.

As a result, we spent some time in 2018 exploring alternatives. An ideal solution would need to be easy to use for both developers and the end user — a frictionless admin console for content editing and media management was our first priority. To meet our client’s often complex needs, the platform would need to be highly extensible and customisable, and support a rich ecosystem of plugins and integrations. Performance and security needed to be world-class and provide a foundation we could rely upon for new projects going forward. Finally, as we move increasingly toward decoupled website solutions (which separate the front-end from the back-end CMS for performance and security gains), support for a fast and customisable API was also crucial.

To this end, we’ve settled on adopting Craft CMS for future content-heavy websites, and we’re also considering Contentful for the cases where an admin console is less of a priority (for example, small brochure or promotional sites).

We’re no strangers to Advanced Custom Fields on WordPress — it was created by a 24 alumnus — but there’s no excuse for custom fields not to be built directly into the CMS by 2019, and Craft enables this out of the box. While Craft CMS doesn’t yet have the mindshare that WordPress has accumulated over its lifetime, we’re in good company considering it as a solution — Netflix and the Associated Press both rely on it, as does the Dalai Lama.

While WordPress suits some projects, and Craft CMS will open up further possibilities, Contentful will serve as a base for some more tailored solutions. It offers rich and flexible content models, fast performance, and would be highly suitable for decoupled builds. Spotify and Lyft use Contentful for some of their services, and we’re looking forward to exploring its potential further with some internal exercises.

Never Mind The Buzzwords, Here’s Some Microservices

Of course, there are times when a full-featured CMS either won’t meet the project requirements, or will be massively excessive.

One of our projects in 2018 was to replace an internal tool used by up to a hundred users, which needed to load tens of thousands of records daily and keep all instances in sync while providing a fast and stable user experience. Our solution to this involved several different projects including a Node API, a websocket server and React front-end. No CMS would have suited this project, as it required a highly custom solution tailored to specific business needs and user workflows.

Another small project toward the end of the year involved adding a payment gateway to an existing WordPress site. While we could have added yet another plugin to the site and integrated it into the CMS, the overhead to achieve this simple task seemed unjustified. Instead, we created a Lambda function in AWS which receives a Stripe token from the frontend, handles all of the business logic and integrations, and returns only the information required by the site. While this solution sounds more complex, in practise it makes the workflow much easier to rationalise by keeping specific functions clearly separated. More importantly, by isolating the payment workflow into its own service, we were able to create a solution that can easily scale during times of peak activity — nobody wants to miss out on any customers!

We want to continue more of this thinking in 2019, and recognise where different tools can be used to provide the most value. 2018 added some strong examples to our portfolio, and in 2019 we’re looking to further expand our knowledge, and run more regular hack days and internal workshops to explore the potential of microservices and custom API builds.

Host Stories

Over the years, we’ve grown from providing managed hosting to friends and family, to maintaining platforms for enterprise-level clients and large eCommerce websites. However, many of the decisions made years ago are still influencing our services today, and add complexity to our tech stack and our back office (and we want to keep them happy, since they do our payroll!).

To be fair, this isn’t such a drastic change — we’ve been slowly introducing AWS into our stack over the past eighteen months, and some of our larger clients host much of their own infrastructure on AWS themselves. However, by migrating more of our sites from managed and shared hosting solutions to AWS, we’re able to take advantage of more automation, consolidate our billing details, and introduce more complex integrations to our offerings.

Another driving factor behind this change has been our movement away from WordPress and toward a more diversified, product-oriented back-end stack; our current managed hosting providers simply can’t offer the technical solutions we need for future product work.

However, this change isn’t without some trade-offs. While managed hosting providers, well, manage everything, self-hosting your own systems — even on a platform with as much automation, diagnostics and failover support as AWS — leads to extra work in maintenance and security. Additionally, AWS systems have their own specialised tools which require developer experience to use to their full potential. As a result, one of our star back-end developers, Michael, is currently undergoing a training course to become AWS-certified and we look forward to seeing how his expertise can help shape the future of our hosting solutions.

Frameworks make the dream work

When our lead front-end developer Ian started back in 2017, the first thing he noticed was the variety of frameworks still in use compared to previous places he’d worked. With such a wide variety of frameworks across projects, it’s hard to maintain work efficiently due to a lack of knowledge and inconsistency in code and structure.

As much as we all want to stay up-to-date with the latest technologies and tools on offer, this approach just isn’t feasible with the current state of web development. In order to deliver high quality work and be a high performance team, we need to make fitting choices in which frameworks we want to use, that fit the clients we want to serve moving forward.

When considering which framework we wanted to use in 2019, we had to consider a few different factors.