How we designed our new tech stack at Dictionary.com

Yair Kukielka
Dictionary Engineering
4 min readAug 20, 2018

As an engineer, when I read about a successful company, the first thing I think about is what technologies they are using and why. After using the same technology for some years, the engineering team at Dictionary.com decided to take a leap into the future and try a new stack that would allow us to keep up with new trends and to move faster.

In this post, we wanted to share an overview of how we transitioned our tech stack as well as our work dynamic, migration to the cloud, CI/CD pipeline and the impact these changes have had on our business.

Side note: If you are considering applying for one of our tech positions at Dictionary.com, you will find this post useful as we answer the questions our interviewees always ask first:

What languages do you use? Which frameworks? What does your infrastructure look like?

The past

Until recently, our architecture consisted of a PHP monolith with Apache and a MySQL database. Tech debt was accumulating and most of the new developers didn’t feel they owned the code. Updates were painful: any small change would require a complete and manual deployment. The entire development workflow for our team was inefficient to say the least. We decided to freeze development on this platform and start from scratch in order for us to re-architect the whole system.

Image by Andy Lin

The present

We are proud to say that we just migrated our main properties (Dictionary.com and Thesaurus.com) to a modern tech stack based on a Node.js/React microservices pattern. In this section we are going to talk about our cloud architecture, our process, CI and testing strategies.

We started the migration by focusing on updating our services on the backend first, and on the frontend second. For the databases, we revamped the data ingestion workflow to allow us to switch from MySQL to sharded MongoDB clusters hosted on the cloud with MongoAtlas.

We re-wrote from scratch our backend API’s, into modular Node.js microservices using Express/Fastify. For the frontend we also leverage Node.js and a combination of Webpack and React. Emotion-js is used for styling our React components. Our web apps are server rendered using beautiful ES6 javascript!

Living in the cloud
Part of our tech migration consisted of moving everything we could to the cloud. After moving one microservice at a time, we now have pretty much all of our infrastructure on AWS — which has been a boon. Using AWS Elastic Beanstalk we have greatly reduced the number of machines needed to run our staging and production environments. Beanstalk includes straightforward load balancing and autoscaling. With the right dashboards set up in AWS CloudWatch our applications have become much easier to monitor and triage. We also use AWS CloudFormation to programmatically spin up, configure, and deploy our infrastructure with templates to deterministically and consistently recreate any environment.

Agile process and testing
We are doing one week rolling sprints in Scrum, using BDD. Engineers collaborate with product owners to write Jira tickets in Gherkin language. Our frontend tests run mainly on Cucumber, using Enzyme for testing React components and Selenium (with Webdriver.IO) for end-to-end tests. Mocha and Chai are used in both the frontend and backend apps.

Our secret ingredient: CI/CD pipeline
We started building a continuous integration pipeline on Gitlab before the migration and it really streamlined the re-shaping of our architecture. Refining it was the cornerstone of our velocity. There’s no silver bullet for CI/CD pipelines and it takes some effort, but it pays off. This is roughly how our process works:

  1. When new code is committed to a feature branch and pushed to Gitlab, all tests run.
  2. The feature branch owner creates a merge request.
  3. After two reviewers have approved the merge request it’s merged to master
  4. Tests will run again. When they pass, the docker container will be uploaded to the AWS Elastic Container Service and deployed to the staging environment.
  5. If everything looks good at this point it will be deployed to production, just by clicking a button on the AWS ElasticBeanstalk console.

CDN and Public Infrastructure Topology
Akamai as a platform is a big part of our infrastructure as well. We leverage their various services for our CDN as well as orchestrating our various properties, content, and DNS to provide one seamless end user experience. A big workflow booster has been our transition to utilizing Akamai Property Manager, which is a spiffy new GUI control center that allows to move more quickly with less white glove assistance.

Our new tech stack has given our engineering team and entire organization a big win. We move much faster and we are more confident about making changes. For example, we recently switched our sites over to HTTPS to get that green check mark in your browser to ensure that end users have a secure visit to our applications.

The future

Web industry best practices evolve quickly, and we are now ready to keep up with them and provide the best experience to our users. We are very excited about our next steps, and we will let you know about them in future posts!

--

--