Scaling Code, Scaling Teams: Part 2

Project Templates, Design Patterns and Moving from Node.js to Java

In Part 1 of this post, we covered the journey of moving languages and how Maven Archetype was the optimal choice for project templates. In Part 2, we discuss specific aspects of development solved by project archetypes and how they can be applied to any tool engineers use.

Patterns vs. Implementation

Irrespective of the type of service or library, project templates define essential design patterns. Developers adopt these patterns in their implementation, resulting in a codebase that is easy to navigate by anyone familiar with the project template.

To start, we had Java Sr. Architects set up project templates using Archetype to define the patterns we would use to build out the business logic. Dependency inversion is a common pattern across the codebase. Such patterns enable RippleNet Engineering to write software that adapts to ever-changing business requirements.

Focus on Writing Code

Using project templates to facilitate the transition from Node.js to Java allowed Node.js developers to focus on meeting business requirements rather than navigating a new language framework, dependency management and build system. Services generated from the project template allowed developers to focus on implementing requirements quickly since the template had enough libraries and utilities to get the job done.

Testing

A core principle in RippleNet Engineering is that every developer owns the testing of the codebase. To maintain release velocity, developers must be confident that the code they push has adequate test coverage. Our project templates have test frameworks that allow developers to write testable code at any layer in the service. We also include multiple commonly-used assertion libraries, so developers have what they need without having to update their project dependencies.

For server-level components, we developed an in-house tool called Topology that programmatically creates versions of RippleNet to allow us to test network topologies. Topology is part of the project template dependency, so every generated project can write integration tests with Topology.

Continuous Integration

With project templates, we do not need to set up continuous integration (CI) pipelines for every new service. Instead, we define the GitLab configurations necessary to run tests and publish builds in the project template. GitLab and Maven plugins allow us to define our versioning strategy for release artifacts. A well-defined versioning strategy is critical to ensure that every developer knows how to create new releases and patch previous releases across all services and libraries.

Non-technical Requirements

Sometimes with rapidly increasing engineering headcount, teams neglect the maintainability of a codebase, which generates technical debt. Project templates can reduce technical debt by allowing engineers to stay motivated and build things rapidly in a sustainable manner.

Naturally, engineers have biases towards using specific frameworks and dependencies—and may introduce these biases on a one-off basis in, say, a patch to fix an issue in a core dependency. One-off core dependencies, however, make it harder to keep them up-to-date. Using a project template instead allows that patch to be applied uniformly across an organization's repositories.

Project templates can also be part of the documentation strategy. For example, a template can include a Swagger definition as the standard for documenting APIs. As a result, anyone in the company can create API documentation with a standard publishing process. Swagger-generated clients can be the de-facto method of consuming services programmatically.

Conclusion

Project templates set up a standard way to introduce new patterns and frameworks to an organization. Having a practice of introducing these tools as a project template allows us first to validate if it works in the current environment sustainably and at scale. At Ripple, we were able to successfully utilize project templates to help us move from Node.js to Java while growing our engineering team. Since then, project templates have been essential to maintaining our RippleNet engineering best practices.

If you’re interested in joining Ripple’s engineering team, we’re hiring!

Photo by Alex wong on Unsplash