Share:
.svg)
.svg)
This is a guest blog written by Richard Gill, founder and CEO of Cloud M, a company devoted to saving lives.
CLOUD M is a leading innovator of cloud-based native mobile apps for keeping people safe in their homes, communities, and workplaces.
The Safety Network
The company’s Alerter apps are used by New Zealand Government agencies to warn and keep the public informed during natural disasters and emergency situations. With population coverage of 1.4 million people growing to 4.5 million over the coming months, Alerter is a key tool in the Civil Defence and Emergency Management arsenal.
CLOUD M’s latest product, Blerter, takes this to high-risk workplaces, by empowering personal and collective responsibility for health & safety across sites and projects. Blerter uses social networking, mobile, cloud, big data, and real-time situational awareness to drive change and safety-first cultures in industries like construction, transport, mining and energy.
“The mission-critical nature of these systems means that responsiveness, uptime, and coverage are essential. The more devices client app platforms supported, the more people can be kept safe”, Alisdair Brotchie, Engineering Lead — Mobile, CLOUD M.
Evolution of an API
CLOUD M started out as an API company, building significant cloud-based capability served by a rest‐like API optimized for supporting sophisticated native mobile apps. As the products have grown in features and capabilities, the number of API calls and data models has also grown significantly to more than 400 endpoints and 600 models. The company is also expanding the number of platforms it supports from initially just iOS and mobile web, to Android, desktop, and soon windows mobile and potentially other platforms.
In order to reduce the complexity of re-implementing such a large and rapidly evolving API by hand on every platform the company developed a tool for automatically generating client-side native bindings for the API. While this worked well and provided significant benefits, the company had only managed to implement it so far on one client language due to resource constraints.
“Our code generation tools worked well and really proved how powerful auto-generating native bindings can be. However, it was going to be a big stretch for us to expand these to cover all the languages we were going to need, and we just didn’t have enough engineers to do it at the time” -Brotchie
Challenges of Scale
It became obvious that while the approach was right, the company would have to rapidly increase the number of languages supported, as well as improve the automation of the code generation to meet its business objectives. Along with this, the company is expanding it’s partner base and wanted to provide bindings in a simpler form for 3rd party systems integrators and other app developers. This would mean supporting languages that the company had no in-house expertise in.
“We see being able to give our partners a fully functional SDK rather than just documented API as a real competitive advantage — if we make it easier for them, they’ll integrate more services and faster” - Brotchie
Auto-Generated SDKs
Before committing to a major increase in investment in it’s own code generation tools, the company decided to try out the automated SDK creation service offered by APIMatic. Being fortunate to share space in Auckland with the APIMatic team, the company was able to utilize their significant expertise in short-cutting the process for getting to a successful trial.
In a matter of a few weeks, the company has a large proportion of its API being converted to native language auto-generated SDKs, and has begun building new client app on this SDK. It has also trailed the generated code for Objective-C, Java for Android and Java for Web.
The code generation process is now being plugged into the company’s Continuous Integration environment, which will rapidly decrease the amount of work for app developers implementing API changes or new features.
Risks and Rewards
For any technology company replacing mission critical component of your software stack with a 3rd party solution carries significant risk, especially when failure can affect your entire user base.
The CLOUD M development team undertook a significant analysis of the generated code, and worked closely with the APIMatic engineers to ensure that the SDKs met and will continue to meet the company’s needs.
“We’ve been really impressed with the responsiveness and enthusiasm of the APIMatic team, and the results we’ve achieved together. We now see APIMatic as a significant technology partner helping us maximise our resources and get new features to market much faster” Richard Gill, CEO CLOUD M.
