Contact

DELIVERABLES

An example distributed system (client web app and REST API server) using Pact to provide backwards- and forwards-compatibility.

 

TECHNOLOGIES USED

      • Typescript
      • Spring Boot
      • Bamboo

Nowadays, almost every system you interact with is a distributed system. Rather than single machines running all of the code for an app or website, we have web apps, mobile apps, and API servers all interacting over the Internet. Adding new features to these apps often requires API changes, but introduces the risk of breaking older versions still being used. Our team introduced Pact as a way to enable teams to be more confident when building these types of systems.

TECHNICAL DEEP-DIVE

shutterstock_466266161
What is an API and how does it help you?
READ NOW

The AndPlus Innovation Lab is where our passion projects take place. Here, we explore promising technologies, cultivate new skills, put novel theories to the test and more — all on our time (not yours).

code-1839406_1920

 

OUR RESEARCH

Modern applications typically communicate using a RESTful API service in order to keep your data in sync across multiple devices, share your content with other services, or receive updates. Sometimes these APIs are even implemented using multiple collaborating services, all communicating with each other over REST. These interactions have to be designed and documented so that each team knows what they must send and what they should expect to receive. Traditionally, this was done by the service provider writing a specification and publishing it for interested clients. Technologies such as OpenAPI (formerly Swagger) were developed around streamlining this process. However, this approach can often lead to "lowest common denominator" interfaces, or APIs that are overly generic and ill-suited for a particular application.

Consumer-driven contracts turn the development model on its head by allowing the client apps themselves to specify how the API should look and act on their side, putting the responsibility on the service provider to implement the functionality accordingly. By versioning these contracts, or "Pacts," we can also ensure that our APIs will remain backwards-compatible as they change. This is important as it prevents us from breaking the experience for users who haven't updated yet – reducing the amount of bug reports and complaints for the development team. These contracts also integrate into a continuous delivery pipeline to reduce the amount of manual testing required by a QA team.

 

TIS_7322

 

lobby

 

DELIVERABLE

The experiment resulted in both a client web application, written in Typescript, and a REST API server written in Java using the Spring Boot framework. The client application specified API behavior using Pact, a popular consumer contracts library. The Pact specifications were published to a Pact broker and tagged with the appropriate client versions, based on the source control branch. This allowed the provider application to test against both old and new versions of the specification, ensuring that as it added new features, it would not break existing features. The team demonstrated integrating with AndPlus's Bamboo CI server so that deployments to the cloud would only occur when all supported client versions had been successfully tested against the server.

 

HOW IT WAS DONE

  • Pact tests were written using Jest to validate the client's interactions over HTTP
  • A publishing script was written that used information from the source control environment to automatically version specifications tied to new features in a Jira issue tracker
  • A Bamboo build pipeline was configured to automatically test the server against the correct Pacts based on the source control environment
  • A Bamboo deployment pipeline was configured to automatically deploy the server when tests had been run successfully, and the client when the server had successfully deployed

GET IN TOUCH

LET’S BUILD SOMETHING AWESOME. TOGETHER.