At Boxed, from the beginning, our engineers built our core web services using the practices and principals of Service-Oriented Architecture. This upfront investment and foresight helped form the foundation powering our core technology today. Our API architecture is built using domain-driven design for model partitioning, and hexagonal architecture for layered separation of concerns. Lately, we decided to hop on the hype train and join the GraphQL movement. We’re making a huge investment in and we’re super excited about it, so we’d like to share where we are today.

We’ve been able to leverage the abstractions provided by GraphQL to reduce…

Welcome to the new Boxed Engineering Blog! Here we’ll post stories about some of the cool stuff we’re building, design patterns or practices we’ve stumbled across along the way, and the technical feats, failures, and perspectives we’ve gained over time.

Boxed was founded in 2013 by an experienced group of tech pioneers with a simple idea — make shopping for bulk easy, convenient, and fun. Today, Boxed is a late-stage startup delivering a first-class e-commerce experience for everyday essentials across the country. We value tech and innovation at the heart of all we do. We live and breathe technology, and…

The term “repository” is heavily overloaded within software engineering, in this article, we’ll learn to understand that a repository is an in-memory collection facade, its role as transaction script layer and a generic data access primitive, its role within the domain driven design context, and its general usage within a developer’s toolkit.

All of these facets are heavily related and they’re all just evolutions of the original repository pattern. This pattern predates the Gang of Four, Domain Driven Design, and many of the popular frameworks and strategies that are out there today. …

When building large systems, inevitably you need to integrate with libraries and third party apis. Often enough you find client SDKs which take a lot of the heavy lifting out of the integration work, but they also expose lots of functionality you probably don’t need or ever end up using. Nonetheless the code (and its dependencies!) are still there lying dormant on your servers.

This leads to long running bloated builds, slow cold starts, complex project setups, and broad exposure to security vulnerabilities.

There are some solutions to this this problem for the client-side world such as webpack’s “tree shaking”…

As the back-end development world evolves — particularly the Node.js ecosystem — functional decomposition has become an essential strategy of system scalability and a primary driver of the industry wide shift towards micro-service architectures.

Gone are the days of monolithic Java-like object oriented design systems which make top level domain services difficult to deconstruct. While these strategies work for small, midsize, and even large-scale codebases, they simply don’t mesh well with the micro-service architecture. …

This article assumes that you are already familiar with developing node applications with express and mongo. The aim is to take an existing application and with minimal effort increase testability and provide built in abstractions using inversion of control.

It all starts at the spine of your application; the route definition file. For simplicity and brevity the code written in this article is to illustrate the intent of this article, and does not include proper error handling or best practices.

A basic route file defines endpoints inline and is typical when seeing node back ends particularly in hello world or…

Classes in JavaScript received a ton of flak by the javascript community when they first came out, but for no good reason. They provide syntactical sugar around javascript’s prototypal inheritance features which are one of the most powerful aspects of language. They introduced no new functionality, but made more obscure parts of the language more explicit and approachable for those coming from other languages. I’m referring of course, to this and the new keyword.

function MyFunc () {}
const instance1 = MyFunc();
const instance2 = new MyFunc();
instance1 === instance2 // false

Execution context in javascript is everything, and this…

One of the selling points of Event Sourcing is this idea of the re-playable event stream. There’s plenty of literature around why event sourcing is a good pattern but very little around actual implementation details and the challenges surrounding it’s use. In this article I intend to address the concept of the re-playable event stream.

Events are facts. An immutable append-only log of things that happened in the past. This means that once you hit production you are obligated to handle the events as they were originally published indefinitely. In an event driven architecture, events are published everywhere. All of…