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).
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.
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.
AndPlus understands the communication between building level devices and mobile devices and this experience allowed them to concentrate more on the UI functions of the project. They have built a custom BACnet MS/TP communication stack for our products and are looking at branching to other communication protocols to meet our market needs. AndPlus continues to drive our product management to excellence, often suggesting more meaningful approaches to complete a task, and offering feedback on UI and Human Interface based on their knowledge from past projects.
